Multi-agent systems are fashionable and usually wrong. Every agent you add to a design buys you two things you did not have before: a coordination problem and a new surface for errors to enter and hide. Neither improves the output. So the correct default is not a swarm, or a "crew," or a manager delegating to a team of specialists — it is the smallest number of agents the task's structure actually forces on you, which is very often one.
This is the opposite of how the field talks. The framing you see is additive: give each concern its own agent, wire them together, and let the collective be smarter than any part. That intuition is imported from human organizations, and it does not survive contact with how LLM agents actually communicate. Human specialists share a durable context and correct each other continuously. Two LLM agents share a text message and then forget the conversation. The handoff is the whole problem, and adding agents adds handoffs.
So the question worth answering is not "how do I orchestrate many agents" but "what specific structure in this task makes one agent insufficient." There are exactly four honest answers. If none of them applies, you are paying for complexity and getting nothing back.
Why extra agents cost more than they look like they cost
Start with the arithmetic, because it disciplines the whole discussion. The binding constraint on agents is that per-step success probabilities multiply — a 95%-reliable agent completes a 20-step task about 36% of the time, because 0.95²⁰ ≈ 0.358. I argued the full case for this in The Compounding-Error Problem; here I only need the shape of it. Reliability is a product of terms less than one, and products shrink fast.
A handoff between agents is one of those terms — and usually a bad one. When agent A finishes and passes to agent B, it does not transfer its full internal state. It serializes what it did into a summary, and B re-grounds from that compressed snapshot. Information is lost at the boundary, and worse, the loss is silent: B cannot tell what A knew but failed to write down. So every inter-agent handoff is both a reliability term below 1.0 and a place where an error becomes invisible to the rest of the system. Walden Yan of Cognition made this argument sharply in "Don't Build Multi-Agents" — that fragile context transfer between parallel subagents is the dominant failure mode, and that a single-threaded agent holding one coherent context often beats a team precisely because nothing has to be re-serialized across a boundary.
There is a second cost that is easy to miss until you are debugging at 2 a.m.: nondeterminism compounds across agents in a way it does not within one. A single agent's trace is a line you can read top to bottom. A multi-agent system's behavior is an interaction between several stochastic processes whose relative timing and message ordering vary run to run. The same inputs produce different failures. You cannot reproduce the bug, so you cannot fix it — you can only add more logging and hope. This is not a tooling gap that will be patched. It is intrinsic to putting nondeterministic components in a loop with each other.
And there is a token cost that is embarrassingly literal. Anthropic reported that their multi-agent research system consumed roughly fifteen times the tokens of a single-agent chat interaction, and was worth it only for high-value tasks whose subtasks genuinely parallelized. That is the honest baseline: a multi-agent design should be assumed to cost about an order of magnitude more, and should be adopted only when the structure returns more than that in value.
So the burden of proof sits on the extra agent. It has to earn its handoff. Here is when it does.
The four structures that justify more than one agent
| Structure | What one agent can't do | The multi-agent shape |
|---|---|---|
| Parallel independent subtasks | Run N things at once; latency is serial | Fan out, then join |
| Independence adds signal | Catch its own blind spot | Generator + independent verifier / adversary |
| Genuine role separation | Hold two tool sets / permission scopes / contexts at once | Specialists with different capabilities |
| Chain too long to be reliable | Stay reliable across a long horizon | Short verified segments behind checkpoints |
1. The work is genuinely parallel
If a task breaks into subtasks that do not depend on each other's outputs, running them concurrently is a real win — and it is the cleanest case for multiple agents, because parallel workers that never talk to each other have no handoffs between them to lose information. Fan out K independent search or research threads, let each explore, then join their results in one place.
The load-bearing word is independent. The moment subtask B needs subtask A's output, you no longer have parallelism; you have a sequence you have disguised as a swarm, and now the workers must coordinate mid-flight — race conditions, stale reads, and the exact silent-handoff problem above. The test is concrete: can you shuffle the subtasks into any order, or run them on separate machines that never communicate, and still get the right join? If yes, parallelize. If the answer requires a caveat, it is sequential, and one agent working the sequence will beat a team fighting over shared state.
2. Independence adds signal — verification and adversarial roles
A single agent is a poor judge of its own work, and not for lack of intelligence. The reasoning that produced an error is the same reasoning you would ask to check for it, so blind spots are systematically shared between the generation and the review. Separating the roles into two agents breaks that correlation: an independent verifier, or an adversary explicitly tasked with attacking the first agent's output, brings a different context and a different objective, and so can catch failures the generator cannot see in itself.
This is the strongest philosophical case for multiplicity, and it is old. It is the logic of adversarial review in science — the reason Popper made refutation, not confirmation, the engine of knowledge. You do not certify a claim by asking its author whether they believe it; you expose it to someone whose job is to break it. The independence is the entire point. Which is also the failure mode to watch: if your "verifier" shares the generator's context, prompt, and model temperament, it will share its blind spots too, and you have bought a rubber stamp at double the token cost. The verifier must be genuinely independent — ideally a different context window, and where it matters, a different model — or it is theater.
3. Roles need different tools, permissions, or contexts
Some separations are real because the capabilities are real. An agent that reads production data and an agent that can execute writes should not be the same agent, because you want the permission boundary to be enforced by the system, not by a prompt asking nicely. An agent whose context is a 200-page codebase and an agent whose context is a customer's PII should not share a window, because you do not want either concern leaking into the other's reasoning. When roles differ in what they can touch — distinct tools, distinct credentials, distinct data — separating them into agents makes the boundary architectural.
The trap here is calling a prompt difference a role difference. Two "agents" that use the same tools, hold the same context, and differ only in their system prompt are one agent wearing two hats, and you are paying two round-trips to simulate what a single agent does natively when you tell it to switch modes. Role separation earns an agent only when the capabilities, not just the instructions, are actually different.
4. The chain is too long to be reliable in one pass
This is the reason people reach for multi-agent that is almost right, and it deserves care because it is easy to over-apply. A 100-step chain at 99% per step succeeds 37% of the time. You cannot run that as one unbroken agentic loop and expect it to land. The fix is to cut the chain into short segments and verify at the boundaries, so an error is caught and corrected before it propagates instead of silently poisoning the remaining 80 steps.
But notice what that fix actually requires: decomposition and checkpoints. It does not automatically require multiple agents. You can run short verified segments inside a single agentic loop, checkpointing between them, and get most of the benefit with none of the handoff loss. You cross into genuine multi-agent territory only when a segment needs something the single loop cannot give it — a clean context window free of the accumulated cruft of the earlier segments, a different tool set, or an independent verifier of the kind in reason (2). Split the chain first. Add an agent only where the split needs a wall.
The checklist
Before you add the second agent, four questions. If every answer is no, build one agent.
- Is the work genuinely parallel? Can the subtasks run in any order, or on machines that never talk, and still join correctly? Independent subtasks earn a fan-out. A disguised sequence does not.
- Does independence add signal? Would a separate context catch errors the first agent shares with itself — verification, red-teaming, adversarial review? Genuine independence earns a second agent. A same-context rubber stamp does not.
- Do roles need different capabilities? Distinct tools, permissions, or data — enforced, not prompted? A real capability boundary earns a specialist. A prompt difference does not.
- Is the chain too long to be reliable as one pass? And if so — does it need a second agent, or just decomposition and checkpoints inside one loop? Add the agent only where a segment needs isolation the loop can't provide.
Each "yes" should point at a specific structure, not a vibe. "It feels cleaner to separate concerns" is not a structure. "The verifier must not share the generator's context or its blind spots go uncaught" is.
The part nobody budgets for
Suppose you clear the checklist honestly and the task really does need three agents. You are not done deciding — you are at the start of the hard part. Something has to route work between those agents, decide when a subtask is finished, detect when one has gone off the rails, and reconcile their outputs. That coordinator is itself an agent, usually the least reliable one in the system, and its failures are the hardest to diagnose because they are failures of a stochastic process supervising other stochastic processes. I treat this as its own problem in The Orchestrator Problem, because it is where most multi-agent systems that pass the checklist still die.
Which sharpens the default rather than softening it. Every agent you add does not cost you one unit of complexity; it costs you the handoffs into it, the handoffs out, its share of the nondeterminism, and a slice of the orchestrator's job. The swarm was never free. The question was only ever whether the task's structure pays for it — and most of the time, if you are honest about the four reasons, it doesn't.
Count the agents your structure forces on you. Then build one fewer than you were about to.