Multi-agent systems split a task across specialized agents that coordinate, hand off work, and check each other's output. Done well, they beat a single generalist agent. Done by default, they mostly add token cost and coordination overhead for no real gain.
A multi-agent system coordinates two or more LLM-driven agents — each with a distinct role, prompt, model tier, or tool set — to complete a task that one generalist agent would handle worse, slower, or not at all. Three conditions justify the added complexity: specialization (a focused agent genuinely outperforms a generalist), parallelism (independent sub-tasks can run at once and shorten wall-clock time), or critique (a separate critic agent measurably improves quality beyond what self-review inside one agent achieves). Six orchestration patterns cover almost every production system: supervisor/worker, hierarchical, swarm, pipeline, debate, and fan-out — and the honest number worth knowing upfront is that multi-agent setups typically carry 58% to 285% more token overhead than a single well-designed agent, so it pays to confirm one of those three conditions actually applies before reaching for a team.
It's one of the most over-prescribed shapes in applied AI: reaching for multiple agents because it sounds more sophisticated than it needs to be. A single well-scoped agent, given the right tools and enough context, handles most tasks just fine.
Each pattern is a different answer to the same question: who decides what happens next, and how do results get back together.
A central supervisor receives the goal, breaks it into subtasks, routes each to a specialist worker agent, and synthesizes the results. This is by far the most common shape in production — by some estimates, around seventy percent of deployed multi-agent systems use this orchestrator-worker topology.
It gives clear control and simple debugging, since every decision flows through one place. The trade-off is exactly that centralization: the supervisor is a potential bottleneck, and its growing context window — not the worker calls — usually dominates token spend.
Hierarchical systems stack supervisors into levels: a top-level orchestrator delegates to mid-level supervisors — say, a research team lead and a code team lead — each of whom manages their own team of specialist workers. Higher levels focus on coordination and planning; lower levels focus on execution.
This earns its added coordination overhead only when task complexity genuinely spans multiple distinct domains of expertise. Adding a hierarchy layer to a task a single supervisor could already handle just adds latency and cost without a matching benefit.
In a swarm, autonomous agents work in parallel with minimal central coordination — sharing information directly with neighbors or through a publish-subscribe message bus, rather than reporting to a supervisor. There's no single bottleneck and no single point of failure.
The cost shows up elsewhere: without a coordinator, getting the overall system to converge on a coherent result becomes significantly more complex to reason about and to debug. Swarm shows up most often in research-and-summarize tasks, where independent parallel exploration genuinely pays off.
Pipeline agents process work in a fixed sequence, each one refining the previous agent's output — a drafting agent, then an editing agent, then a fact-checking agent, in a straight line. Every step depends on the one before it, which makes the flow easy to reason about and debug, but also fully serial: no step starts before the last one finishes.
It fits workflows with a genuinely natural sequence — draft, then edit, then verify — better than tasks where steps could just as easily run in parallel.
In the debate pattern, two or more agents argue different perspectives on the same problem, and a separate judge — sometimes a different model entirely — arbitrates between them. It's the clearest way to operationalize the "critique" condition for going multi-agent: a genuinely independent second opinion catches errors a single agent's self-review misses.
The cost is real and worth quoting plainly: running a debate pattern typically costs around two and a half times a single-model call. Reserve it for decisions where being wrong is expensive enough to justify that premium.
One coordinator dispatches and synthesizes. The 2026 production default.
Supervisors of supervisors, for genuinely multi-domain complexity.
Autonomous peers, parallel exploration, harder to coordinate.
Sequential hand-offs, each agent refining the last one's output.
Competing perspectives plus a judge; costly but high-assurance.
Parallel dispatch to independent workers, results gathered back.
Every orchestration pattern needs the same underlying thing: persistent, shared state that survives beyond any single agent's turn. Without it, systems hit the same handful of failures no matter which pattern they picked.
Cross-vendor communication has its own emerging standard: the A2A protocol, now under the Linux Foundation, defines how agents from different frameworks or vendors can talk to each other regardless of which orchestration pattern sits on top.
Every added agent adds tokens, and the coordination overhead compounds faster than most teams expect.
Independent, decentralized setups typically run around 58% more token overhead than a comparable single agent; centralized supervisor setups can run closer to 285% more, because every worker result eventually flows back through — and grows — the supervisor's own context window.
A common cost lever is model tiering: a larger, more capable model for the planner or supervisor role, and smaller, cheaper models for routing classifiers and narrow worker tasks — since the supervisor's reasoning quality matters more to the outcome than any single worker call.
| Topology | Typical token overhead | Cost driver |
|---|---|---|
| Single agent (baseline) | 0% | — |
| Independent / decentralized | ~58% extra | Redundant context across peers |
| Centralized / supervisor | ~285% extra | Supervisor's growing context window |
| Debate / consensus | ~2.5x a single call | Multiple full reasoning passes plus a judge |
Real systems often combine patterns — a hierarchical structure might run a pipeline inside each team, or a supervisor might spawn a swarm for a burst of parallel exploration before synthesizing the results. None of these hybrids are wrong; the mistake is picking a shape before understanding what the task actually needs.
Start with a single agent. Add a second only when specialization, parallelism, or critique clearly earns its keep — and budget for the token overhead that comes with it, honestly, before it shows up in a bill.
When at least one of three conditions clearly holds: a specialized agent measurably outperforms a generalist on the sub-task, independent sub-tasks can genuinely run in parallel and save wall-clock time, or a separate critic agent catches errors that self-review inside one agent reliably misses. If none of these apply, a single well-scoped agent is usually both cheaper and simpler to debug.
The supervisor / orchestrator-worker pattern, used in an estimated seventy percent of production multi-agent deployments. A central coordinator breaks the goal into subtasks, routes each to a specialist worker, and synthesizes the results — offering clear control at the cost of the supervisor becoming a potential bottleneck.
Decentralized, independent setups typically run around 58% more token overhead than a single agent; centralized supervisor setups can run closer to 285% more, largely because the supervisor's context window keeps absorbing every worker's output. Debate patterns with a judge model run around 2.5 times the cost of a single model call.
Hierarchical stacks supervisors into levels, with higher levels planning and coordinating while lower levels execute — still fundamentally centralized, just at multiple tiers. Swarm has no central coordinator at all: autonomous peer agents work in parallel and share information directly with each other, which removes the bottleneck but makes overall coordination harder to reason about.
Usually not because of the orchestration pattern chosen, but because of missing persistent shared state — leading to context loss between hand-offs, bloated payloads re-passed at every step, race conditions where agents overwrite each other's work, and no checkpoint to recover from after a crash. Solving coordination and state management matters more than picking the "right" topology.
Agent-to-Agent (A2A) is an open standard, now under the Linux Foundation, for cross-vendor agent communication — letting agents built on different frameworks or by different vendors coordinate regardless of which orchestration pattern sits above them.
Start with a single agent, confirm one of the three conditions before adding a second, and pick the orchestration pattern that matches your task's actual shape — not the most impressive-sounding one.