Multi-agent orchestration: when it pays and when it is dead weight

On 12 June 2025, Cognition published a piece called Don't Build Multi-Agents.

The next day, Anthropic published how it had built a multi-agent system that beat the single agent by 90.2%.

Twenty-four hours apart, two serious companies, opposite positions. And both are right. That only gets clear once you look at what the agents in each case were doing.

This post is about the rule that reconciles the two, and about what the 2026 measurement did to the discussion. It is a chapter in the series on harness engineering, and the only one where the right answer tends to be "do not".

The two publications measured different things under the same name.

Cognition, through Walden Yan, argued that multi-agent systems turn fragile for two reasons: the agents share context in a bad way, and decisions taken in parallel come into conflict. The practical conclusion was direct, meaning do not build one.

Anthropic described the opposite path. Their research system uses a lead agent on Claude Opus 4 that delegates to subagents on Claude Sonnet 4, and that configuration beat Opus 4 alone by 90.2% on their internal research evaluation (Anthropic, 13 June 2025).

Anyone who reads one of them comes away convinced. Anyone who reads both comes away unsure what to do. The way out is not picking a side: it is looking at what each case was delegating.

The 90.2% traveled the world. The caveat, published in the same text a few paragraphs away, did not.

Anthropic spells out where the multi-agent pattern goes wrong:

• Tasks where every agent needs the same context.
• Domains with heavy dependencies between the parts.
• Most coding tasks.
• Situations demanding real-time coordination and delegation.

The third item is the one that matters for readers of this blog. The company that published the field's most cited success case says, in that same text, that it fails to apply to coding.

The failure modes they observed while building the system deserve recording, because they are concrete and recognizable. Agents creating over 50 subagents for simple queries. Endless searching for sources that do not exist. Duplicated work from vague instructions. A preference for SEO farm content over authoritative sources, and sequential execution where parallel would fit.

One distinction before moving on. This post covers the system: when to compose several agents and when not to. The mechanics of a single piece, with a configuration file, context isolation and forking, sit in when to delegate to a subagent. They are decisions at different levels, and mixing the two is part of the problem.

<!-- [UNIQUE INSIGHT] -->

The two positions stop contradicting each other once you ask what each agent was doing with the result.

Anthropic's subagents read. Each one searched sources, in parallel, writing nothing the others needed to see, and returned a summary to the lead. No shared state exists to come into conflict, because nobody writes to the same place.

The cases Cognition describes are agents that write. Two agents editing the same project take incompatible decisions without knowing it, and the conflict shows up later, at assembly.

Out of that comes the rule:

That explains the exclusion Anthropic makes with no additional theory required. Code is writing to shared state by definition: two agents working the same repository compete for the same files, the same interfaces and the same design decisions.

Cognition's argument is, at bottom, one about context: the same problem that makes a lone agent lose the thread, covered in why your agent forgets. In multi-agent it fails to disappear: it multiplies.

An April 2026 work tested the question head on: does putting an external orchestrator over the model pay off, or does writing the procedure in the prompt suffice?

In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks, by Dennis, Diamond, Patil, Shabahang and Guo, compared both approaches across three procedural flows: travel booking with 14 nodes, Zoom technical support with 14 nodes and insurance claim processing with 55 nodes. There were 200 conversations per condition, evaluated by LLM-as-a-judge on five criteria (arXiv 2604.27891, 30 April 2026).

The in-context prompt won all three, with scores of 4.53 to 5.00 against 4.17 to 4.84. But the result that matters is the failure one.

In all three, the orchestrator raised the failures, and in the first two the difference goes past double. The layer that existed to add reliability took reliability away.

An honest boundary: the study covers procedural tasks, with steps known in advance. It says nothing about open research, which is where Anthropic's case lives. Both pieces of evidence coexist, and the rule from the previous section is what separates one from the other.

Researchers have mapped multi-agent failure with method, and the result runs against the common sense that the problem is coordination.

