Your tech lead proposes splitting a working single-agent feature into a planner plus an executor. Defend the rule that a multi-agent migration needs a named single-agent failure first, and give two examples of what would count as a valid named failure.
Free · 2 AI evals / day
The rule sounds restrictive but it is actually saving you from a common mistake. Every multi-agent feature ships with costs that a single-agent version does not pay. Until you can name a specific failure of the single-agent version, those costs buy you nothing.
The concrete costs are real. A supervisor agent adds one LLM call per hop. The shared context grows because both agents need to see the conversation, so the token bill roughly doubles. Traces become harder to read because there are now two agents to follow. New failure modes appear: handoff loops where two agents bounce work back and forth, role bleed where the planner starts writing code and the executor starts planning, and deadlocks where each waits on the other. The eval suite cost roughly doubles too, because every eval task now runs both agents instead of one.
The rule asks for a named failure to justify paying all that. A named failure is a concrete metric the single-agent version is missing.
Example one: your single agent has 22 tools in its system prompt and the eval suite shows it picks the wrong tool on 18 percent of long-tail tasks. Splitting into a router plus a specialist that owns the long-tail tools restores accuracy.
Example two: your single agent skips verification because the same model that drafts also grades, and it is biased toward its own output. A separate critic with a different prompt and a different rubric raises verification-step success on a held-out set.
What does not count: 'separation of concerns reads cleaner', 'this is how the demo does it', 'multi-agent is more modern'. Those are aesthetic arguments; the cost is real.
**The rule exists because the costs of going multi-agent are real and uniform, while the wins are conditional.** A second agent adds one supervisor LLM call per hop (cost scales linearly with hops), doubles the token budget on shared context, multiplies the observability surface, introduces handoff loops, role bleed, and deadlock as new failure modes, and roughly doubles the eval-suite cost because every eval task runs the full team trajectory.
Those costs accrue whether or not the split actually helps. Without a named failure of the single-agent version, the split is paying for all of them to deliver a workflow the existing agent was already handling.
### What counts as a valid named failure
**Tool-surface overflow.** The single agent has 18 to 25 tools in its system prompt and the eval suite shows it picking the wrong tool on a measurable fraction of long-tail tasks. The signal is per-tool accuracy on a long-tail eval slice. A planner-router split that hands long-tail tools to a specialist restores the accuracy. This is the Devin-style argument.
**Self-grading bias.** The single agent is supposed to verify its own work but skips or rubber-stamps the check because the same model is both the drafter and the grader. The signal is verification-step success on a held-out set. A separate critic with a different prompt and rubric raises that metric.
### What does not count
'Separation of concerns reads cleaner', 'this is how the AutoGen demo does it', 'multi-agent is more modern', 'the team wants to learn LangGraph'. These are aesthetic or career arguments. The cost is real, the signal is missing, and the conversation should redirect to 'show me the failure first.'
The rule does not say 'never go multi-agent.' It says 'pay for it with a named failure.' Production teams that follow this discipline end up with multi-agent in the places it earns its keep and single-agent everywhere else.
Quick reference
TL;DR
The rule is not 'avoid multi-agent'; it is 'name the single-agent failure first', because every second agent adds supervisor calls, tokens, eval cost, and new failure modes that a working single agent does not pay.
Imagine you have one good cook in your kitchen who handles every meal well. Someone suggests hiring a second cook to be the prep chef. Before you agree, ask what the existing cook is failing at. Are they too slow on big banquets? Do they make mistakes when the menu has too many dishes? If you cannot point to a real problem, the second cook just doubles your wage bill, doubles the chance of two cooks tripping over each other in the kitchen, and doubles the planning meetings. The same logic applies to LLM agents. A second agent has real costs; only a real failure of the existing one justifies them.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
A research demo or paper experiment where the point is to study multi-agent dynamics Research has different success criteria; the named-failure rule applies to production where cost and reliability matter, not to investigations where the topology is the subject.
A regulated workflow where each agent must produce its own auditable artefact for compliance reasons The audit trail is the named justification, even if a single agent could technically handle the work; compliance is a measurable requirement, not an aesthetic argument.
An early prototype where the team is exploring the design space and the cost is trivial The discipline becomes important at production cost scale; for a two-week prototype, exploring multi-agent without a named failure is fine because the lesson learned has value too.
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: enumerate the five costs, define what a named failure looks like, give the two canonical examples (tool-surface overflow, self-grading bias), and contrast with the aesthetic arguments that do not pay the bill.
Real-world examples
Real products, models, and research that use this idea.
1Devin (Cognition) justified its planner plus executor split with a named failure: long-horizon coding tasks with 30+ tools exceeded what a single agent could handle reliably, and the eval data showed the split improving task success on real SWE-bench problems.
2Claude Code's subagent feature ships behind a deliberate flag and is recommended only for specific failure cases (large-codebase exploration, parallel-search workflows) rather than as a default, which mirrors the 'name the failure' discipline.
3Anthropic's published guidance on building agents explicitly recommends starting with a single agent and adding agents only when a specific failure mode demands it, which is the public articulation of the same rule.
4Production teams that ignored the rule frequently report rolling back from multi-agent to single-agent after the cost data came in; the most common rollback story is 'multi-agent was 5x the cost for the same eval scores'.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you structure an A/B that validates the multi-agent version actually fixes the named failure?
Sign in or go Pro to see the approach for this follow-up.
QWhat is the cheapest way to test a named failure hypothesis before committing to a multi-agent rewrite?
Sign in or go Pro to see the approach for this follow-up.
QWhen does a named failure stop justifying the split (the multi-agent version stops outperforming the single agent on the metric)?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Justifying the split with aesthetics (separation of concerns, this is how the framework demo does it) instead of with a measurable failure of the existing single-agent version.