Multi-Agent Systems & Orchestration
When one agent isn't enough — how orchestrators, specialized subagents, and handoffs divide work among many agents.
A single agent loop is powerful, but it has limits: one context window, one line of reasoning, one thing at a time. Multi-agent systems break a big problem across several agents — each with its own context, tools, and focus — coordinated so the whole is more capable than any one part. Think of it as going from a solo contractor to a small team with a project lead.
Why more than one agent?
- Context isolation. Each subagent gets a fresh, focused context window, so deep work on one sub-task doesn’t crowd out everything else. This is often the single biggest reason to split.
- Parallelism. Independent sub-tasks (research three vendors, check five files) run at the same time instead of one after another.
- Specialization. A “coder” agent, a “reviewer” agent, and a “researcher” agent can each have tailored prompts and tools, and specialized behavior tends to beat one generalist prompt.
The trade-off: coordination overhead, more tokens, and harder debugging. Reach for multi-agent only when a single loop genuinely strains — not by default.
The dominant pattern: orchestrator → workers
The most common and reliable shape is a lead/orchestrator agent that plans the work and spawns worker/subagents for the pieces, then synthesizes their results.
Anthropic’s own multi-agent research system uses exactly this shape: a lead agent plans a research question, spins up subagents to investigate facets in parallel, and combines their findings — a design that outperformed a single-agent version on breadth-heavy research tasks, at the cost of using considerably more tokens.
Common coordination patterns
| Pattern | How it works | Good for |
|---|---|---|
| Orchestrator–workers | A lead delegates sub-tasks and synthesizes | Open-ended tasks that decompose (research, large refactors) |
| Sequential pipeline | Agent A’s output feeds agent B feeds C | Fixed multi-stage flows (draft → edit → fact-check) |
| Handoff / routing | One agent transfers control to a specialist | Triage — route a request to the right expert agent |
| Debate / review | Agents critique each other’s work | Higher-stakes outputs where a second opinion helps |
The hard parts
- Token cost. Multi-agent systems can use several times the tokens of a single agent — every subagent has its own prompt, tools, and reasoning. Make sure the task justifies it.
- Communication. Subagents share findings through messages or a shared scratchpad/memory. Passing too much re-creates the context-bloat problem you split up to avoid; passing too little means agents duplicate work or miss context.
- Error propagation. One confused subagent can poison the synthesis. The orchestrator needs to validate and, when needed, re-delegate.
- Emerging standards. Just as MCP standardized agent-to-tool connections, protocols for agent-to-agent communication (e.g. Google’s A2A) are emerging to standardize how independent agents talk.
When to use it
- Yes: breadth-heavy work that parallelizes (research across many sources, auditing many files), or clearly separable specialties (code + review + test).
- No: tightly sequential tasks where each step depends on the last — there’s nothing to parallelize, and a single well-run agentic loop with good context engineering is simpler, cheaper, and easier to debug.