Mert Cemri and Melissa Pan led the work Why Do Multi-Agent LLM Systems Fail?, with Matei Zaharia, Joseph Gonzalez and Ion Stoica among the thirteen authors. It annotated 1,642 execution traces across seven frameworks and derived a taxonomy of 14 failure modes, with inter-annotator agreement of 0.88 (arXiv 2503.13657, March 2025, revised in October).

The largest share is not coordination: it is design. Ambiguous specification, ill-defined roles, a flow that fails to close. The system is born wrong, and the agents execute the error in parallel and nothing more.

Two corrections belong here, because that paper's summary circulates distorted. The frameworks studied were ChatDev, MetaGPT, HyperAgent, AppWorld, AG2, Magentic-One and OpenManus, and CrewAI and LangGraph were absent from the study, contrary to what several texts claim. And the percentages in circulation (36.94% and 21.3%) belong to no part of the paper.

The abstract also opens with a sentence that seldom gets cited: despite the enthusiasm, these systems' gains on the popular benchmarks are minimal in general. And it closes by saying the failures found demand more sophisticated solutions, meaning a better prompt solves nothing.

The verification category, third in size, has its own treatment: it is the same limit described in why the agent cannot review its own work. And finding out which of the three categories you landed in requires a trace, the subject of instrumenting what you cannot reproduce.

The polarized debate of 2025 ended with victory for neither side. It ended in a narrow pattern, one both parties practice today.

The format that settled has three characteristics:

1. A single orchestrator owns the continuous context. Two owners do not exist.
2. The subagents are ephemeral: they are born for one subtask and die in it.
3. They are read-only and return compressed summaries, instead of writing to the main state.

Note that this is the third section's rule, implemented. Reading in parallel, writing concentrated in one place. Nobody chose the pattern for its elegance: it is what remained after the other configurations failed.

What "ephemeral and read-only" means in code

The three characteristics above tend to read as vague recommendations. They have a direct translation.

Ephemeral means the subagent holds no state between calls. It receives the subtask, the minimum context for executing it and nothing more. It has no memory of the session, no idea what the others are doing and no need to know. Once it finishes, what remains of it is the text it returned.

Read-only means it holds nothing in its tool set that writes to the main state. It is no instruction in the prompt asking for care: it is the absence of the tool. If the subagent cannot call the function that writes, it writes nothing, regardless of what it decides.

Compressed summary means the return is smaller than the input. A subagent that returns everything it read solved nothing, it moved the context problem to the orchestrator and nothing more. The gain lies in it reading a lot and returning little.

Checking that the pattern is right is simple: if two subagents running at the same time could produce a conflict, one of them writes to shared state, and the design still needs work.

A confusion of layers gets in the way here. A system with several agents needs a way for them to talk, and that is protocol, the subject of the map of agent protocols. Having the protocol solved answers nothing about whether you should have several agents.

Before any architecture discussion, one sum eliminates half the cases.

Per Anthropic, an agent consumes around 4× more tokens than a chat interaction. A multi-agent system consumes around 15×.

Fifteen times is a multiplier that pays for itself only when the gain is large and measurable. In Anthropic's case it was: 90.2% on a task the company runs at scale. On an internal flow that already works with one agent, it seldom is.

Where that cost leaks in production, and what to do about it, sits in where the money leaks in production. Here the effect is enough: multi-agent turns an architecture problem into a budget problem.

Gartner projects that companies will cancel over 40% of agentic AI projects by the end of 2027, and lists three causes: rising cost, unclear business value and insufficient risk controls (Gartner, 25 June 2025). The first cause is this section's.

The same analysis estimates that, among the thousands of vendors calling themselves agentic, around 130 hold up to the name. The rest is rebranding of a product that already existed. Keeping that in mind while reading a framework comparison written by someone who sells a framework is worth doing.

Three questions, in this order. If the first fails, the others do not matter.

1. Does the task split into independent parts? If the parts have to talk during execution, or if all of them need the whole context, stop here. It is no case for multi-agent.

2. Do the parts read or write? Reading in parallel is the case that works. Writing to the same state is the case that breaks. If writing exists, concentrate it in one agent and leave the others reading.

