Shared State, Messaging, and Coordination

Someone has counted the failure this lesson is about. In 2025 Cemri and colleagues read more than 1,600 traces from 7 multi-agent frameworks and sorted every failure they found into a taxonomy: “This process identifies 14 unique modes, clustered into 3 categories: (i) system design issues, (ii) inter-agent misalignment, and (iii) task verification.” The coding was checked on 150 traces, at inter-annotator agreement κ = 0.88.

The distribution is the point. Inter-agent misalignment accounts for 32.3% of failures. System-design issues account for 44.2%, task verification for 23.5%. The paper's own figure caption says the percentages come from “our analysis of 1642 MAS execution traces”. And the systems broke often to begin with: the body reports “41% to 86.7% failure rate on 7 state-of-the-art (SOTA) open-source MAS”.

The misalignment modes are named and numbered rather than vague: 2.1 Conversation Reset, 2.2 Fail to Ask for Clarification, 2.3 Task Derailment, 2.4 Information Withholding, 2.5 Ignored Other Agent's Input, 2.6 Reasoning-Action Mismatch. An agent rewrites the goal. A second appends evidence. A third merges a stale summary. That is not an anecdote about a bad day. It is modes 2.3, 2.4 and 2.5, and roughly a third of every failure anyone has counted happens there.

Coordination that survives a restart lives in five places. A task board, holding assignments, owners, dependencies, status and budgets. An artifact store, holding versioned outputs with provenance and access rules. A message envelope, carrying sender, recipient, task, type, correlation and deadline. A shared-state policy: ownership, locking, append-only events, conflict detection. And a coordination monitor, watching for orphaned work, loops, contention and inconsistent versions. Give the policy and the monitor different owners, and different tests.

None of that is new. The first version of it is 45 years old. Reid G. Smith published the contract net protocol in December 1980, and it already had typed coordination messages with a named owner and an explicit deadline. Task distribution runs as an announcement–bid–award negotiation cycle. The execution of a task is a contract between exactly two nodes: one manager, one contractor. That is the ownership rule of a task board, written as a protocol rather than as a norm.

The task announcement message carries eight slots: To, From, Type, Contract, Task Abstraction, Eligibility Specification, Bid Specification and Expiration Time. The last of them is not decorative — “the expiration time is a deadline for receiving bids”. The full specification defines ten message types, not three: task-announcement, bid, announced-award, directed-award, acknowledgment, report, termination, node-available-message, request-message and information-message.

A protocol is not about wording, and Smith said so: “It offers a structure that assists the system designer in deciding what the nodes should say to each other, rather than how to say it.” The paper has been cited 2,394 times. The design your agents need has been sitting in the literature for four decades. A free-form chat channel throws away every slot in it.

Conversation bus, blackboard, and message queue and ledger differ on one question: can the state be recovered without replaying the talk? On a conversation bus the chat log is the state, so losing it loses the work — flexible, hard to recover, ambiguous about commitments. A blackboard gives everyone a common view, but it needs ownership and it invites contention. A message queue and ledger is durable and auditable, and costs more protocol design. The test that separates them is simple. With the transcript gone, can the system still say who owes what and by when? And can a message be mistaken for a command without authority?

The blackboard column is not a thought experiment. Hearsay-II, published in June 1980, built one: independent knowledge sources that could reach each other only through a shared structured global database, where “knowledge sources operate solely by detecting and modifying hypotheses on the blackboard”. It worked, and the paper says by how much in its opening sentence. The system “recognizes connected speech in a 1000-word vocabulary with correct interpretations for 90 percent of test sentences”. A later line adds that “The vocabulary contains 1011 words”.

Its architecture also names the ambiguity this lesson keeps circling: “In this framework the blackboard serves in two roles: It represents intermediate states of problem-solving activity, and it communicates messages (hypotheses) from one KS that activate other KSs.” When the state is also the channel, every write is a broadcast and every broadcast is a write. So a blackboard needs an ownership rule bolted on top. “Needs ownership” in the middle column is not a stylistic preference.

Multi-agent coordination requires a shared model of tasks, artifacts, ownership, status, and messages. Agents talking in ordinary language can work out what a request means. But durable coordination should use typed events and versioned state.

Messages need sender identity, recipient, purpose, correlation, authority, and expected response. That list is not a preference. It is a standard with a document number. The FIPA ACL Message Structure Specification, SC00061G, dated 2002, fixes exactly 13 message parameters: performative, sender, receiver, reply-to, content, language, encoding, ontology, protocol, conversation-id, reply-with, in-reply-to, reply-by. Four of those are the correlation machinery on their own — conversation-id, reply-with, in-reply-to, reply-by. The performative is the field that “Denotes the type of the communicative act of the ACL message”.

