Multi-Agent Systems
Multi-agent patterns
Supervisor, hierarchical, swarm
More agents is not more intelligence - it is more tokens, more coordination, and more ways to fail. This lesson gives you the honest economics of single vs multi-agent, a gallery of the ten canonical patterns, and a decision rule for reaching past one agent only when the task actually demands it.
Start with one agent
Before you draw an org chart of agents, learn the line Anthropic draws through the whole space. Everything is built from one primitive - the : a model wired to retrieval, tools, and memory, generating its own queries and choosing its own tools.[1] How you wire those primitives together splits into two architectures.
Workflows
Agents
Most production value comes from the simpler box. Multi-step agentic systems buy better task performance at the cost of latency and money, so Anthropic's central rule is blunt: "Find the simplest solution possible, and only increase complexity when needed."[1] Treat architecture as an escalation ladder - climb one rung only when the rung below demonstrably fails.
- A single augmented LLM call with good retrieval and in-context examples. Try this first - many tasks need nothing more.[1]
- A workflow (chaining / routing / parallelization / evaluator-optimizer) when the control flow is knowable and fixed.
- A single autonomous agent - one loop, many tools - when steps are unpredictable but the work is coherent and mostly single-threaded.
- Orchestrator-workers / supervisor multi-agent only when the task is valuable, heavily parallelizable, exceeds one context window, or needs isolated sub-contexts.
- Hierarchical only when a single supervisor has too many workers to manage.
The default is one
When multiple agents help - and when they hurt
This is a real, unresolved-until-recently debate, so learn both sides honestly.
The case FOR (Anthropic)
Anthropic's multi-agent Research system - an orchestrator-worker design with a Claude Opus 4 lead spawning Claude Sonnet 4 subagents - outperformed a single-agent Opus 4 baseline by 90.2% on an internal research eval, especially on breadth-first queries that require pursuing several independent directions at once (e.g. "find a new board member for every S&P 500 IT company").[3] The mechanism is not magic - subagents give the system more total context spread across many parallel context windows, sidestepping the single-window ceiling.
But that power has a price tag, and the price is tokens. On their BrowseComp eval, token usage alone explained about 80% of performance variance; adding tool-call count and model choice pushed it to about 95%.[3] Multi-agent is fundamentally a way to spend far more tokens, in parallel, than one agent can.
| Setup | Relative token burn |
|---|---|
| Chat | 1x |
| Single agent | ~4x a chat |
| Multi-agent | ~15x a chat |
The case AGAINST (Cognition)
Cognition's Walden Yan published the sharpest counterpoint, "Don't Build Multi-Agents," resting on two rules of context engineering: (1) share full agent traces, not just messages, and (2) actions carry implicit decisions, and conflicting implicit decisions produce broken results.[4] Their worked example makes it visceral.
The conflicting-writers trap
And the skeptics have data. The Berkeley MAST study annotated 200+ tasks across 7 popular multi-agent frameworks and found that gains over single-agent baselines are frequently minimal, with failures clustering into three buckets: 41.8% specification & design, 36.9% inter-agent misalignment, 21.3% verification. The single most common failure mode was step repetition (17.1%).[5] The lesson: multi-agent failures are organizational, not just model-capability, problems.
Multi-agent HELPS when
The 2026 reconciliation
The pattern gallery
Here are the ten canonical patterns, ordered from least to most autonomy. The first five are Anthropic's composable workflows (fixed code paths); the sixth is the single autonomous agent; the last four are true multi-agent topologies (how two-or-more agents wire together).[1][2]
Workflows - fixed, human-written control flow
| Pattern | Shape | Use when |
|---|---|---|
| 01 Prompt chaining | LLM calls in a fixed sequence with validation gates between them | the task cleanly decomposes into a fixed sequence and you will trade latency for accuracy - draft an outline, gate-check it, then write the doc. |
| 02 Routing | a classifier dispatches input to one of several specialized handlers | inputs fall into distinct categories better handled separately - refund vs technical vs general, or cheap-model vs strong-model by difficulty. |
| 03 Parallelization | one input fans out to parallel workers whose outputs are aggregated | independent subtasks run concurrently for speed (sectioning), or the same task runs many times for confidence (voting) - e.g. a guardrail model beside the answer model. |
| 04 Orchestrator-workers | a central orchestrator spawns worker LLMs decided at runtime | you cannot predict the subtasks in advance - their number and shape depend on the input. The orchestrator decomposes, delegates, then synthesizes. |
| 05 Evaluator-optimizer | a generator and an evaluator loop until the output is good enough | clear evaluation criteria exist and iterative refinement measurably helps - literary translation, or multi-round research where a critic decides if more searching is needed. |
| 06 Autonomous agent | a single agent loops over tools until a stopping condition | the problem is open-ended and you cannot predict the step count, but the work is coherent and mostly single-threaded. Needs strong guardrails. |
Notice that pattern 04 (orchestrator-workers) and the supervisor topology below are the same idea at two altitudes: the workflow decides subtasks at runtime for one task; the topology makes that a persistent, reusable multi-agent structure.[2]
Topologies - how true agents wire together
The supervisor is the productionized orchestrator-worker: one hub receives everything, dispatches to a specialist, reads the result, and either calls the next or returns.
Tap a node to see what it does.
| Topology | Shape | Use when |
|---|---|---|
| 07 Supervisor | a hub supervisor with bidirectional spokes to surrounding workers | you want the productionized orchestrator-workers - one hub owns the plan. Clear and debuggable, but the hub is a bottleneck. |
| 08 Hierarchical | a top supervisor over mid-level supervisors, each with their own workers | a single supervisor manages too many workers. Group them into teams under mid-level supervisors - an org chart for agents. |
| 09 Network / swarm | peer agents in a mesh, each able to hand off to any other, no central coordinator | peer specialists should hand the baton directly to each other. Fewer LLM calls than a supervisor, but harder to reason about and prone to loops. |
| 10 Sequential | distinct role agents in a fixed deterministic pipeline | distinct specialist agents each own one stage of a known pipeline, wired with deterministic code edges - unlike chaining, each node is its own agent. |
Tap a node to see what it does.
Picking a pattern
The whole gallery collapses into one decision: match the structure of the task to the structure of the pattern, and stop climbing the moment a pattern is good enough.
| If the task... | reach for |
|---|---|
| has a fixed, known sequence of steps | Prompt chaining (add validation gates) |
| splits into distinct input categories | Routing (classify, then dispatch) |
| has independent subtasks, or needs a second look | Parallelization (sectioning / voting) |
| has subtasks you cannot predict up front | Orchestrator-workers / supervisor |
| has clear critique criteria and iteration helps | Evaluator-optimizer (generate to critique) |
| is open-ended with an unknown step count | Single autonomous agent |
| overloads one supervisor with workers | Hierarchical (teams under teams) |
| needs peers to hand off with no hub | Network / swarm |
The one rule that governs all of them
The mechanics of transferring control between these agents - handoffs vs agents-as-tools, shared vs separate state, LangGraph's Command primitive - are the whole of the next lesson. And whatever you build, start from the raw LLM API before adopting a framework: frameworks speed up standard cases but add abstraction layers that "obscure the underlying prompts and responses, making them harder to debug."[1]
Check yourself
Match each topology to its defining trait.
one coordinator dispatches to workers
supervisors nested over sub-teams
peers hand off with no central boss
When does adding more agents most reliably pay off despite the ~15x token cost?
State Cognition's two rules of context engineering, and the 2026 rule for when extra agents are safe.
Who ends up doing the mutating work? Try to state it, then check.
Lock it in
- One agent is the default. Climb the escalation ladder - call, workflow, single agent, multi-agent - only when the rung below demonstrably fails.
- Multi-agent is a token-spending mechanism. About 15x a chat; token use alone explained about 80% of Anthropic's performance variance. It pays off only for valuable, parallelizable work.
- Breadth-first and read-only wins; tightly-coupled writing loses. Anthropic's +90.2% research system and Cognition's Flappy Bird failure are the two poles.
- Match task shape to pattern shape. Fixed steps to chaining; categories to routing; unknown subtasks to orchestrator; too many workers to hierarchical.
- Writes single-threaded, intelligence parallel. The 2026 consensus that reconciles both camps.
Primary source
Anthropic, Building Effective AgentsThe canonical taxonomy this lesson is built on: the workflow/agent distinction, the augmented-LLM primitive, and the five composable patterns. Read it once and the whole gallery clicks. Pair it with Anthropic's empirical companion, "How we built our multi-agent research system," for the +90.2% result and the token economics.
Sources