Multi-Agent Systems › Communication Protocols

Agents in a multi-agent system need to exchange information reliably. The communication protocol defines the format and channel together with the semantics of these exchanges. Getting this right matters more than it might seem. Ambiguous messages cause agents to misinterpret task requirements. Missing context causes agents to produce outputs that cannot be composed with other agents' outputs. Inadequate error signaling leaves the orchestrator unable to respond appropriately to failures.

Two fundamental communication paradigms exist:

Shared state (also called a shared workspace or blackboard): All agents read from and write to a common data store. An agent processing a research subtask might write its findings to a shared document that the orchestrator and other agents can read. This is simple to implement and avoids serializing messages, but requires careful coordination to avoid race conditions where two agents modify the same state simultaneously.

Message passing: Agents send structured messages directly to each other (or through a message bus). Messages identify the sender and recipient alongside the payload. This is more explicit about information flow and easier to trace, but requires agents to poll for incoming messages or react to asynchronous notifications.

Many practical systems blend both: a shared workspace holds durable state (task assignments, completed results), while message passing handles real-time coordination (requesting help, signaling completion). The workspace acts as a source of truth about what has been accomplished, while the message bus handles the dynamic coordination of who should do what next.

Shared state introduces its own challenges beyond race conditions. When multiple agents write to the same data store, you need clear conventions for what data belongs to which agent and how updates are structured. Namespacing (storing each agent's output under a key that includes the agent ID and task ID) avoids collisions and makes the workspace readable after the fact as a complete audit trail of the multi-agent execution.

For agents to communicate effectively, their messages need a consistent structure. A minimal message schema includes:

• Sender: Which agent sent this message
• Recipient: Which agent (or all agents) should process it
• Message type: What kind of message this is (task assignment, result report, clarification request, approval request, error notification)
• Content: The actual payload, typically structured as JSON or plain text
• Conversation ID: A thread identifier linking related messages

Having explicit message types lets agents route messages efficiently. An orchestrator processing many messages needs to quickly distinguish a subtask completion from an error report. Message types also serve as a contract between agents: when a subagent sends a task_completed message, the orchestrator knows it will find the result in the workspace under the relevant task ID.

Schema evolution is a practical concern. When you update the message format (e.g., add a new field indicating execution time), agents using the old schema need to handle the new field gracefully. Versioning messages and writing agents to ignore unknown fields follows the compatibility principle from network protocol design: be strict in what you send, liberal in what you accept.

When multiple agents exchange multiple messages about a single task, tracking context becomes important. A subagent asking a clarification question and then receiving an answer needs to link those messages to the original task. Conversation threads with unique identifiers solve this: every message carries the conversation ID, and agents maintain a history of the conversation for context.

For LLM-based agents, managing conversation history has a practical cost. Including the full multi-agent message history in every agent's context window is expensive. Systems typically use summarization (compress older messages) or selective inclusion (only include messages relevant to the current agent's active task) to keep context manageable, building on the memory techniques discussed in the Agent Memory chapter.

The tension between completeness and efficiency in conversation management does not have a universal solution. For tasks where the complete history is essential for correctness (e.g., an agent that needs to know about a decision made three rounds ago), selective inclusion risks omitting critical context. For tasks that are truly local (an agent that only needs its own task specification and the results it depends on), including the full history wastes tokens. Adaptive context management, which monitors what context each agent attends to and prunes unused history accordingly, is an active research area.

One underappreciated aspect of conversation management is the role of explicit acknowledgment messages. In human teams, a brief "understood, I will start on this now" serves an important function: it confirms that the message was received and interpreted correctly. Without acknowledgment, a sender cannot distinguish between "message received and task in progress" and "message lost in transit." Building explicit acknowledgment into multi-agent message protocols, while adding overhead, dramatically reduces the number of situations where an orchestrator discovers hours later that a subtask was never started.

When one agent's output becomes another agent's input, the output format is an implicit contract. If the research agent produces markdown prose and the analysis agent expects a JSON object with specific fields, the pipeline breaks at the boundary. Making this contract explicit through typed data structures prevents an entire class of failures that are otherwise difficult to diagnose because they manifest as downstream errors with no obvious connection to the upstream format mismatch.

Pydantic models (in Python) serve this purpose well. Defining the research agent's output as a ResearchFindings Pydantic model with fields sources, key_claims, confidence_level, and date_range forces the research agent to produce data in a validated format and gives the analysis agent a typed, navigable structure instead of raw text. The validation happens at the boundary: if the research agent produces output that does not conform to the schema, the error is raised immediately rather than propagating silently into the analysis stage.

Structured outputs also make the system more debuggable. When every inter-agent data exchange is typed and versioned, you can inspect the workspace and see exactly what each agent received and produced, in a format that a human can read and reason about. This turns post-hoc debugging from a detective exercise into a straightforward inspection of structured records.