Describe the conditions under which a multi-agent architecture outperforms a single agent system, and the conditions under which it degrades performance. What is the key structural property of the task that determines which is better?
Multi-agent wins when sub-tasks are parallelisable, isolate context, or need specialists. It hurts when they form a dependency chain, paying coordination tax for zero concurrency gain.
Imagine writing a research report. If three sections can be researched at the same time, you hand each to a different person and finish in a third of the time. That is multi-agent, and it works because the work splits cleanly. Now imagine a report where each section needs the conclusion of the one before it. Handing it to three people does not help, because person two cannot start until person one finishes. You have just added meetings, handoffs, and confusion for no speed gain. One careful person would have done it faster. AI agents are the same. Splitting a task across many agents helps only when the pieces are truly independent. If the pieces depend on each other in a line, one well equipped agent is usually simpler, cheaper, and easier to debug.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
The single versus multi-agent decision is one of the most over-romanticised choices in agent engineering. Multi-agent systems sound sophisticated, so teams reach for them by default, often before they have a single working agent. The honest answer is that most problems are better solved by one well-equipped agent, and multi-agent only pays off under a narrow set of structural conditions that you should be able to name out loud before you commit.
The whole decision collapses to a single question about the task, not about the models. Do the sub-tasks decompose into pieces that are independent enough to run concurrently? If yes, multiple agents can buy real wall-clock reduction and let you route each branch to a specialist. If no, you are paying the full coordination cost for none of the concurrency benefit, and a single agent is simpler, cheaper, and far easier to debug.
The useful mental model is to treat a multi-agent system the way a distributed-systems engineer treats horizontal scaling. You add nodes only when one node is genuinely the bottleneck, because every node you add brings its own coordination, failure, and observability cost. The sections below work through the three conditions that justify the cost, the three costs you pay regardless, the structural property that decides the whole thing, and the pragmatic default that should be your starting point.
The three legitimate win conditions
Multi-agent earns its complexity on three structural conditions, and ideally more than one holds at once.
- Parallelism. When sub-tasks do not block each other, several agents run concurrently and the wall-clock time drops toward the longest single branch rather than the sum of all branches. A research task that fans out into five independent web searches is the canonical example. For five branches that each take thirty seconds, a fan-out finishes in roughly thirty seconds plus a merge step, where a single agent would spend two and a half minutes walking them in sequence.
- Specialisation. When a sub-task is meaningfully better served by a different model, a specialist agent beats a generalist. A code-tuned model for review, a domain fine-tuned model for medical text, or a cheap fast model for routing while an expensive model handles synthesis. The bar here is a measurable quality delta, not a hunch. If a specialist only edges out the generalist by a point or two, the cost of maintaining and orchestrating a second model rarely repays itself.
- Context isolation. When the combined transcript would overflow the reliable context window, or dilute attention so the model loses track of the goal, giving each agent a narrow scope keeps its reasoning sharp. This is the condition people most often overlook, because it can justify a split even when there is no parallelism at all.
The critical caveat is that parallelism is a property of the task graph, not a property of having many agents. You only harvest it when the branches are genuinely independent. Spawning ten agents on a task whose steps must run in order does not give you a tenfold speedup. It gives you ten agents taking turns, plus the cost of the turn-taking. The skill is recognising which of the three conditions actually holds for the task in front of you, rather than assuming that more agents must mean more capability.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Dimension | Single well-equipped agent | Multi-agent system |
|---|---|---|
| Best task shape | Linear dependency chain | Independent, parallelisable sub-tasks |
| Wall-clock latency | Sequential, predictable | Lower only when branches run concurrently |
| Specialisation | One generalist model for all steps | Specialist model per sub-task |
| Context handling | One transcript, can overflow on huge scope | Isolated narrow scope per agent |
| Coordination cost | None beyond the tool loop | Routing, messaging, shared state sync |
| Error behaviour | Single failure point, easy to trace | Per-step rates multiply, harder to trace |
| Debugging | Trace one trajectory | Debug the orchestration layer too |
Real products, models, and research that use this idea.
- Anthropic's multi-agent research system fans out subagents for parallel search, but its own write-up warns the orchestration and token cost only pay off when sub-queries are independent.
- Claude Code runs as one well-equipped agent with file, shell, and search tools rather than a swarm, because coding edits form a tight read then edit then test dependency chain.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you quantify when the parallelism win outweighs the coordination tax?
Model wall-clock as the critical-path length of the dependency graph, not the sum of all tasks. Compare latency saved on independent branches against added routing, messaging, and merge-step latency, plus the extra token cost of duplicated context per agent.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Reaching for multi-agent by default because it sounds sophisticated. Most tasks have a linear dependency chain, where many agents add coordination cost but no concurrency benefit over one strong agent.
60 second bullets to scan on the way to the call.
Name the three conditions under which multi-agent genuinely wins.
Explain why a dependency chain kills the parallelism argument.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.