Single-agent tool loops work until they don't—context windows overflow, latency spikes, and one failure kills everything. Production multi-agent systems need explicit communication patterns. Direct request-response works for simple two-agent handoffs but creates tight coupling. The orchestrator pattern gives you centralized coordination and clear debugging, but introduces a bottleneck. Publish-subscribe decouples agents through event-driven messaging, ideal for pipelines where agents don't need to know about each other. The blackboard pattern lets agents collaborate through shared state—good for iterative refinement tasks like code review or content generation. Hierarchical delegation creates agent trees where managers decompose tasks and assign them to specialists, matching how complex projects actually get done. Most production systems combine patterns: orchestrators that delegate to sub-teams communicating via pub-sub internally. Choose based on coupling tolerance, failure isolation needs, and whether your workflow is sequential, parallel, or iterative. Start with the simplest pattern that works and add complexity only when you have evidence it's needed.
Every agent tutorial follows the same script. Give an LLM a system prompt, connect it to tools, run it in a loop, and call it done. That works for demos. It works for single-task automations. But the moment you need two agents to coordinate on anything meaningful, that single-agent loop pattern falls apart in ways that no amount of prompt engineering can fix.
I've built systems where a dozen agents need to collaborate on workflows spanning research, analysis, content generation, and quality review. The agent logic was never the hard part. The communication between agents was. How Agent A tells Agent B what to do, how they share context without duplicating it, how one agent's failure doesn't cascade through the entire pipeline—these are the problems that separate working multi-agent systems from expensive experiments.
Agent communication patterns determine whether your multi-agent system ships in weeks or stalls for months. Here's what actually works in production, and when to use each approach.
Why Single-Agent Tool Loops Break Down
The single-agent pattern is straightforward. An LLM receives a prompt, decides which tool to call, observes the result, reasons about what to do next, and repeats until the task is done. For focused tasks—answering questions from a knowledge base, extracting data from documents, generating reports—this loop handles the job.
Problems appear when you push this pattern past its design limits.
Context windows overflow. A single agent handling a complex workflow accumulates tool outputs, intermediate reasoning, and conversation history. By the tenth step of a research-and-analysis pipeline, you're burning 80% of your context window on history from earlier steps. The agent's reasoning quality degrades precisely when the task gets hardest. Our guide on agent memory and context management covers this in detail, but the fundamental issue is architectural, not memory-related.
Latency compounds. Each reasoning step in a single-agent loop requires a full LLM inference call. A ten-step workflow means ten sequential calls, each waiting for the previous one. When steps are independent—like researching three different topics—running them sequentially wastes time a parallel architecture would save.
Failure isolation doesn't exist. If a single agent encounters an error on step seven of a twelve-step process, everything stops. There's no way to retry just that step without replaying the entire chain. In production, where external APIs fail and models occasionally hallucinate, this fragility is unacceptable.
Specialization is impossible. Different tasks benefit from different system prompts, different temperature settings, and different tool configurations. A single agent configured for creative writing performs poorly at data validation, and vice versa. Forcing one agent to context-switch between fundamentally different tasks produces mediocre results across all of them.
These aren't theoretical concerns. They're the exact failure modes I've debugged in client systems that outgrew their single-agent architecture. The solution isn't a better prompt—it's a communication pattern that distributes work across specialized agents. For a broader comparison of when each architecture fits, see our breakdown of multi-agent vs single-agent systems.
Direct Request-Response: The Simplest Multi-Agent Pattern
The most intuitive communication pattern mirrors how HTTP APIs work. Agent A sends a request to Agent B, waits for a response, and continues processing. No middleware, no message queues, no shared state.
This pattern works well for straightforward handoffs. A research agent gathers raw data, then sends it directly to a summarization agent that returns a condensed version. A code-generation agent writes a function, then passes it to a review agent that returns feedback. The interaction is synchronous, predictable, and easy to trace.
Implementation is simple. Agent A constructs a message containing the task description and relevant context, calls Agent B's endpoint or function, and receives structured output. In code, this looks like any service-to-service call. The calling agent controls retry logic, timeouts, and fallback behavior.
Where this pattern fails:
I use this pattern for two-agent handoffs where the relationship is stable and the calling agent clearly owns the workflow. A planning agent that calls an execution agent. A drafting agent that calls an editing agent. Once you need three or more agents coordinating, you're better served by a pattern that reduces coupling.
The Orchestrator Pattern: Centralized Agent Coordination
An orchestrator agent sits at the center of a multi-agent system and manages all communication. Specialized agents don't talk to each other—they talk to the orchestrator, which decides what happens next, routes tasks, aggregates results, and handles errors.
Think of it as a project manager who assigns tasks to specialists and synthesizes their output into a final deliverable.
How it works in practice. The orchestrator receives a high-level task, decomposes it into subtasks, assigns each subtask to the appropriate specialist agent, collects their outputs, and either returns a final result or kicks off the next phase. The specialist agents are stateless from a coordination perspective—they receive input, do their job, and return output.
A due diligence system I helped build used this pattern. The orchestrator received a company name and analysis request, then dispatched tasks to a financial analysis agent, a market research agent, a competitive landscape agent, and a regulatory risk agent. Each specialist worked independently with its own tools and context. The orchestrator waited for all four, resolved any contradictions between their findings, and assembled the final report.
Advantages:
Tradeoffs:
This is the pattern I reach for most often. It works for 80% of multi-agent use cases where you need coordination without the complexity of fully decentralized communication.
Publish-Subscribe: Event-Driven Agent Communication
Publish-subscribe decouples agents entirely. Instead of calling each other directly, agents publish events to channels. Other agents subscribe to the channels they care about and react independently. The publisher doesn't know who's listening. The subscribers don't know who published.
When this pattern shines:
Data processing pipelines are the natural fit. An ingestion agent publishes a document_received event. A classification agent subscribes to that event and publishes document_classified. A summarization agent subscribes to document_classified and produces a summary. An indexing agent subscribes to the same event and updates a search index. Each agent operates independently, and adding a new agent to the pipeline requires zero changes to existing agents.
I implemented this for a media monitoring system that tracked news across dozens of sources. A scraping agent published raw articles. Separate agents subscribed for sentiment analysis, entity extraction, topic classification, and relevance scoring. When the client wanted to add translation for non-English articles, we added one subscriber agent. No existing agent was modified or even restarted.
Implementation details that matter:
Tradeoffs:
Blackboard Architecture: Shared-State Agent Collaboration
The blackboard pattern takes a different approach to inter-agent communication. Instead of sending messages to each other, agents read from and write to a shared workspace—the blackboard. Each agent monitors the blackboard for relevant changes, contributes its output, and steps back. No agent directly addresses another agent.
This pattern originated in AI research for problems where multiple knowledge sources need to collaborate iteratively—and it maps surprisingly well to certain multi-agent LLM workflows.
How it works. The blackboard holds the current state of a task: raw inputs, intermediate results, annotations, and final outputs. Agents watch for conditions that trigger their expertise. A grammar agent activates when it sees unreviewed text. A fact-checking agent activates when it sees claims without citations. A formatting agent activates when it sees reviewed-and-approved content. Each agent reads what it needs, writes its contribution, and the blackboard state evolves until the task is complete.
Where I've seen this work:
A collaborative content pipeline used the blackboard pattern effectively. The shared state was a document with sections in various stages: drafted, reviewed, fact-checked, edited, and approved. A research agent wrote initial drafts. A review agent added feedback. The drafting agent revised based on feedback. A compliance agent flagged regulatory issues. Agents operated asynchronously, each picking up work as it appeared on the blackboard, running multiple review cycles naturally without explicit coordination logic.
Code review systems are another natural fit. Multiple specialized agents—security, performance, style, correctness—all read the same codebase from the blackboard and write their findings. No agent needs to know what the others found. A final synthesis step aggregates all findings.
What makes blackboard different from pub-sub:
Pub-sub is about events flowing through a pipeline. Blackboard is about shared state that evolves. In pub-sub, agents react to discrete messages. In blackboard, agents react to the current state of the workspace. This distinction matters when agents need to see each other's contributions to do their own work—the fact-checker needs to see the draft and the reviewer's comments before deciding what to check.
Tradeoffs:
Hierarchical Delegation: Agents Managing Agent Teams
Hierarchical delegation creates a tree structure where manager agents decompose complex tasks and delegate subtasks to specialist agents or sub-teams. Each level of the hierarchy handles coordination at its own scope, and only escalates to the level above when something falls outside its authority.
This pattern mirrors how organizations actually function. A VP doesn't manage individual tasks—they set objectives for directors, who coordinate managers, who assign work to individual contributors. The same principle applies to agent architectures.
A practical example. A client's investment analysis system used three levels. A top-level strategy agent received the analysis request and determined which asset classes to evaluate. It delegated to sector-level manager agents—one for equities, one for fixed income, one for alternatives. Each sector manager controlled its own team of specialist agents: the equities manager dispatched agents for fundamental analysis, technical analysis, and news sentiment. The specialist agents did the work and reported up. Each manager synthesized its team's output and reported to the strategy agent.
Why this works well for complex problems:
Where to be cautious:
Choosing the Right Communication Pattern
No single pattern fits every multi-agent system. The right choice depends on your specific coordination requirements.
Use direct request-response when you have two or three agents with stable interfaces and simple handoff logic. Don't introduce infrastructure you don't need.
Use the orchestrator pattern when a central agent needs to make conditional routing decisions, aggregate results from multiple specialists, or maintain a clear audit trail. This is the default for most business automation workflows.
Use publish-subscribe when agents should operate independently on a shared event stream, when you need to add new agents without modifying existing ones, or when your workflow is a pipeline with clear input-to-output stages.
Use the blackboard pattern when agents need to see and build on each other's contributions iteratively—collaborative writing, multi-pass code review, or any workflow where the output improves through repeated agent interaction.
Use hierarchical delegation when your problem naturally decomposes into nested sub-problems, when the agent count exceeds what a single orchestrator can manage, or when different sub-teams need independent coordination strategies.
Most production systems combine patterns. An orchestrator at the top level delegates to sub-teams that use pub-sub internally. A hierarchical system where leaf-level agents communicate through a shared blackboard. The patterns are composable—match each to the specific coordination problem it solves.
The mistake I see most often is choosing a pattern based on what feels architecturally sophisticated rather than what the problem requires. Start with the simplest pattern that handles your coordination needs. Add complexity when you have evidence—not assumptions—that a more sophisticated pattern would solve a real problem. The teams that ship working multi-agent systems fastest are the ones that resist over-engineering their communication layer on day one.
Build Agent Communication That Scales
Agent communication patterns are the infrastructure layer that makes multi-agent systems viable in production. Single-agent loops work until they don't, and when they stop working, the fix isn't a better prompt—it's a communication architecture that distributes work, isolates failures, and lets specialized agents do what they do best.
Start with direct request-response or an orchestrator for your first multi-agent system. Get it working, learn where the coordination pain points are, and evolve toward pub-sub, blackboard, or hierarchical patterns as your system grows. The patterns in this article aren't theoretical—they're the ones I've used across dozens of production deployments, and they work because they solve the real problem: getting agents to collaborate without creating a tangled mess of dependencies.
Frequently Asked Questions
Quick answers to common questions about this topic
Single-agent patterns involve one agent calling tools and reasoning in a loop—all logic lives in one context window. Multi-agent communication patterns involve multiple specialized agents exchanging messages, sharing state, or coordinating through an orchestrator. The key difference is that multi-agent patterns distribute reasoning across agents, enabling specialization, parallel processing, and failure isolation.