Inter-Agent Communication Patterns

The Two Foundational Paradigms of Agent Communication

At the highest level, inter-agent communication architectures fall into two main categories. A great conceptual introduction to these can be found in the LangChain video on multi-agent architectures.

As the video explains, the two primary methods are:

1. Shared Knowledge: Agents communicate indirectly by reading from and writing to a common, centralized data structure.
2. Message Passing: Agents communicate directly (or through a broker) by sending explicit messages to one another, each maintaining its own private state.

Let's dissect each of these paradigms.

1. Shared Knowledge (The Blackboard Pattern)

The classic implementation of the shared knowledge paradigm is the Blackboard Architecture. In this model, a central "blackboard" acts as a shared repository of information. Specialized agents, known as "knowledge sources," watch the blackboard for data relevant to them. When they see something they can act on, they perform their task and post their results back to the blackboard, potentially triggering other agents.

This pattern is powerful for solving complex, emergent problems where the solution path isn't known in advance. From a system design perspective, this is analogous to services communicating via a shared database or a distributed cache like Redis. The primary architectural challenges revolve around concurrency control, data consistency, and avoiding contention on the shared store.

Modern agent frameworks have adopted this pattern. The technical paper "Multi-Agent Framework Communication Protocols" provides an excellent analysis of how this is implemented today.

As the paper highlights, LangGraph's GraphState is a direct modern implementation of this shared-state philosophy.

• Pros: It provides high determinism, clear control flow, and excellent observability, as the entire state of the system is in one place.
• Cons: It can become a bottleneck. As more agents try to write to the state simultaneously, you introduce problems of write contention. Persisting this state for durability can also create I/O overhead, which often becomes the dominant performance constraint.

2. Message Passing

In the message-passing paradigm, agents operate more like independent services in a microservices architecture. Each agent maintains its own internal state and communicates with others by sending and receiving messages. There is no single shared knowledge store.

A common way to implement this is with a message broker, which will be very familiar to you from your experience with distributed systems.

This architecture is highly scalable and decoupled. Agents don't need to know about each other's internal state; they only need to understand the message format and the address (or topic) to send to.

Let's return to the "Multi-Agent Framework Communication Protocols" paper to see how this pattern is realized in a popular framework.

CrewAI is a prime example of a framework built on message passing.

• Pros: This approach offers high horizontal scalability and fault isolation. The failure of one agent doesn't corrupt a central state.
• Cons: Coordination becomes more complex. Instead of just checking a central state, agents must parse messages and engage in dialogue, which adds "conversational overhead." The system's overall state is distributed and harder to observe in its entirety.

Common Message-Passing Protocols

While "message passing" is the paradigm, several specific protocols have been developed to structure these conversations. The field of Distributed AI has formalized these interactions, drawing heavily from philosophy's "Speech Act Theory"—the idea that language performs actions. A message isn't just data; it's a REQUEST, an INFORM, or a PROPOSE.

The "Engineering Notes" article on agent communication provides an excellent breakdown of these foundational patterns.

To summarize the key protocols from the article:

1. Request-Reply: A simple, synchronous interaction where one agent asks another to perform an action and waits for a result. This is analogous to a standard RPC or REST API call.
2. Broadcast-Subscribe (Pub/Sub): An asynchronous pattern where agents publish information to a topic, and other agents subscribe to topics they care about. This is ideal for event-driven systems and is exactly what the Kafka diagram illustrates.
3. Contract Net (Bidding): A dynamic task allocation protocol. A "manager" agent announces a task (a "call for proposals"), and "worker" agents bid on it. The manager awards the contract to the best bidder. This is a powerful pattern for resource optimization and will appeal to your interest in economics.
4. Negotiation: An iterative back-and-forth process where agents exchange proposals and counter-proposals to reach a mutually acceptable agreement.

Coordination Architectures

The communication pattern you choose enables a particular coordination architecture. This defines the "who talks to whom" rules of the system. The Google Cloud Tech podcast provides a great overview of these common structures.

The main coordination architectures are:

• Supervisor / Orchestrator: A central agent acts as a manager, decomposing problems and delegating tasks to a team of specialized agents. This is a highly practical and common pattern that imposes a clear hierarchy on communication. The delegation can be:
  • Sequential (Router): The supervisor passes a task to Agent A, gets the result, then passes a new task to Agent B. This creates a dynamic, step-by-step workflow.
  • Parallel: The supervisor delegates tasks to Agents A, B, and C simultaneously and aggregates the results.
• Deterministic Flow (Sequential/Circular): This is the simplest pattern, where agents are arranged in a fixed pipeline, like an assembly line. Agent A always hands off to Agent B. A circular flow is a variation that allows for iterative refinement, like a coder-tester loop.
• Swarm (Decentralized): This is a highly flexible "all-to-all" communication model where any agent can, in principle, talk to any other agent. This allows for emergent collaboration but runs the risk of chaos without careful design. It prioritizes flexibility over control.

Conclusion

In this lesson, we have moved from single-agent design to the multi-agent architectures that enable complex, collaborative problem-solving. We've seen that the choice of communication pattern is a fundamental trade-off with deep architectural implications.

Key Takeaways:

• Two Core Paradigms: Inter-agent communication is built on either Shared Knowledge (e.g., a Blackboard, LangGraph's GraphState) or Message Passing (e.g., conversational, CrewAI).
• The Fundamental Trade-Off: Shared State offers determinism, control, and observability at the cost of potential contention and I/O bottlenecks. Message Passing provides scalability, decoupling, and fault isolation at the cost of higher coordination complexity and distributed state.
• Structured Protocols: Message passing is governed by protocols like Request-Reply, Pub/Sub, and the more advanced Contract Net, which use a vocabulary of "speech acts" to structure conversations.
• Coordination Defines Topology: The communication patterns are used to build coordination architectures like the hierarchical Supervisor model, the rigid Deterministic Flow, or the flexible Swarm model.

Preview of the Next Lesson:

We now understand how agents can talk to each other. The next logical question is, what do they talk about, and who directs the conversation? In the next lesson, we will focus on the mechanisms an orchestrator or supervisor uses to manage the workflow. We will explore how a complex goal is broken down into smaller tasks, how those tasks are delegated to the right agents, and how their individual contributions are synthesized into a coherent final result.