When Not to Use Multi-Agent
Multi-agent systems stack latency, compound errors, cost coordination tokens and are harder to evaluate; the first question is always whether one agent or deterministic code can do the job reliably.
The thesis
Most multi-agent systems in production would be better as one agent with good tools, or as a workflow graph with LLM calls at the nodes. Multi-agent is the last rung of the ladder in Choosing the Right Abstraction, and it is reached far too often because demos reward organisational metaphors ("a CEO agent, a CTO agent…") that do not map to engineering benefits.
The question to ask first, and to answer with evals rather than intuition: can one agent, or a deterministic workflow, do this reliably? If a single agent scores 85% on your golden set and the multi-agent version scores 87% at 3× the cost and 2.5× the latency, you have not built a better system; you have built a slower, more expensive and less debuggable one.
The four costs
These are not hypothetical. Each one shows up in traces within the first week.
- Coordination cost: every hand-off spends tokens re-explaining the task, and every merge spends tokens reconciling outputs. A 3-agent system commonly spends 30–50% of its tokens on coordination rather than work.
- Latency stacking: agents run sequentially unless engineered otherwise. Three agents × 4 turns × 2 s = 24 s where one agent × 6 turns × 2 s = 12 s.
- Error compounding: with independent per-stage success of 0.9, a 4-stage chain succeeds 0.9⁴ ≈ 0.66 of the time. One agent at 0.85 is better.
- Harder evals: you now need per-agent golden sets, contract tests for every hand-off, and end-to-end evals — and a regression can hide in any of them (
flaky-evals).
Signals that you really do need it
Multi-agent is justified when at least one of the role separations from Multi-Agent Systems Overview is load-bearing and you can show it on evals. Concretely: the single agent measurably degrades because its context cannot hold all material; or two sub-tasks need mutually exclusive permissions (a reviewer must not be able to write); or sub-tasks are independent and wall-clock time matters enough to parallelise.
Even then, prefer the most constrained topology that works: pipeline over supervisor, supervisor over hierarchy, hierarchy over swarm. Constraint is what keeps the system evaluable.
Cheaper fixes to try first
Before adding an agent, try: better tool descriptions (Tool Schemas); compressing or reordering context (Context Selection & Compression); a stronger model for the single agent; splitting the prompt into phases within one loop; or moving deterministic parts (validation, formatting, fan-out) into code. Each is an afternoon of work and often closes the gap.
Key points
- Ask first: can one agent or deterministic code do it reliably? Answer with evals.
- Coordination tokens, stacked latency, compounded errors, harder evals — the four costs are certain; the benefits are conditional.
- Per-stage success multiplies: 0.9⁴ ≈ 0.66.
- Justify multi-agent by a load-bearing role separation, shown in measurements.
- Prefer the most constrained topology that passes.
- Try prompt, context, model and code fixes before adding agents.
When to use — and when not to
- Use this checklist in every design review that proposes more than one agent.
- When a team reports a multi-agent system that is slow, expensive or flaky.
- When deciding whether to add a "reviewer agent" to an existing loop.
- It is not an argument against multi-agent when evals show a clear, large gain that no single-agent fix closes.
- It does not apply to parallel fan-out over independent items, which is a queue, not a multi-agent system.
- It is not a reason to skip role separation for permissions when the security requirement is real.
Failure modes
- Organisational-metaphor architectures with no engineering rationale.
- Adding agents to fix a prompt problem.
- Never measuring the single-agent baseline, so the comparison is impossible.
- Cost per request 5× the estimate because coordination was not modelled.