Single-agent wins on latency-critical chat, fits in one prompt tasks, single-step extraction, and high-volume features; multi-agent earns its keep on long-horizon SWE and budget-unconstrained benchmarks.
Think of a restaurant kitchen. A solo cook is faster, cheaper, and easier to coordinate when the order is simple: a sandwich, a salad, a quick stir-fry. Hiring a brigade of chefs (sauce chef, grill chef, garde manger) only makes sense for a multi-course tasting menu that one person could not realistically execute. The same trade-off shows up in LLM agents. For small clear orders, one well-trained agent is the right answer. For long complicated multi-station work, a team earns its keep. The mistake is to bring the full brigade to make a sandwich.
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 2026 multi-agent landscape has a quiet honesty problem. Research papers and framework demos make multi-agent look like the obvious next step from single-agent. Production data tells a different story: single-agent wins the majority of workloads, and the cases where multi-agent earns its keep have specific structural properties.
This card tests whether you can spot those properties. Four of the six options are categories where single-agent reliably wins; two are deliberate distractors where multi-agent is the right answer for structural reasons. Getting the split right is the difference between 'multi-agent everywhere' (which is the failure mode of teams that buy the research narrative) and 'multi-agent where the structural argument holds' (which is the production-honest framing).
Why single-agent wins latency-critical chat
The first single-agent win is fully mechanical. Each agent hop in a multi-agent topology adds at least one LLM round-trip. On Claude or GPT-class models that is typically 400 to 1200ms per hop, depending on the model size and the response length.
User-facing chat has a sub-second UX bar for the start of streaming. Empirically, time to first token above one second feels sluggish; above two seconds users start re-prompting or assuming the system has failed. With one model call as the budget, multi-agent topologies with a supervisor call plus a worker call cannot meet the bar.
The topology choice is forced by arithmetic. Latency budget divided by per-hop latency gives you the maximum hop count. For sub-second chat on a frontier model, the answer is one. Single-agent is the only option that meets the constraint.
This is the cleanest single-agent case because it does not depend on quality arguments at all. Even if multi-agent produced a measurably better answer, the latency cost is unacceptable for the UX. The category is settled by the UX bar, not by the eval metric.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Workload category | Topology that wins | Why |
|---|---|---|
| Latency-critical chat | Single | Extra hops blow the sub-second UX bar |
| Under 15 tools, one prompt | Single | Frontier models handle this tool surface reliably |
| Single-step extraction | Single | No decomposition to do; planner adds no value |
| High-volume cost-sensitive | Single | Cost multiplier is prohibitive at consumer scale |
| Long-horizon SWE, 30+ tools | Multi | Tool surface overflows single-agent; long horizon amortises supervisor cost |
| Frontier research benchmarks (budget unconstrained) | Multi | Quality gains visible when cost is not the constraint, but does not transfer to production |
Real products, models, and research that use this idea.
- ChatGPT's main chat surface runs on what is effectively a single agent with tool use; the latency budget for the UX rules out multi-agent topologies for the main flow.
- Anthropic's Claude on the API runs single-agent for most production workloads; Claude Code subagents are the explicit exception for the long-horizon coding case where the named failure justifies the split.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you measure the cost multiplier multi-agent imposes on your specific workload before committing to the split?
Build a minimal two-agent prototype on a representative slice of the eval set, run it alongside the single-agent baseline, and divide the per-task cost. Repeat for latency. Use those numbers to project the impact at production volume.
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.
Defaulting to multi-agent because it sounds more capable. The honest 2026 framing is that single-agent wins most production workloads; multi-agent wins specific structural cases.
60 second bullets to scan on the way to the call.
The four single agent winning categories and why each one wins
The two distractors and the structural reason each is a multi-agent case
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.