Most Multi Agent Systems Are a Solution Looking for a Problem

Every major lab now ships a multi agent SKU, and almost none of them repeats in its marketing what its own engineers have written down about when to use one.

Anthropic subagents, 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 small robots handing work to each other. It looks like progress. Draw five boxes, give each one a job title, connect them with arrows, and it feels as if you have built an organization instead of a prompt.

My view is that most teams reaching for multi agent are years early. The best evidence for that comes from the same companies that sell the boxes.

The famous war was a category error

For most of last year the debate had two poles. On one side was 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 was Cognition's Walden Yan, with a post titled, bluntly, "Don't Build Multi-Agents". He argued that parallel agents produce fragile systems and that "a single-threaded linear agent will get you very far."

The internet framed it as a fight. Anthropic proves multi agent wins, Cognition proves it loses, pick a team.

Look at what each of them built, though. Anthropic's win is on research, a read heavy and embarrassingly parallel task where four subagents can each crawl a different corner of the web without getting in each other's way. 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 result says more about parallelism on independent lookups than about any advance in reasoning.

Cognition's warning concerns the opposite job, which is writing. Their cautionary tale has two subagents cloning Flappy Bird. One builds a Mario style background, the other an incompatible bird, and the final agent cannot reconcile the pieces because each made conflicting implicit decisions that nobody wrote down. Cognition does not claim agents are useless. Its claim is narrower, namely that parallel writers editing shared state break in ways you cannot debug.

Separate reads from writes and the "war" turns into a single rule that both sides already follow.

Parallelize read only exploration, keep writes single threaded and default to one agent. Everything else is a footnote.

Both camps now say as much 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 arrives at the same place: multi agent works "when writes stay single-threaded and the additional agents contribute intelligence rather than actions." In other words, extra agents should read and advise, and one agent should write.

The 90.2% is mostly a compute story

That headline number is the one that ends up in the slide deck, so it deserves a second look.

Ninety percent sounds like a result about architecture, and mostly it is not. The same Anthropic post contains 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 used roughly 15x the tokens of a normal chat interaction. A system that spends fifteen times the compute ought to win. What matters is whether the architecture won or the budget did.

In April 2026, Tran and Kiela tested exactly that. When they held the reasoning token budget equal across Qwen3, DeepSeek-R1-Distill-Llama and Gemini 2.5, single agents matched or beat multi agent systems on multi hop reasoning. Their argument is grounded in information theory (passing a problem through more agents cannot add information the tokens did not already carry). The practical conclusion is simple: much of the reported multi agent advantage came from a single agent being starved of tokens it was never given. They also trace some earlier "wins" to artifacts of API budget control, in particular on Gemini 2.5.

So before adding a second agent, ask a cheaper question first: have I let one agent think longer?

In most cases nobody has. The single agent ran on a stingy token budget, hit a wall, and the wall was read as a need for more architecture. What it needed was the 15x you were about to spend anyway, pointed at one agent instead of five.

What usually sits behind "we need multi agent"

The pattern we see most often in the field has little 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 begins picking the wrong tool. The instinct is to split the work, with a returns agent for returns, a billing agent for billing, and handoffs between them. It feels like org design.

Usually it is an unresolved context engineering problem. It is solved with context isolation and a tighter toolset, and a second agent only adds a coordination surface that you then have to debug. Anthropic makes the same point when it recommends context centric rather than problem centric decomposition: split work only when the context can truly be isolated, and not merely because a task has a sub part with a name.

The failure data supports this. UC Berkeley's MAST taxonomy went through more than 1,600 execution traces from ChatDev, MetaGPT and AutoGen and sorted the failures. 41.8% were specification and design issues, 36.9% were misalignment between agents, and 21.3% were verification failures. The finding that should give any architect pause is that better models do not fix these failures, because they are structural. No amount of prompt engineering or model upgrades will repair a system in which nobody defined exactly what each agent sees and owns.

More agents do not give you more redundancy either. The same body of work reports uncoordinated multi agent setups amplifying errors by up to 17x, against roughly 4.4x when a centralized architecture forces a validation bottleneck. Each added agent adds failure surface. A CrewAI diagram does not amount to an architecture. If you cannot state what context each agent sees, you are building the fragile system the essays warn about, with better graphics.

Latency in real time channels

There is one more argument, and in our part of the market it is often the deciding one.

Blits.ai works in real time conversational AI: banking IVR, telco support, government hotlines across the Middle East, Africa and Europe. In those channels the binding constraint is the clock, more than the eval score. 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.

As a rough engineering shape, a single LLM call lands somewhere near 800 milliseconds, while an orchestrator and worker flow with a reflexion pass can run 10 to 30 seconds. Treat those figures as illustrative rather than benchmarked. The ratio holds, though, and every extra agent adds 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 case against the hype is strongest. A multi agent system can score better on a research bench and still be ruled out on the round trip budget alone. For real time work, starting with one agent is often the only architecture that fits the time available.

The same reasoning makes agentic RAG the last variant 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 it gets you most of the way.

When splitting is justified, and how to do it

None of this means multi agent is never right. It means the bar is high, and you should be able to name which of two conditions you meet. Either you have parallel, read only work that is worth the token bill, or you need hard context isolation that a single agent cannot get. If you cannot name one of those, stay with one agent and tighten the prompting and tools.

Once you clear that bar, a few design choices separate a working system from a swarm you will regret.

Prefer agents as tools over free form handoffs. Keep one orchestrator that owns the conversation with the user and calls specialists as if they were tools. That is the single writer principle applied directly. Decentralized swarms that hand off from peer to peer are close to impossible to debug without full distributed tracing, which is the amplification hazard MAST measured. Cognition's own working example is Devin Review, a reviewer agent that catches ~2 bugs per PR (about 58% of them severe), and it does so because it adds intelligence and never writes.

Share full traces, not only messages. Context passing is the main job, and passing too little context is the most common failure. Give the downstream agent the whole reasoning trace rather than a summarized handoff note. Conflicting decisions come from agents that could not see each other's work.

Scope permissions to roles. If you run a planner, executor and reviewer, make the boundaries real controls and not just labels. The planner reads broadly but holds no write rights, executors are limited to a narrow toolset, and the reviewer owns escalation and policy checks. In regulated workflows this separates a system you can explain from one where you 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

Three of the four lines point back to one agent. The exception (read only, parallel, off the critical latency path) is real. When you meet it, it tends to be obvious: the work is a pile of independent lookups, and the value clears the 15x token bill without anyone having to argue for it.

Complexity is not the same as seriousness

The urge to add agents resembles the urge that pushed teams toward microservices in 2016, or toward a Kubernetes cluster to host a blog. Complexity feels serious, and it rarely is. The room in Johannesburg kept coming back to this point this year: the winning team is the one that knows what each agent reads, who reviews it and who is accountable when it drifts, and the number of agents has little to do with it. That is hard to say about a swarm.

So the question to ask was never "single agent or multi agent?" It is whether you have exhausted a well fed single agent, with an isolated context and a tight toolset, before taking on coordination as a permanent cost.

Most teams have not. Give one agent the budget you were about to split five ways, and measure the result. Split only when a specific job (parallel reads, real isolation) will not fit inside one agent. When you do, split deliberately, keep the writes single threaded and treat context passing as the main piece of design work.

If you would rather test that against a real workload than on a whiteboard, that is a large part of what we do on the Blits.ai agentic studio. More often than not, it means talking teams out of the fifth agent.

Paul

Updated on 12 October 2026.