Most Multi-Agent Systems Are a Solution Looking for a Problem

Every major lab now ships a multi-agent SKU.

Almost none of them will tell you the same thing their own engineers wrote down.

Anthropic sub-agents, the OpenAI Agents SDK, Google ADK, LangGraph's supervisor and swarm, CrewAI, AutoGen — by mid-2026 you cannot open a framework's docs without a diagram of little robots handing work to each other. It looks like progress. Draw five boxes, give each one a job title, connect them with arrows, and you feel like you've built an organization instead of a prompt.

Here's the uncomfortable part. Most teams that reach for multi-agent are years early, and the best evidence for that comes from the exact people selling you the boxes.

The famous war was a category error

For most of last year the debate had two poles.

On one side, Anthropic's June 2025 write-up of how they built their multi-agent research system: a Claude Opus 4 lead agent spawning parallel Sonnet 4 subagents, beating a single agent by 90.2% on their internal research eval. On the other, Cognition's Walden Yan with a post titled, bluntly, "Don't Build Multi-Agents", arguing that parallel agents produce fragile systems and that "a single-threaded linear agent will get you very far."

The internet did what the internet does and framed it as a fight. Anthropic proves multi-agent wins; Cognition proves it loses; pick a team.

But read what each one actually built. Anthropic's win is on research — a read-heavy, embarrassingly parallel task where four subagents can each go crawl a different corner of the web and nobody steps on anybody. Their canonical example was listing every board member across the S&P 500 Information Technology companies: a single agent plodded through sequential searches and failed, while subagents split the list and finished. That's not a reasoning breakthrough. That's parallelism doing what parallelism has always done for independent lookups.

Cognition's warning is about the opposite job: writing. Their cautionary tale is two subagents cloning Flappy Bird — one builds a Mario-style background, the other an incompatible bird, and the final agent can't reconcile the pieces because each made conflicting implicit decisions nobody wrote down. That's not a claim that agents are useless. It's a claim that parallel writers editing shared state break in ways you can't debug.

Split reads from writes and the "war" collapses into a single rule both sides already follow.

Parallelize read-only exploration. Keep writes single-threaded. Default to one agent. Everything else is a footnote.

And here's the tell: both camps now say the quiet part in their own product guidance. Anthropic's January 2026 page on when to use multi-agent systems opens with "start with a single agent," and warns that teams "build elaborate multi-agent systems... only to discover that improved prompting on a single agent achieved equivalent results." Cognition's 2026 update lands in the same place: multi-agent works "when writes stay single-threaded and the additional agents contribute intelligence rather than actions." Intelligence, not actions. Read, don't write. That's the whole game.

The 90.2% is a compute story wearing an architecture costume

Now go back to that headline number, because it's the one that ends up in the slide deck.

Ninety percent sounds like architecture. It mostly isn't. Buried in the same Anthropic post is the sentence that should have been the headline: in their BrowseComp analysis, "token usage by itself explains 80% of the variance." Multi-agent systems in that setup burned roughly 15x the tokens of a normal chat interaction. When you spend fifteen times the compute, you should win. The interesting question is whether the architecture won, or the budget did.

In April 2026, Tran and Kiela answered it directly. Hold the reasoning-token budget equal across Qwen3, DeepSeek-R1-Distill-Llama, and Gemini 2.5, and single agents match or beat multi-agent systems on multi-hop reasoning. Their argument is information-theoretic — passing a problem through more agents can't add information the tokens didn't already carry — but the practical takeaway is blunt: much of the reported multi-agent advantage was a single agent being starved of tokens it was never given. They even trace some prior "wins" to API budget-control artifacts, notably on Gemini 2.5.

So before you add a second agent, ask the cheaper question first.

Have I let one agent think longer?

Most of the time nobody has. The single agent was run at a stingy token budget, hit a wall, and the wall got read as "we need architecture." It didn't. It needed the fifteen-x you were about to spend anyway — just pointed at one agent instead of five.

What you're actually calling "we need multi-agent"

Here's the pattern we see most often in the field, and it has nothing to do with intelligence.

A single agent starts to degrade. Its context fills with irrelevant order history, its tool list has grown to thirty entries, and it starts picking the wrong one. The instinct is to split: give the returns a returns-agent, give billing a billing-agent, wire up handoffs. It feels like org design.

It's usually an unresolved context-engineering problem wearing a costume too. The fix is context isolation and a tighter toolset — not a second agent that adds a coordination surface you now have to debug. Anthropic frames the same point as context-centric rather than problem-centric decomposition: split work only when the context can be genuinely isolated, not because a task has a nameable sub-part.

The failure data backs this hard. UC Berkeley's MAST taxonomy went through 1,600-plus execution traces from ChatDev, MetaGPT, and AutoGen and sorted the failures. 41.8% were specification and design issues. Another 36.9% were inter-agent misalignment; 21.3% were verification failures. The headline finding is the one that should give any architect pause: better models don't fix these. They're structural. You cannot prompt-engineer or GPT-upgrade your way out of a system whose problem is that nobody defined exactly what each agent sees and owns.

