How AI Agents Communicate with Each Other

Message Passing

Message passing is the most intuitive communication model because it mirrors how humans communicate: one agent sends a message to another agent, and the receiving agent processes the message and optionally sends a response. Each message contains all the information the receiving agent needs to perform its work, making the communication explicit and traceable. You can understand an agent's behavior by examining the messages it receives and sends without needing to inspect shared state or external data stores.

Direct message passing connects two agents in a point-to-point conversation. Agent A sends a message to Agent B, which processes it and returns a response. This pattern is simple and works well for request-response interactions like asking a research agent to look up information and return the results. The main limitation is that it creates tight coupling between the sender and receiver: the sender must know which agent to contact and must wait for a response before proceeding.

Broadcast messaging sends a message to all agents in the system or to all agents in a defined group. This is useful for system-wide announcements like configuration changes, for distributing work to a pool of agents where any available agent can handle the task, or for notifications that multiple agents might need to act on. The tradeoff is that broadcast messages consume resources at every receiving agent, including those that have no use for the message.

AutoGen uses message passing as its primary communication model, with agents exchanging messages in structured conversations. The conversation history serves as the communication channel, and agents can see messages from all participants when operating in group chat mode. This conversational approach is natural for tasks that involve discussion, deliberation, and iterative refinement but can be token-expensive because agents receive the full conversation history, not just the messages addressed to them.

Shared State

Shared state communication provides a common data store that all agents can read from and write to. Instead of sending messages directly to each other, agents communicate indirectly by writing their results to shared state and reading other agents' results from the same state. This indirect communication model decouples agents from each other because they do not need to know which specific agents produced the data they are reading or which agents will consume the data they are writing.

LangGraph implements shared state through its StateGraph abstraction, where a typed state object flows through the execution graph. Each node (agent) receives the current state, performs its work, and returns state updates that are merged into the accumulated state. This design provides strong typing, automatic persistence, and checkpointing, making it well-suited for workflows that need auditability and the ability to resume from any point in the execution.

The blackboard pattern is a variation of shared state where a central data structure is visible to all agents, and agents opportunistically contribute information when they have something relevant to add. This pattern works well for problems that are solved incrementally, where the solution emerges from the accumulated contributions of multiple specialists. The blackboard model is more flexible than the state graph model because agents can contribute in any order, but it provides less structure and typing.

Shared state creates a risk of concurrent access conflicts when multiple agents read and modify the same state simultaneously. Two parallel agents might read the same state, make conflicting decisions based on it, and write back contradictory updates. Mitigating this risk requires either serializing state access (only one agent can write at a time) or using append-only semantics (agents add their contributions to lists rather than overwriting previous values). Most production systems use append-only semantics during parallel phases and resolve any conflicts during the synchronization step between phases.

Event-Driven Communication

Event-driven communication is a decoupled model where agents publish events to a shared event bus and subscribe to events they are interested in. When an agent completes its work, it publishes an event describing what it did and what results it produced. Other agents that have subscribed to that type of event receive it and decide whether to take action. The publisher does not need to know which agents will receive the event, and the subscribers do not need to know which agent published it.

This publish-subscribe pattern provides the loosest coupling of any communication model. Agents can be added to or removed from the system without modifying other agents because publishers and subscribers are independent. New agent types can subscribe to existing event types to add new capabilities without changing the agents that produce those events. This extensibility makes event-driven architectures well-suited for systems that evolve frequently or need to support dynamic agent composition.

The tradeoff is complexity in understanding the system's behavior. In message passing, you can trace a conversation between two agents by reading their message history. In event-driven systems, you need to trace events through the event bus, determine which agents received each event, and reconstruct the chain of events that led to the final output. This distributed event flow is harder to debug and reason about than direct message passing or linear state flow.

Event-driven architectures also introduce eventual consistency concerns. An event published by Agent A might not be received by Agent B immediately due to network latency or processing delays. If Agent B makes a decision before receiving Agent A's event, it may be working with stale information. For workflows where agents need to coordinate in real time, event-driven communication may need to be combined with synchronization barriers that ensure all relevant events have been processed before agents proceed to the next phase.

Standardized Protocols

The A2A (Agent-to-Agent) protocol, developed by Google, standardizes communication between agents across different frameworks and vendors. A2A defines how agents discover each other through agent cards, exchange structured messages, manage task lifecycles, and return results. By implementing A2A, agents built with different frameworks can collaborate without custom integration code, reducing the engineering cost of building multi-framework multi-agent systems.

The Model Context Protocol (MCP), developed by Anthropic, standardizes how agents connect to external tools and data sources. While MCP is not a direct agent-to-agent communication protocol, it enables a form of indirect communication by providing standardized access to shared resources. Two agents that connect to the same database through MCP can effectively communicate by reading and writing data to that shared resource using a common interface.

These standardized protocols are becoming increasingly important as multi-agent systems grow beyond single-team, single-framework deployments. In enterprise environments where different teams use different frameworks and different vendors, standardized protocols provide the interoperability layer that enables cross-team and cross-vendor agent collaboration without requiring everyone to adopt the same technology stack.

Choosing the Right Communication Model

The right communication model depends on the structure of your workflow and the relationships between your agents. Use message passing when agents need to have direct, traceable conversations and when the workflow involves clear request-response patterns. Use shared state when agents contribute to a common work product and need access to each other's intermediate results without explicit coordination. Use event-driven communication when agents are loosely coupled and the system needs to be easily extensible with new agent types.

Many production systems combine multiple communication models. An orchestrator might use message passing to delegate tasks to agents while the agents use shared state to store their results. A quality review agent might subscribe to completion events from worker agents through an event bus while communicating review feedback through direct messages. The combination of models provides both the traceability of message passing and the decoupling of event-driven architecture.