Over the past year, the story around AI coding tools has been upgraded from “copilot” to “team.” Mainstream coding agents now ship sub-agents that work in parallel (Claude Code’s docs have a dedicated section on running agents in parallel, listing four ways to do it), orchestration frameworks sell multi-agent coordination as the headline feature, and plenty of teams are already discussing how to point ten agents at one codebase. The implicit assumption is simple: if one agent can do the work, a team of agents can do bigger work.

Diyi Yang’s group at Stanford put that assumption on the bench (Stanford HAI coverage, paper at arXiv:2601.13295). The result: pair two top coding agents on real software tasks and their combined success rate averages 41% lower than one agent doing everything alone. A note on the number up front: 41% is the relative drop in the AUC metric described below (0.338 down to 0.200). The paper’s abstract uses a different calculation and reports “30% lower on average.” The two figures measure differently and don’t contradict each other. The authors gave the phenomenon a name: the curse of coordination.

How the experiment works

The benchmark is called CooperBench, and it is deliberately built to look like real team development: 652 task pairs drawn from 12 real open-source repositories, spanning Python, TypeScript, Go, and Rust. Each pair is two features that can be implemented independently but may collide, and collisions are not an edge case: in 77.3% of task pairs, even the two gold-standard implementations conflict with each other. A single feature averages 52 changed lines across 4.4 functions, which is a real development task, not a toy problem.

The setup simulates remote pair programming. Two agents (built on the OpenHands framework, testing GPT-5, Claude Sonnet 4.5, MiniMax-M2, and two Qwen3-30B variants) each modify their own copy of the same repository in isolated containers, and can message each other at any time. When both finish, their patches are merged with git. The evaluation even provides a small fine-tuned 0.5B model (a Qwen2.5-Coder variant; one spot in the paper’s body says 1.5B, but the model spec in the appendix says 0.5B, which I’m treating as authoritative) to resolve trivial merge conflicts. Unit tests then run on the merged code. The control condition, solo, is the same agent implementing both features by itself.

The metric is the area under the success-rate-versus-difficulty curve, which you can roughly read as combined success rate across all difficulty levels. Pooled across five models, solo scores 0.338 and pairing drops it to 0.200: agents keep only 59% of their capability. Even GPT-5, the strongest model tested, keeps only 64% (0.506 to 0.325). Claude Sonnet 4.5 keeps 60%, MiniMax-M2 just 46%. The harsher finding: shutting off the messaging channel entirely produced no statistically significant change in success rates. Being able to talk and talking usefully are two different things.

What the failures look like

The authors used an LLM to label the symptoms across all failed trajectories. The two biggest categories are work overlap (33.2%: both agents independently implemented the same piece of functionality, wasting the effort or overwriting each other) and divergent architecture (29.7%: the two implementations are incompatible by design). Behind those come repetitive messaging (14.7%: status updates carrying no new information) and unanswered questions (8.7%: direct questions from a teammate that go nowhere).

They also manually read 50 failure traces and sorted root causes into three bins: expectation failures (42%: wrong predictions about what the partner is doing or will do), commitment failures (32%: promised work not done, or work done that was promised off-limits), and communication failures (26%). The transcripts contain scenes anyone who has shipped software will recognize: one agent explicitly warns “I’m working on this file,” the other acknowledges, then overwrites the code anyway. The chattier models (Claude, GPT-5) spend up to roughly 20% of their action steps sending messages, and the messages don’t buy coordination.

One pattern in this taxonomy deserves to be called out separately: the two largest symptom categories both come from working in parallel without seeing each other’s work. Work overlap is two agents doing the same job twice; divergent architecture is two designs that don’t fit together. The paper’s definitions stop there. “Both sides made design calls blind, without seeing the other’s finished work” is my inference about the cause. Following that inference, I suspect the lethal variable is concurrent writes, not headcount. But to be clear: the paper has no “two agents working sequentially” control, so the existing data cannot separate “one more agent” from “two agents writing at once.” That remains an untested hypothesis. The solo condition offers weak circumstantial support at best: the paper only says the same agent handled both features, without prescribing an order, but a solo agent sees every line it has already written, so conflicts get resolved as they arise and never accumulate.

The natural next question: would a sequential relay (A finishes, B builds on A’s result) recover the lost success rate? The paper doesn’t test this setting, so I can only reason from mechanism. Sequential execution eliminates work overlap outright and should sharply reduce architecture divergence, because B sees all of A’s finished code before starting. The residual loss sits at the handoff: B inherits the code but not A’s design intent or the assumptions A never wrote down. The cost is equally clear: a relay gives up the parallel speedup, and “faster” is the core selling point of multi-agent orchestration. If concurrency really is the driver, a more accurate name for this curse would be the curse of concurrent writes to shared state.

The mechanism: spatial coordination is fixable, semantic coordination isn’t

The paper splits coordination into two layers, and this split is the most explanatory idea in the whole study.

Spatial coordination answers “who edits where.” As long as both sides state files and line numbers, they won’t collide. Messaging genuinely helps at this layer: with communication on, merge conflicts for Claude and GPT-5 drop noticeably, and trajectories that successfully avoid conflicts mention specific line numbers more often (32.6 times on average, versus 22.5 in trajectories that hit conflicts).

