Multi-Agent Systems: When One Agent Is Not Enough

Why Multiple Agents

The fundamental reason to use multiple agents is context focus. A language model performs better when its context window contains only information relevant to its immediate task. A single agent handling a complex task accumulates tool results, reasoning traces, and intermediate outputs across many steps, and its context window fills with a mix of information from different phases of the task. A multi-agent system gives each agent a clean, focused context for its specific sub-task, which produces better results per agent even though the total system is more complex.

The second reason is tool specialization. Different parts of a complex task often require different tools, and a single agent with 30 tools is harder to build and more error-prone than three agents with 10 tools each. A coding agent needs access to the file system, a test runner, and a linter. A research agent needs web search, document retrieval, and data extraction. A writing agent needs a style guide, templates, and a grammar checker. Each agent works better when its tools are focused on its specific job, because the model has to choose among fewer options and is less likely to call the wrong tool.

The third reason is parallelism. When a task decomposes into independent sub-tasks, multiple agents can work on them simultaneously. A research report that requires data from three different sources can have three research agents working in parallel, each gathering one piece, rather than one agent gathering all three sequentially. This reduces total latency from the sum of all sub-tasks to the duration of the longest one. Parallelism only works for truly independent sub-tasks, but when it applies, it can dramatically reduce time to completion.

Architectures

Multi-agent systems use one of three main coordination patterns: hierarchical, collaborative, and pipeline.

Hierarchical (manager-worker): A coordinator agent receives the task, decomposes it into sub-tasks, delegates each sub-task to a specialist agent, and synthesizes the results into a final output. The coordinator is the only agent that sees the full picture, the specialist agents see only their sub-task. This is the most common pattern and the one used by frameworks like CrewAI. It works well when the task has a clear decomposition and the coordinator can judge the quality of each specialist's output. The coordinator does not need to be the smartest model, it needs to be good at task decomposition and result synthesis, which are different skills from deep execution.

Collaborative (peer-to-peer): Agents communicate directly with each other without a central coordinator. Each agent processes a message, produces its contribution, and passes it to the next agent or back to the group. AutoGen uses this pattern, framing multi-agent interactions as conversations where agents talk to each other. Collaborative systems are more flexible than hierarchical ones, they can handle tasks where the decomposition is not clear upfront, because agents can negotiate and adjust as the conversation progresses. The downside is that they are harder to control and can produce longer, more expensive conversations as agents go back and forth.

Pipeline (sequential handoff): Each agent performs one stage of processing and hands off to the next, like an assembly line. Agent A does research, passes findings to Agent B for analysis, which passes results to Agent C for report writing. This is the simplest multi-agent pattern and works well when the task has a natural sequential structure. The downside is that errors in early stages propagate forward, and there is no feedback loop for later agents to ask earlier ones for more information. Adding feedback (allowing Agent C to send Agent A back for more research) turns the pipeline into a more flexible architecture.

Communication and Context Sharing

The hardest engineering problem in multi-agent systems is how agents share information. Each agent has its own context window, and information that one agent discovers needs to reach the agents that depend on it. There are three approaches: message passing, shared memory, and artifact passing.

Message passing: Agents communicate by sending structured messages to each other, typically through the coordinator or through a shared message bus. The advantage is that each agent controls what it shares, keeping its context clean. The disadvantage is that information can be lost if an agent fails to include something relevant in its message. Message passing works best when the handoffs between agents are well-defined and the information that needs to cross boundaries is structured and predictable.

Shared memory: All agents read from and write to a shared memory layer. When the research agent discovers a relevant fact, it writes it to shared memory, and the analysis agent can retrieve it when needed. This is more flexible than message passing because agents do not need to predict what other agents will need, they just store what they find. Adaptive Recall can serve as this shared memory layer, storing facts with context, relevance scores, and confidence ratings so that any agent in the system can query for the information it needs. The guide to sharing memory between agents covers this pattern.

Artifact passing: Agents produce artifacts, such as documents, code files, data tables, or structured outputs, and pass them to the next agent as files or structured data rather than as natural language. This is the most reliable method for transferring complex information because the artifact preserves exact details that would be lost or distorted in a natural language summary. A coding agent produces a code file, a testing agent receives the file and runs tests, a review agent receives the file and the test results. The artifact is the communication medium.

Failure Handling Across Agents

Single-agent failures are local: the agent retries, adjusts, or stops. Multi-agent failures can cascade: one agent's failure blocks others that depend on its output, produces bad data that corrupts downstream reasoning, or creates an inconsistent state where some agents have completed their work and others have not. Designing for these failures is what separates a demo multi-agent system from a production one.

The first defense is isolation: each agent should be designed so that its failure does not crash the entire system. If the research agent fails to find data from one source, the system should continue with data from the other sources rather than halting. This means agents should return structured results that include both data and status, so the coordinator can distinguish between "no results found" and "the agent crashed." The coordinator then decides how to proceed: retry the failed agent, skip it and work with partial data, or escalate to a human.

The second defense is idempotency: if an agent is retried, running it again with the same inputs should not produce duplicate side effects. A coding agent that writes a file should overwrite rather than append. A data agent that inserts records should check for existing entries. Idempotent agents can be safely retried after failures, which makes the system more resilient because the coordinator can simply retry failed sub-tasks without worrying about creating inconsistencies.

The third defense is consensus checking: when multiple agents produce outputs that should be consistent (for example, three research agents each finding the revenue of the same company), the coordinator should compare results and flag contradictions rather than blindly merging. If Agent A reports revenue of $4.2 billion and Agent B reports $3.8 billion, the coordinator should not average them, it should investigate the discrepancy, typically by asking a validation agent to check both sources. This consensus step catches errors before they reach the final output.

When Multi-Agent Is Worth the Complexity

Multi-agent systems are significantly more complex than single agents. You need to design the decomposition, build the coordinator, handle communication between agents, manage failures in any sub-agent, and pay for multiple model calls per sub-task on top of the multiple calls each agent already makes internally. This complexity is only justified when the task genuinely benefits from specialization, parallelism, or context isolation.

A good rule of thumb: if a single agent can complete the task within 15 iterations and the context window does not overflow, use a single agent. Multi-agent systems earn their complexity when the task has 3 or more distinct phases that require different tools, when the total work would exceed a single agent's context window capacity, when independent sub-tasks can run in parallel for a latency improvement, or when the quality of specialist agents measurably exceeds that of a generalist agent on each sub-task.

The most common mistake is reaching for multi-agent architectures too early. A single agent with well-designed tools and good context management handles the vast majority of practical tasks. Multi-agent systems are the right tool for genuinely complex workflows, like a code review pipeline, a research synthesis engine, or a customer service system with specialized domain agents, not for tasks that a single focused agent can handle. The orchestration patterns guide covers the engineering decisions for systems that genuinely need multiple agents.