Multi-Agent Orchestration: Patterns That Work (and 3 That Don't)

The 17x Error Problem

In December 2025, a Google DeepMind team led by Yubin Kim ran the most rigorous evaluation of multi-agent architectures to date. They tested 180 configurations across 5 agent architectures and 3 LLM families. The headline finding: when agents are thrown together without structured topology, each agent's output becomes the next agent's input, and errors compound through every handoff.

The amplification factor hit 17.2x in the worst configurations. Not 17% worse. 17 times worse. A system of agents produced 17 times more errors than a single agent doing the same work.

This is the "bag of agents" anti-pattern: multiple LLMs thrown at a problem without a formal topology. No hierarchy. No gatekeeper. No compartmentalized information flow. Every agent has an open line to every other agent, and the system degrades as you add more.

The fix is structure. A centralized control plane suppresses the error amplification. Anthropic's multi-agent research system, using a structured orchestrator-worker pattern with Claude Opus 4 coordinating Sonnet 4 subagents, outperformed single-agent Opus 4 by 90.2%. Same models. Different topology. Opposite outcomes.

Separately, analysis of enterprise multi-agent deployments found that 41-87% fail in production. Nearly 79% of those failures originate from specification and coordination issues, not from model capability. The model is usually fine. The topology is broken.

Five Patterns That Work

Production multi-agent systems converge on five topologies. Each solves a specific coordination problem. The right choice depends on whether your tasks are decomposable, whether agents need to communicate, and how you want to handle failures.

1. Orchestrator-Worker (Fan-Out/Fan-In)

A central orchestrator analyzes the task, decomposes it into subtasks, fans them out to parallel workers, then aggregates results. This is the most common production pattern because it maps naturally to how humans delegate. The orchestrator acts as both planner and quality gate.

Anthropic's multi-agent research system uses this pattern. The lead agent spins up 3-5 subagents in parallel, each exploring different aspects of a query. Subagents use 3+ tools concurrently within their own execution. The lead agent synthesizes results into a final answer. Parallelization cut research time by up to 90% for complex queries.

┌─────────────────┐
│   Orchestrator   │   Plans, delegates, synthesizes
└──────┬──────────┘
       │ fan-out
  ┌────┼────┐
  ▼    ▼    ▼
┌───┐┌───┐┌───┐
│ W1 ││ W2 ││ W3 │   Workers execute in parallel
└─┬─┘└─┬─┘└─┬─┘
  │    │    │
  └────┼────┘
       │ fan-in
  ┌────▼────┐
  │ Aggregate│   Results merged by orchestrator
  └─────────┘

Best for: Decomposable tasks, code review from multiple
angles, research across multiple sources.
Latency: Bounded by slowest worker, not sum of all.
Cost: Each worker has own context, but scoped tightly.

2. Pipeline (Sequential Stages)

Agents process work in sequence. Stage 1 outputs become stage 2 inputs. Each stage transforms or enriches the data. This is the right choice when order matters and later stages depend on earlier outputs.

The weakness is latency. A 5-stage pipeline where each stage takes 8 seconds produces 40 seconds end-to-end. You cannot parallelize what is inherently sequential. But when stages are truly dependent, forcing parallelism just creates agents that block on each other, which is slower than a pipeline with less overhead.

┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐
│ Analyze  │──▶│  Plan   │──▶│  Code   │──▶│ Review  │
└─────────┘   └─────────┘   └─────────┘   └─────────┘

Best for: Code generation workflows (plan → implement →
review → test), data transformation chains, content
moderation pipelines.
Latency: Sum of all stages. No parallelism.
Cost: Lower per-stage because each agent gets a focused
context with just the previous stage's output.

3. Hierarchical (Tree Delegation)

A tree structure where managers delegate to specialized teams, who may delegate further. This is what Cursor discovered works for large codebases. Their January 2026 browser project (1 million lines, 1,000 files) tried equal-status agents with locking and optimistic concurrency. It failed. They succeeded with a three-role hierarchy: Planners continuously explore the codebase and create tasks. Workers execute assigned tasks without coordinating with each other. Judges determine whether to continue at each cycle end.

Hierarchical beats flat because the control plane contains error propagation. If a worker produces bad output, the manager catches it before it reaches other workers. With equal-status agents, bad output propagates freely. This is exactly the mechanism behind the 17.2x error amplification.

           ┌──────────┐
           │  Lead    │
           └────┬─────┘
          ┌─────┼─────┐
          ▼     ▼     ▼
       ┌─────┐┌─────┐┌─────┐
       │Mgr A││Mgr B││Mgr C│
       └──┬──┘└──┬──┘└──┬──┘
        ┌─┼─┐  ┌─┼─┐  ┌─┼─┐
        ▼ ▼ ▼  ▼ ▼ ▼  ▼ ▼ ▼
        W W W  W W W  W W W

Best for: Large codebases, enterprise systems with
multiple teams, projects requiring domain specialization.
Error containment: Managers filter worker errors before
propagating up. Suppresses the 17x amplification.
Cost: Higher due to manager overhead, but error
reduction usually makes net cost lower.

4. Debate (Adversarial Verification)

Multiple agents argue opposing positions. A judge agent evaluates the arguments and synthesizes a conclusion. This works for decisions where single-agent confidence is unreliable: architecture choices, security reviews, debugging hypotheses.

LLMs suffer from anchoring bias. Once a single agent commits to a theory, subsequent reasoning is biased toward confirming it. Two agents assigned opposing positions explore the solution space more thoroughly than one agent instructed to "consider alternatives." The cost is 3 agents minimum (two advocates plus a judge), but for high-stakes decisions where being wrong is expensive, that cost is trivial.

┌───────────┐     ┌───────────┐
│  Agent A  │◄───▶│  Agent B  │
│ (for X)   │     │(against X)│
└─────┬─────┘     └─────┬─────┘
      │                 │
      └────────┬────────┘
          ┌────▼────┐
          │  Judge  │   Evaluates both positions
          └─────────┘

Best for: Architecture decisions, security audits,
root cause analysis, technology selection.
Rounds: 2-3 rounds of argument typically sufficient.
Cost: 3 agents minimum. Worth it when being wrong
costs more than the agents.

5. Swarm (Self-Coordinating)

Agents coordinate through shared state without a central controller. Each agent reads from and writes to a shared task board, claiming work autonomously. No single point of failure. No bottleneck at the orchestrator.

This is Claude Code Agent Teams' model. Teammates share a task list with dependency tracking, claim tasks independently, and message each other directly via SendMessage. It works because the shared state (JSON task files) provides implicit coordination without requiring every message to route through a central node.

The caveat: swarms need explicit termination conditions. Without an orchestrator deciding when to stop, agents need max iterations, quality thresholds, or timeout-based convergence. Most swarm failures come from agents that never stop rather than agents that produce bad output.

┌────┐ ┌────┐ ┌────┐ ┌────┐
│ A1 │ │ A2 │ │ A3 │ │ A4 │
└──┬─┘ └──┬─┘ └──┬─┘ └──┬─┘
   │      │      │      │
   └──────┼──────┼──────┘
     ┌────▼──────▼────┐
     │  Shared State  │   Task board, message bus
     │  (task files)  │
     └────────────────┘

Best for: Tasks with many independent work items,
open-ended exploration, research with unknown scope.
Risk: No termination guarantee without explicit
conditions (max iterations, quality thresholds).
Cost: Scales with agent count. Monitor for agents
claiming work outside their scope.

Three Patterns That Don't Work

These three anti-patterns appear in nearly every failed multi-agent deployment. They share a common mistake: assuming more agents means better results without accounting for how those agents interact.

Why "Just Add More Agents" Fails

The intuition that more agents means more throughput comes from human teams, where adding people to independent tasks scales linearly. But agent coordination is qualitatively different from human coordination. Humans share background context implicitly through shared culture, shared workspace, and overheard conversations. Agents share nothing unless you explicitly provide it.

Every piece of context an agent needs must be placed in its context window or communicated via messages. When Agent A discovers that a function was renamed and Agent B does not know, Agent B produces code referencing the old name. With humans, this is caught in a hallway conversation. With agents, it is caught at compile time if you are lucky, or in production if you are not.

Augment Code documented this across enterprise deployments: most multi-agent failures are not catastrophic. They are close. A missing model field. A broken import. An unhandled error case. The code is 90% right, which makes it harder to catch than code that is obviously wrong. Structured topology prevents these subtle failures by controlling what information flows where.

Framework Comparison

Seven frameworks compete for multi-agent orchestration in 2026. Each encodes different assumptions about how agents should coordinate. The architecture determines which patterns are natural to express, not just which are possible.

LangGraph: Graph-Based Control

LangGraph models agent workflows as directed acyclic graphs. Each node is an operation or agent action. Edges define control flow and data flow. This makes it suited for any topology you can draw as a graph, which is all of them. The trade-off is complexity: you are building a state machine, not configuring a framework.

The distinguishing feature is built-in checkpointing with time travel. You can replay agent execution from any point. For debugging multi-agent systems where you need to understand exactly where coordination broke down, no other framework provides this level of execution introspection.

CrewAI: Roles Over Graphs

CrewAI operates like a scripted play. Agents take turns executing roles under the Crew's direction, maintaining structured, cumulative knowledge throughout the workflow. It supports sequential and hierarchical processes natively. The mental model is closer to defining a team than writing code.

The limitation surfaces at scale. CrewAI's execution pipeline iterates through tasks linearly, which means true concurrent execution requires workarounds. For teams under 5 agents with well-defined roles, it is the fastest path from idea to working system. For complex topologies or dynamic task decomposition, LangGraph offers more control.

OpenAI Agents SDK: Minimal Abstraction

The lightest option. Agents hand off to each other explicitly, using context variables for ephemeral state. Swarm, its predecessor, was stateless by design. The Agents SDK adds guardrails and tracing but keeps the same philosophy: simple handoffs, minimal framework surface area.

Best for fan-out patterns where you dispatch work to specialized agents and collect results. Not ideal for long-running workflows requiring persistent state across agent interactions.

Coding-Specific Orchestrators

Claude Code Agent Teams and Codex CLI are not general-purpose frameworks. They are orchestrators purpose-built for code. The critical difference is git worktree isolation: each agent gets its own working directory so parallel file edits never collide. General frameworks like LangGraph and CrewAI do not provide this. You would need to build it yourself, and getting concurrent file access right is harder than it looks.

If your multi-agent system writes code, this distinction matters more than any framework feature comparison. File-level isolation is a prerequisite for parallel code generation that does not corrupt the repository.

Cost Model

The naive cost model says multi-agent is always more expensive: N agents means N context windows means Nx the tokens. This is wrong in practice because it ignores scope isolation.

When a single agent handles a complex task, it loads the full problem context into one window. Code files, documentation, conversation history, tool outputs. With 200K-token models, accuracy drops measurably once context utilization exceeds 60-70% of the window, especially for retrieval tasks positioned in the middle. The agent starts hallucinating, which means wasted tokens on wrong outputs that need regeneration.

Multi-agent scope isolation fixes this. Each agent gets a focused slice of the problem. Per-agent token consumption drops 60-70% compared to the monolithic approach. A 3-agent system can process 67% fewer total tokens than a single agent because each agent's context stays high-signal.

The breakeven depends on task complexity. For simple tasks (a bug fix in one file), single-agent is always cheaper. Zero coordination overhead, minimal context needed. For tasks requiring 50K+ tokens of context, multi-agent scope isolation starts winning because accuracy gains from focused context reduce retry costs.

The Search Subagent Example

Cognition measured that agent trajectories spend over 60% of their first turn just retrieving context. This is the expensive model burning tokens on search instead of code. Splitting retrieval into a specialized subagent means the expensive model spends fewer tokens on search and more on its actual job.

The numbers from SWE-Bench Pro: when Opus 4.6 is paired with WarpGrep v2 as a search subagent, it reaches 57.5% while cutting cost by 15.6% and time by 28%. A cheaper, RL-trained model handles search in its own context window. The expensive model handles reasoning in its own. Total cost goes down because the expensive model processes fewer tokens.

This is the multi-agent cost model at its clearest: cheaper models doing expensive-model work at lower quality is wasteful. Expensive models doing cheap-model work is equally wasteful. Orchestration lets you match model capability to task requirements per agent.

Real-World Architectures

Theory collapses without evidence. Here are four multi-agent systems built for production and what they reveal about orchestration in practice.

Cursor's FastRender: Hierarchical After Flat Failed

Cursor's January 2026 browser project was 1 million lines of code across 1,000 files. They started with equal-status agents using locking and optimistic concurrency control. Agents stepped on each other's output, context coordination spiraled, errors propagated between peers.

The architecture that worked: three roles. Planners continuously explore the codebase and create tasks. Workers execute assigned tasks without coordinating with each other and push changes when done. Judges determine whether to continue at each cycle end. Textbook hierarchical orchestration, arrived at only after flat orchestration failed on a real codebase.

Anthropic's Research System: Orchestrator-Worker at Scale

Anthropic's multi-agent research system uses Claude Opus 4 as the lead agent coordinating Claude Sonnet 4 subagents. When a query arrives, the lead develops a strategy and spawns 3-5 subagents to explore different aspects in parallel. Each subagent uses 3+ tools concurrently. Results aggregate back to the lead for synthesis.

The 90.2% improvement over single-agent Opus 4 came from one key design choice: using a cheaper model (Sonnet 4) for the workers. The expensive model only plans and synthesizes. Worker tasks are scoped tightly enough that the cheaper model handles them well. This is the cost model in action: the orchestrator-worker pattern enables model-task matching that a single agent cannot.

16-Agent C Compiler: Swarm Coordination

16 Claude agents built a 100,000-line C compiler in Rust that compiles the Linux kernel 6.9, passing 99% of GCC torture tests. Cost: approximately $20,000. This worked as a swarm because agents needed to coordinate on shared type systems, calling conventions, and test results in real time. A pure orchestrator-worker pattern would have bottlenecked at the orchestrator. The swarm's shared state let agents broadcast discoveries (like a new type definition) that multiple other agents needed immediately.

Morph's SEO Pipeline: Hybrid Architecture

Morph's 22-agent SEO pipeline uses a hybrid. Research tasks (gathering data, analyzing competitors) run as orchestrator-worker with subagents. Page generation uses agent teams because agents writing different sections need to coordinate on shared components, consistent data, and cross-references. The pipeline stage between research and generation is sequential by necessity: you cannot write a page before the research is complete.

The lesson: real systems combine patterns. Orchestrator-worker for embarrassingly parallel subtasks. Pipeline for sequential dependencies. Swarm for tasks requiring real-time coordination. The best architecture is usually a hybrid, not a single pattern applied everywhere.

Choosing a Pattern

Four questions determine which orchestration pattern fits your task. Answer them in order.

Per-Agent Infrastructure

Every agent in a multi-agent system needs three capabilities: search the codebase, generate edits, and apply those edits to files. In a single-agent system, these are bundled together. In a multi-agent system, they need to work independently per agent, in parallel, without stepping on each other.

The Search Problem

When 5 agents all need to search the same codebase simultaneously, each one needs to find different files relevant to its specific task. Generic search (grep, find) loads too many irrelevant files, wasting context. A search subagent running in its own context window solves this by returning only high-signal results to the calling agent.

Cognition's data: agents spend 60%+ of their first turn on retrieval. With a dedicated search subagent like WarpGrep, that overhead shifts to a cheaper model while the primary agent focuses on reasoning. This is per-agent infrastructure: the search capability is isolated so it does not pollute the primary agent's context.

The Apply Problem

Multi-agent orchestration produces more code changes in parallel than single-agent workflows. Each change needs to merge cleanly into the codebase. When 5 agents each produce a diff, you need 5 reliable apply operations, each running against the correct file state.

Git worktrees solve file isolation. Each agent works in its own directory. But the apply step itself (taking an LLM-generated edit and merging it into existing code) is a context engineering problem. The apply model needs three things: the original file, the edit intent, and the update snippet. Too little context and the merge fails. Too much and the model gets confused.

Morph's Fast Apply model is purpose-built for this: instruction + code + update in, merged file out at 10,500+ tok/s. By isolating the merge in a specialized model, each agent's primary context window stays clean for planning and reasoning. When 5 agents generate edits in parallel, the reliability of the apply step determines whether the orchestration produces working code or a broken repository.

The Context Problem

Each agent needs exactly the context relevant to its task. Not more. CLAUDE.md provides shared project context. Spawn prompts provide agent-specific context. The search subagent provides just-in-time file content. The combination keeps each agent's context window focused and high-signal.

This is where per-agent infrastructure connects to cost. Focused context means fewer tokens per agent. Fewer tokens means lower cost. Lower cost means you can run more agents. More agents with focused context means better results. The virtuous cycle only works when the infrastructure supports per-agent isolation.

Frequently Asked Questions

What is multi-agent orchestration?

Multi-agent orchestration is the design of how multiple AI agents coordinate, communicate, and share work on a task. It encompasses topology selection (hierarchical, pipeline, fan-out/fan-in, debate, or swarm), communication protocol design, shared state management, and failure handling. Google DeepMind research found that the topology choice matters more than the model or framework, with unstructured systems amplifying errors up to 17.2x.

What are the main orchestration patterns?

Five patterns work in production. Orchestrator-Worker (fan-out/fan-in) delegates to parallel workers and aggregates. Pipeline processes sequentially. Hierarchical uses a tree of managers and workers. Debate has agents argue opposing positions before a judge. Swarm agents self-coordinate through shared state. Most production systems use hybrids that combine two or three patterns within a single workflow.

Why do multi-agent systems fail?

Three patterns reliably fail. The "bag of agents" (no formal topology) amplifies errors 17.2x. Flat mesh at scale (everyone talks to everyone) breaks past 5-6 agents due to N-squared communication paths. Eager parallelism on sequential tasks wastes tokens while agents wait on each other. Across enterprise deployments, 79% of failures originate from coordination issues, not model capability.

How does multi-agent orchestration affect cost?

For simple tasks, single-agent is always cheaper. For complex tasks requiring 50K+ tokens of context, multi-agent scope isolation reduces per-agent token consumption by 60-70%, often making total cost lower despite running multiple agents. When Opus 4.6 uses WarpGrep v2 as a search subagent, cost drops 15.6% while performance increases because the expensive model spends fewer tokens on search.

Which framework should I use?

If your agents write code, start with Claude Code Agent Teams or Codex CLI for built-in git worktree isolation. If your agents process data or make decisions, use CrewAI for fast prototyping or LangGraph for full control over the execution graph. If you need multi-vendor agent interop, look at Google's A2A protocol and ADK. Match the framework to the coordination pattern.

How many agents should I start with?

Three. Research consistently shows that 3 focused agents outperform 5 scattered ones. Start with 3, give each 5-6 tasks, and scale up only when work genuinely benefits from more parallelism. Flat topologies break past 5-6 agents. If you need more, add a management layer (hierarchical pattern) rather than adding more peers.