Two coding agents can produce more activity and less working software.
You get parallel branches, twice the status updates, and a satisfying orchestration diagram. Then the changes meet. One agent changed an interface the other relied on. Both completed their assigned feature. The merged result fails.
That is the distinction I care about: parallel activity is not delivered capability.
A second agent is not free capacity. It introduces a coordination tax: the work has to be partitioned, ownership has to stay clear, state has to remain coherent, outputs have to integrate, and the combined result has to be measured. If the extra agent does not improve the completed task, the architecture became more complicated without becoming more capable.
This is not an argument against multi-agent coding. It is an admission standard for it.
What CooperBench actually tested
The CooperBench preprint gives this problem a useful experimental shape. Its benchmark contains 652 collaborative coding tasks constructed from 12 open-source libraries across Python, TypeScript, Go, and Rust.
Each task starts with one repository and two different features. The features are jointly compatible, but their implementations can touch overlapping or interdependent code. In the cooperative setting, two agents each receive one feature and work asynchronously in isolated environments. They can exchange open-ended messages, but neither receives the other feature specification. In the solo baseline, one agent receives both features (CooperBench methodology).
The success condition matters. A cooperative task succeeds only when the two patches can be merged and the integrated repository passes both features' test suites. This is not a count of individually completed subtasks. It measures the merged result (CooperBench evaluation).
Under that setup, the preprint reports that the evaluated coding agents averaged 30% lower success rates when working together than when one agent performed both features (CooperBench results). That result belongs to the five evaluated models, the CooperBench tasks, and this experimental design. It is not proof that every multi-agent system is worse, or that richer orchestration cannot close the gap.
The failure analysis is more useful than the headline number. The authors group underlying problems into three capability gaps (CooperBench failure analysis):
- Expectation gaps: an agent forms the wrong model of what its partner knows, needs, or will do.
- Commitment gaps: an agent agrees to an action but does not reliably follow through.
- Communication gaps: agents omit important information or leave decision loops incomplete.
Communication helped reduce straightforward merge conflicts for several evaluated models, but it did not produce a statistically significant improvement in end-to-end cooperation success. The paper distinguishes spatial coordination—staying out of the same lines—from semantic coordination—building implementations that behave compatibly (CooperBench communication analysis). A clean merge can still be a broken system.
Stanford HAI published an accessible summary of the research, but the preprint is the primary source for the benchmark design and results.
The coordination-tax ledger
The benchmark should not be stretched into a universal rule. My operating assumption is that model calls and compute are not the only costs worth budgeting; coordination has to justify its own budget too.
I use a five-part coordination-tax ledger. This is my operator synthesis, not CooperBench methodology.
1. Partitioning cost
The first cost appears before either agent starts.
Can the task be divided without creating ambiguous dependencies?
My partitioning check covers interfaces, data models, configuration files, test fixtures, and architectural assumptions. It is an operating checklist, not benchmark methodology. If the boundary exists only in the task titles, I do not treat the work as cleanly partitioned.
Failure signal: both agents finish their piece, but one changed something the other piece silently depended on.
2. Ownership cost
Parallel work needs explicit decision rights.
Who owns the shared interface? Who can revise the plan? Who resolves a conflict? Which files, contracts, or behaviors are off-limits without renegotiation?
Without those answers, agents duplicate work, override each other, or make locally reasonable decisions that cannot coexist.
Failure signal: conflicting edits, duplicated implementation, or no clear authority when assumptions change.
3. Shared-state cost
Messages are not shared state.
An agent can send an update that is stale five actions later. A promise in a conversation is not the same as a durable contract. A completion claim is not the same as an artifact another agent can inspect.
The system needs a reliable source for the current plan, ownership boundaries, interface decisions, artifacts, status, and changed assumptions. Otherwise each agent runs on a private version of reality.
Failure signal: an agent proceeds as if communicated partner work does not exist, or acts on a plan that is no longer current.
4. Integration cost
A merge is a transport event. Integration is a behavioral test.
The combined changes need an independent check that can detect incompatible architecture, incomplete contracts, overlapping changes, and regressions across both feature sets. If each agent grades only its own output, the system has no owner for the whole result.
Failure signal: both branches pass local checks, the merge is clean, and the integrated behavior still fails.
5. Measurement cost
Agent systems make it easy to measure the wrong things.
More tokens, messages, branches, or simultaneous activity can look like throughput. None of them proves that the completed task improved.
The comparison should be against a strong single-agent baseline using the same task, tools, context, and acceptance criteria. Measure the merged result: correctness, completion, regressions, elapsed time, and total operating cost where those measures are available. That is why I treat green status as evidence to inspect, not proof that work shipped.
Failure signal: the system can show more work happening, but cannot show a better finished outcome.
The Multi-Agent Admission Test
Before adding another coding agent, make it pass five gates. This is my operating framework.
Use multiple coding agents only when the work has a clean partition, explicit ownership, coherent shared state, independent integration, and a measured completed-task advantage over one agent.
Gate 1: Clean partition
Can the work be partitioned without ambiguous dependencies?
Name the shared surfaces. Define the interface before parallel execution. If one agent cannot proceed without guessing what another will change, keep the work serial or redesign the boundary.
Gate 2: Explicit ownership
Does every agent have explicit, non-overlapping authority?
Assign ownership of files, interfaces, decisions, and conflict resolution. “Agent A handles backend” is too vague if both features modify the same schema or contract.
Gate 3: Coherent shared state
Is there a reliable shared-state contract rather than informal message passing?
Plans, artifacts, decisions, status, and changed assumptions need canonical locations and verifiable updates. Communication should point to state, not substitute for it.
Gate 4: Independent integration
Will an independent integration check catch incompatible or overlapping changes?
Run both feature test suites against the merged result. Check the shared contracts. Make one gate responsible for the whole task, not just the sum of agent self-reports.
Gate 5: Completed-task advantage
Does the coordinated system beat one well-instrumented agent on the completed task?
This is the gate that prevents orchestration theater. If two agents generate more motion but produce a worse, slower, or less reliable merged result, the second agent is not justified yet.
All five gates need credible answers. Four out of five is not “mostly ready.” The missing gate is where the coordination tax will surface.
When one agent is the better architecture
One capable agent with clear context, good tools, durable state, and strong verification is often the better default when:
- the task has tightly coupled changes;
- the architecture is still moving;
- ownership boundaries are hard to express;
- there is no independent integration harness;
- or the team has not measured a coordinated run against a solo baseline.
That is not underusing agents. It is avoiding an architecture the task has not justified.
Add another agent when specialization or clean parallelism creates an advantage that survives integration. I reserve second-agent roles for separable research, independent testing and review, or components with stable boundaries. A measurable reduction in elapsed time also counts, provided correctness does not fall. The point is not to keep agent count low. The point is to make each role legible and worth the complexity.
Measure the merged result
The most impressive agent system is not the one with the busiest dashboard. It is the one that can explain why each agent exists, what boundary it owns, how shared state stays true, and whether the finished work beats the simpler alternative.
CooperBench offers bounded evidence that collaboration can reduce success when those capabilities are weak. The operator response is not “never use multiple agents.” It is to stop granting agents roles based on the promise of parallelism.
Start with one well-instrumented agent. Establish the completed-task baseline. Add a second only when the work passes the admission test. Then measure the merged result again.
Agent count is an architectural expense before it is a capability advantage.
Make every additional agent earn its place.