Semantic coordination answers “do the two pieces fit together.” Both implementations need to share the same design decisions: interface signatures, parameter meanings, data structures. A merge can complete cleanly and the tests still fail, because the data format A’s implementation assumes doesn’t match what B’s implementation produces. In theory this layer is also solvable by chat: agree on interfaces and data formats before writing code. The hard part is that these decisions are mostly made implicitly. “I’m editing these lines in this file” is explicit information, stated in one sentence. But when an agent picks a data format in passing while writing code, it doesn’t register that choice as a “decision” worth announcing, and it can’t predict which assumption its partner will diverge on. The mismatch only surfaces when tests fail after the merge, by which point both implementations are fully formed. This explains the otherwise odd combination in the results: communication on, merge conflicts down, success rate unchanged. The explicit location information got through; the implicit design assumptions didn’t.

The data also points at timing. Successful agents have a higher ratio of planning messages to question messages (2.04 versus 1.31), and pairs that lay out a complete plan in their very first message cut their conflict rate from 51.5% to 29.4%. Effective coordination happens before the work starts. The agents’ habit is the opposite: start coding, chat along the way, and discover the incompatibility after both sides have written dozens of lines.

Why do agents behave this way? My speculation (the paper runs no training-side experiments, so this paragraph has no data behind it): coding agents are typically trained with reinforcement learning against single-player reward signals, optimizing for task completion and passing tests. “Keep your promises” and “maintain your teammate’s expectations” are hard to encode into that signal. The authors’ framing in the HAI article points the same direction: these models were not trained to use language for social action, and the team suggests adding coordination-related rewards to training. Humans, for what it’s worth, are also naturally bad at this. The Mythical Man-Month is entirely about the communication cost of adding people (channels grow with the square of headcount). In my own engineering experience, humans keep that cost down with process: interfaces designed first, code review, continuous integration. Agents currently have neither the internalized collaboration habits nor anyone imposing the process on them.

The blind spot in single-agent leaderboards

First, let’s pin down what “single” and “multi” mean in this study, because it is not the product architecture you see most often today. A common pattern in current coding agent harnesses is one lead agent splitting a task across several sub-agents that execute in parallel, with the lead agent integrating the results at the end. Both the split and the integration have a central node making the call, which makes it centralized orchestration (the manager pattern in the OpenAI Agents SDK and Claude Code’s subagents are both this type). The multi-agent setting CooperBench tests has no central node: two fully equal peers, neither directing the other, with the task split fixed in advance by the benchmark, integration done by a git merge after the fact, and all coordination happening through messages. Its solo condition (what I’ve been calling “single agent”) is one agent with no teammate implementing both features alone. The orchestrator-plus-subagents pattern sits between the two, close to the second recommendation below, where coordination is handled by architecture. But whenever multiple sub-agents write to the same codebase in parallel, the same semantic conflicts will appear; the burden of resolving them just lands on the lead agent.

What this study genuinely destabilizes is how we pick models from benchmarks. Mainstream benchmarks like SWE-bench are entirely single-agent problem solving (the official task definition: given a codebase and an issue, one model produces a fix patch). A high score there has no predictive power for “deploy a team of agents on a shared codebase”: in CooperBench, the ranking of solo scores and the ranking of capability retention after pairing don’t line up. MiniMax-M2’s solo score is respectable; it degrades the most when paired.

And the hole deepens with scale. On a 46-task subset, the authors pushed the agent count from 2 to 4, and success rates fell from 68.6% to 46.5% to 30.0%. Until coordination ability catches up, agent count is not a multiplier. It is a divisor.

How to use multi-agent setups today

For anyone building agent workflows right now, three judgments seem directly actionable to me.

First, the multi-agent configurations that genuinely work today are the ones with no shared write state: read-only code retrieval, independent parallel reviews, fan-out analysis with a final aggregation. These don’t trigger the curse of coordination because they don’t require coordination.

Second, if you must parallelize writes, do the coordination in the architecture, and don’t expect agents to negotiate it in chat. Have a human (or the orchestration layer) split the task by module, freeze the interfaces first, and guarantee zero file overlap. That dissolves the hardest part, semantic coordination, at task-division time. If the work won’t split into modules, fall back to a sequential relay (B starts after A finishes) rather than forcing parallelism, accepting that it no longer saves time. This matches the direction of the paper’s own suggestions: verification mechanisms for commitments and forced periodic integration, which amount to strapping human engineering process onto agents.

Third, if agents must communicate, force them to exchange complete plans in the first round. That is the communication behavior most strongly associated with low conflict rates in the paper (51.5% versus 29.4%); mentioning specific line numbers more and sending more planning-type messages also correlate with fewer conflicts. One footnote: these are observational associations, not causal results from controlled experiments.

Will the gap CooperBench exposes close on its own as models get stronger? The paper can’t answer that longitudinal question; the evidence it offers is cross-sectional: across five models, solo capability rankings and collaboration retention rankings disagree, which says coordination is not a free byproduct of coding skill. My own read is pessimistic: collaboration is a capability that needs its own training and its own evaluations, and both have barely started. Until then, the best multi-agent architecture is the one where agents need as little coordination with each other as possible.

References