Only one field is mandatory: “Precisely which parameters are needed for effective agent communication will vary according to the situation; the only parameter that is mandatory in all ACL messages is the performative, although it is expected that most ACL messages will also contain sender, receiver and content parameters.”

So the one obligatory field is the one that says what kind of message this is. Its vocabulary is enumerated too. The companion FIPA Communicative Act Library Specification lists 22 typed communicative acts, among them request, propose, accept-proposal, reject-proposal, agree, refuse, confirm, cancel, and not-understood. FIPA was accepted as a standards committee of the IEEE Computer Society in 2005.

A broadcast channel without semantics has dropped 13 fields and 22 message types and kept only the content. That is why agents on it duplicate work, and why they depend on each other invisibly.

Ownership comes first. Every promise in the system belongs to exactly one agent, and the board says which. A ledger entry that meets the bar has four fields: every commitment has an owner, status, deadline, and evidence. Then check the other three signals one at a time, under repeated and adversarial cases, not once on a clean run.

Signal 3 is the one teams state as a wish. It can be stated as a number instead. Amazon's Dynamo paper asks this lesson's question in this lesson's words: “This process of conflict resolution introduces two problems: when to resolve them and who resolves them.” Then it answers with a measurement. Nine authors at Amazon profiled the shopping-cart service over 24 hours in 2007 and published what they saw: “During this period, 99.94% of requests saw exactly one version; 0.00057% of requests saw 2 versions; 0.00047% of requests saw 3 versions and 0.00009% of requests saw 4 versions.”

That is what a reconciled system looks like when someone instruments it. A named resolver, a named moment of resolution, and a published rate of divergence down to five decimal places. “Conflicting updates are detected and reconciled explicitly” is not a claim you assert about your agents. It is a percentage you can print.

Define the coordination protocol for a workflow whose agents currently just talk to each other. List the shared objects: tasks, artifacts, facts, budgets, approvals. Assign ownership — who may create, update, accept or retire each. Type the messages: request, response, proposal, event, approval, error, cancellation. Version the mutations, with immutable events or conflict detection. Monitor liveness: stalled assignments, missing owners, unconsumed messages.

You do not have to invent the shape. The Agent2Agent (A2A) Protocol Specification, latest released version 1.0.0, was created by Google and moved to the Linux Foundation on 23 June 2025. The Linux Foundation describes the project in one line — “A2A enables autonomous agents to discover one another, exchange information securely and collaborate across systems” — and notes that it was “launched by Google in April and with growing support from more than 100 leading technology companies”.

The specification performs each of the five steps as normative text. It lists the shared objects: Task, Message, Artifact, Part. It assigns ownership by taking task identity out of the conversation: “A taskId is a unique identifier for a Task object, representing a stateful unit of work with a defined lifecycle”, and “Task IDs are server-generated when a new task is created in response to a Message”. A contextId sits alongside it, and outputs are stored as artifacts. It types the status with eight lifecycle states: TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_REJECTED, TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED.

And it writes the authority rule as a prohibition rather than a hope: “Agents MUST NOT treat the TASK_STATE_AUTH_REQUIRED state transition, by itself, as authorization for any particular operation.”

Implementers already build against it. Amazon Web Services' A2A protocol contract specifies JSON-RPC 2.0 over HTTP and an agent card at /.well-known/agent-card.json, with responses “containing tasks and artifacts” and an advertised protocolVersion 0.3.0.

Write your own protocol so that a reader can tell, for any message in the log, whether it was an instruction someone was entitled to give. And so that each promise it creates lands in the ledger with an owner, a status, a deadline, and the evidence behind it.

Communication is part of the action space. Evaluate message volume, misunderstanding, stale state, and authority errors as system failures — because when someone does evaluate them, that is where the failures are. Across 1,642 multi-agent execution traces, 32.3% of failures are inter-agent misalignment, against 44.2% system-design issues and 23.5% task verification. Failure rates across the seven open-source systems examined ran from 41% to 86.7%. Modes 2.4 Information Withholding and 2.5 Ignored Other Agent's Input happen in the talking. They were counted only because someone read the transcripts against a codebook and checked the coding at κ = 0.88 on 150 traces.

The team that owns multi-agent coordination state should be able to do the same on its own logs. Point to a case where an agent treated a suggestion as an order and acted on it. Open the board and show, for every outstanding promise, who owns it, where it stands, when it is due, and what backs it. Dynamo could report that 99.94% of shopping-cart requests saw exactly one version because someone profiled the service for 24 hours. Those four fields and that one percentage are what a chat log does not have and cannot be made to produce.