3. Can you measure whether it improved? Without an evaluation of the real task, you will never know whether the 15× bought anything. The method sits in evaluating an agent on the real task, and it has to exist before the migration, not after.

One warning about the order. MAST's largest failure category is system design, and design is what gets decided now, by answering those three questions. Choosing a framework before that is deciding the tool before the problem.

The way back, if you already migrated

Dismantling a whole multi-agent system is seldom necessary. The adjustment that tends to solve it is cheaper, and it follows the same rule.

Start by identifying who writes. List each agent and its tool set, and mark every tool that changes state: writing a file, calling an API that modifies, updating a record. If two or more agents appear on that list, that is the conflict point, and it is where the incomprehensible errors are born.

Then concentrate the writing. Pick one agent to own the state and take the state-changing tools away from the rest. They keep existing, they keep running in parallel, and they start returning text instead of acting.

Last, measure again. If accuracy rises and cost falls, the problem was the design, and not the number of agents. If nothing changes, the odds are the task never split, and a single agent solves it with fewer moving parts.

<!-- [PERSONAL EXPERIENCE] -->

Producing these texts uses both configurations, and the split follows this post's rule without my having planned it that way.

The research stage is multi-agent by nature: fetching five different primary sources is five independent reads, which never affect each other, and each comes back as a verified summary. It is Anthropic's case in miniature, meaning reading, parallel, with no common state.

The writing is not. The text amounts to shared state, and a post written by two agents in parallel would produce the very thing Cognition describes: two incompatible structural decisions, discovered at assembly. Here there is one agent, from start to finish.

The explicit judgment, then: I would not recommend migrating a writing flow to multi-agent today, however tempting the parallelism looks. And the uncomfortable part is that the temptation is real, since research gets faster in plain sight with parallelism, and concluding from there that writing would too comes easy. It does not: they are operations of different natures, and one's gain transfers nothing to the other.

Is multi-agent better than a single agent?

It depends on what the parts do. In a research case measured by Anthropic, the multi-agent system beat the single agent by 90.2%. In three procedural flows measured in 2026, putting an external orchestrator on top came close to doubling the failure rate. The practical rule: multi-agent helps when the subtasks read in parallel and hurts when they write to the same state.

Is CrewAI or LangGraph worth using?

The question comes before the framework. If the task fails to split into independent reading parts, no framework solves it. The largest failure category cataloged by MAST is system design, at 43.9%, and not the tool. Worth noting that neither CrewAI nor LangGraph was among the seven frameworks studied in that work, contrary to what many summaries claim.

Why does my multi-agent system fail?

MAST annotated 1,642 execution traces and grouped the failures into three categories: system design (43.9%), inter-agent misalignment (31.4%) and task verification (23.5%). Start with the first: ambiguous specification and ill-defined roles account for more failures than coordination problems do.

How much more does running multi-agent cost?

Around 15 times a chat, against around 4 times for a single agent, per Anthropic. It is a multiplier that justifies itself only with a large, measured gain. Gartner projects over 40% cancellation in agentic projects by the end of 2027, and rising cost is the first cause it lists.

Does multi-agent work for coding?

Anthropic itself says no, in most cases. The text describing their multi-agent system excludes, in so many words, tasks demanding shared context, heavy dependencies and most coding tasks. Code is writing to shared state, which is the case where the pattern breaks.

And if I already built one?

Before dismantling, measure. Run the same task in both configurations and compare accuracy, time and cost. If the gain fails to appear, the cheapest migration tends to be keeping one orchestrator owning the context and turning the rest into ephemeral readers that return a summary. It is the pattern the field converged on.

• Cognition and Anthropic published the opposite a day apart, and each measured a different task.
• The 90.2% is real and came from research. The same text excludes most coding.
• On procedural tasks, the external orchestrator worsened the failures in all three flows measured.
• The rule: parallel reading pays, shared writing charges.
• The biggest cause of failure is system design, at 43.9%, not coordination.
• 15× the cost of a chat. It pays for itself only with a measured gain.

Before choosing between CrewAI and LangGraph, answer whether your task splits into independent reads. If it does not split, the right answer is one agent, and that decision is worth more than any framework.