More agents is not more redundancy, either. The same body of work reports uncoordinated multi-agent setups amplifying errors by up to 17x, versus roughly 4.4x when a centralized architecture forces a validation bottleneck. Adding agents adds failure surface, not safety. A CrewAI diagram is not an architecture. If you can't articulate what context each agent sees, you're not building a team — you're building the fragile thing the essays warn about, with better graphics.

The latency tax nobody puts on the slide

There's one more argument, and in our corner of the world it's often the decisive one.

Blits lives in real-time conversational AI — banking IVR, telco support, government hotlines across the Middle East, Africa, and Europe. In those channels the constraint isn't the eval score. It's the clock. A caller sits in silence while the system thinks, and a Gulf-Arabic customer confirming a transfer will not wait ten seconds for an orchestrator to poll three workers and run a reflexion loop.

The rough engineering shape of it: a single LLM call lands somewhere near 800 milliseconds; an orchestrator-worker flow with a reflexion pass can run 10 to 30 seconds. Treat those figures as illustrative, not benchmarked — but the ratio is real, and every extra agent is another turn on the wire.

Accuracy you can't deliver inside the SLA is worthless. In a live voice call, a slightly-worse answer in 800ms beats a slightly-better one in 20 seconds, every time.

This is where the anti-hype stance is strongest. A multi-agent system can be genuinely better on a research bench and still be disqualified before it opens its mouth, purely on the round-trip budget. For real-time work, "start with one agent" isn't caution. It's often the only architecture that fits the clock.

It's the same instinct that makes agentic RAG the last cousin you reach for, not the first — one agent looping through a few extra retrieval rounds is almost always simpler and faster than a committee of agents, and gets you most of the way there.

If you genuinely must split, split like this

None of this means multi-agent is never right. It means the bar is high, and you should be able to say out loud which of two conditions you're meeting: you have parallel, read-only work worth the token bill, or you need hard context isolation a single agent can't get. If you can't name one of those, stay single and go tighter on prompting and tools.

When you do clear the bar, a few things separate a working system from a swarm you'll regret:

Prefer agents-as-tools over free-form handoffs. Keep one orchestrator that owns the user-facing conversation and calls specialists like tools — the single-writer principle in practice. Decentralized swarms that hand off peer-to-peer are effectively undebuggable without full distributed tracing, which is exactly the amplification hazard MAST measured. Cognition's own working example is Devin Review, a reviewer agent that catches ~2 bugs per PR (about 58% severe) precisely because it adds intelligence and never writes.

Share full traces, not just messages. The number-one job is context-passing, and the number-one failure is passing too little of it. Give the downstream agent the whole reasoning trace, not a summarized handoff note. Conflicting decisions come from agents that couldn't see each other's work.

Scope permissions to roles. If you do run planner / executor / reviewer, make the boundaries real controls, not labels: the planner reads broadly but holds no write rights, executors are scoped to a narrow toolset, the reviewer owns escalation and policy checks. In regulated workflows that's the difference between "explainable" and "hope nothing goes wrong."

The multi-agent decision, in four lines:

1. Is the work read-only AND parallelizable? ....... maybe multi-agent
2. Is a single writer editing shared state? ........ single agent, always
3. Am I inside a real-time SLA (voice/IVR)? ......... single agent, usually
4. Have I already given ONE agent the token budget
   and a clean, isolated context? ................... do this FIRST

Notice what that box does. Three of the four lines point back to one agent. The exception — read-only, parallel, off the critical latency path — is real, and when you hit it you'll know, because the work is obviously a pile of independent lookups and the value clears the 15x token bill without you having to argue for it.

The point underneath all of it

The instinct to reach for many agents is the same instinct that made teams reach for microservices in 2016 and a Kubernetes cluster for a blog: complexity feels like seriousness. It rarely is. As the room in Johannesburg kept concluding this year, the team that wins is not the one with the most agents — it's the one that knows what each agent reads, who reviews it, and who's accountable when it drifts. You can't say that about a swarm.

So the honest question was never "single agent or multi-agent?" It's "have I actually exhausted a well-fed single agent, with an isolated context and a tight toolset, before I take on coordination as a permanent tax?"

Most teams haven't. Give one agent the budget you were about to split five ways. Measure. And only when a specific, nameable job — parallel reads, real isolation — refuses to fit inside one head, split deliberately, keep the writes single-threaded, and design the context-passing like it's the whole job. Because it is.

If you'd rather have that argument against a real workload than a whiteboard, that's most of what we do on the Blits agentic studio — usually talking teams out of the fifth agent, not into it.

— Paul

Updated on 15 July 2026.