Agent Communication Patterns

Welcome to the next lesson in our journey to build a production-grade agentic infrastructure. In our previous session, we created a conceptual blueprint of our hierarchical system, defining the essential components like the orchestrator, worker agents, tools, prompts, and memory. We now have a clear picture of the "what." This lesson focuses on the "how"—specifically, how these components communicate with each other.

The communication patterns you choose are a foundational architectural decision, deeply influencing your system's scalability, flexibility, and complexity. Today, we will explore the three dominant patterns for agent communication: direct request-response, shared state, and event-driven messaging. Understanding their trade-offs will empower you to select the right pattern for the right job within your hierarchical architecture.

1. The Three Dominant Communication Patterns

In any distributed system, including a multi-agent one, components need a way to exchange information. How they do so defines the system's runtime characteristics. An excellent article from Grizzly Peak Software outlines the three primary approaches.

Let's dissect these patterns, relating them to concepts you're already familiar with from your full-stack development experience.

a) Request-Response (Direct Messaging)

This is the most straightforward pattern. Agent A sends a message directly to Agent B and typically waits for a response.

• Analogy: This is identical to a synchronous function call within a program or, more broadly, a client making a REST API request to a server. The client sends an HTTP request and blocks until it receives a response.
• Coupling: This pattern creates tight coupling. The calling agent (the client) must know the specific identity and location (e.g., the API endpoint or object reference) of the agent it wants to communicate with. If Agent B's interface changes, Agent A must be updated.
• Use Case: It's perfect for simple, direct commands where a clear, immediate answer is needed. For example, an Orchestrator agent telling a DatabaseQueryAgent to "fetch user data for ID 123."

b) Shared State (The Blackboard Pattern)

In this pattern, agents don't talk to each other directly. Instead, they interact with a common, shared data object or space, often called a "blackboard." Agents read from the blackboard to get context or tasks and write their results back to it.

• Analogy: Imagine a project management board like Trello or Jira. Different team members (agents) look at the board to find tasks in the "To Do" column. When they finish a task, they move the card to the "Done" column and add their deliverables. They don't need to know who created the task or who will use their output; they only interact with the shared board. From a technical standpoint, this is similar to multiple services reading from and writing to a shared database table or a Redis cache.
• Coupling: This pattern decouples agents from each other, but couples them to the data schema of the blackboard. Agents don't need to know about other agents' existence, which makes it easy to add or remove agents. However, they must all agree on the structure of the shared state.
• Use Case: This is ideal for collaborative problem-solving where multiple agents contribute pieces to a larger solution, and the order of operations might not be fixed. An agent can react to a change in state made by any other agent.

The concept of sharing a state object is a key design choice in modern agent frameworks. The following video from LangChain offers a clear explanation of this choice.

c) Event-Driven (Publish/Subscribe)

Here, agents communicate asynchronously through a message bus or event broker. A "producer" agent publishes an event (a message) to a specific "topic" without any knowledge of who will receive it. "Consumer" agents subscribe to topics they are interested in and react whenever a new event is published.

• Analogy: This pattern is the foundation of many modern microservices architectures, using tools like Apache Kafka, RabbitMQ, or AWS SNS/SQS. A new_order event is published by the ordering service, and the inventory, shipping, and notification services all independently react to it.
• Coupling: This provides the loosest coupling (both spatial and temporal). Producers and consumers don't know each other exists. They only need to agree on the message format for a given topic. A consumer can be offline and process events when it comes back online, a key feature of temporal decoupling.
• Use Case: This is extremely powerful for building scalable, resilient, and extensible systems. You can easily add new agents that respond to existing events without changing any of the existing agents. For example, you could add a new FraudDetectionAgent that subscribes to new_order events without the OrderAgent ever knowing.

2. Architectural Trade-offs: A Deeper Look

Your background in building backend systems gives you a head start here, as the trade-offs in agent communication mirror those in microservice communication. Let's watch a video from Confluent, the company behind Kafka, that deep-dives into the comparison between Request/Response and Event-Driven Architectures (EDA).

Based on the video and our discussion, here is a summary of the trade-offs:

3. Applying Patterns to Agentic Workflows

In a sophisticated system like the one you're building, you won't choose just one pattern. You'll use a mix of them, applying the right one for each interaction. Let's look at some practical agent workflows to see how these patterns combine.

The following resource provides excellent, code-driven examples of common agent workflows.

Let's break down the workflows from the article:

• Chaining & Routing: These are classic examples of Request-Response. In chaining, the output of Agent A is directly passed as the input to Agent B. In routing, a dispatcher agent directly calls one of several specialist agents.
• Evaluator-Optimizer: This is an iterative Request-Response loop. The Writer agent sends its work to the Supervisor, which sends feedback directly back. This continues until a condition is met.
• Orchestrator-Workers: This is a more complex, hybrid pattern, highly relevant to your goal.

1. The IN request goes to the Orchestrator.
2. The Orchestrator dispatches distinct tasks to AGENT 1, AGENT 2, and AGENT 3. This is a Request-Response interaction (the orchestrator "calls" the worker agents).
3. The agents work in parallel. They might all be working from a piece of a Shared State (the initial problem decomposition from the orchestrator).
4. The agents complete their work and send their results to the Aggregator. This step could be implemented in two ways:
   • Request-Response: The Aggregator could poll the agents, asking "Are you done yet?".
   • Event-Driven: More elegantly, each agent could publish a task_completed event containing its result. The Aggregator subscribes to these events and knows its job is done once it receives a result from each worker.

This hybrid approach gives you the best of both worlds: the direct control of request-response for delegation and the scalable, decoupled nature of event-driven or shared-state patterns for collecting results.

Conclusion

In this lesson, we've moved from defining what agents are to understanding how they interact. The choice of communication pattern is a critical architectural lever that balances simplicity, scalability, and flexibility.

Key Takeaways:

• Request-Response is simple, synchronous, and creates tight coupling. It's best for direct, imperative commands.
• Shared State decouples agents from each other but couples them to a data schema. It's excellent for collaborative workflows where agents react to changes in a common dataset.
• Event-Driven communication offers the most flexibility and scalability through loose, asynchronous coupling. It's ideal for systems that need to be easily extended.
• Production-grade agentic systems rarely use a single pattern. They strategically combine them, using request-response for direct control and event-driven or shared-state patterns for parallel and asynchronous collaboration.

In our next lesson, we will build on this foundation. Now that we know how agents can communicate, we'll start designing who these agents are. We will focus on defining specific agent roles, such as a DataGatheringAgent or a ReportWritingAgent, establishing their clear responsibilities and boundaries within the hierarchy.