When do more AI agents actually help? What the evidence says

The most quoted success story for multi-agent AI contains a sentence I had read past for months. Anthropic's research system beat a single agent by 90.2% on its internal evaluation, and the authors explain why: token usage alone explained about 80% of the performance difference in their analysis. More agents mostly meant more budget spent on the problem. The same article says most coding tasks are a poor fit.

I had spent two months building tools to let Claude and Codex sessions work on my game together. The first two attempts stalled. The third connected existing sessions but still left me intervening. Before building anything else, I wanted to know what is actually established about coordinating AI agents, and what is only assumed by people like me who want it to work.

This article collects what I found. It is meant as a reference I can point back to, so I am stricter than usual about sources. Everything here reflects what was published or documented on 13 November 2026.

How I read the evidence

I used three kinds of sources and weighed them differently:

• Peer-reviewed or widely cited research, such as the MAST failure taxonomy. Strongest, but often based on older models and research frameworks rather than the tools I use.
• Preprints, such as CooperBench, the Google scaling study and Co-Coder. Recent and relevant, but not all peer-reviewed. Several numbers changed between versions, which I note where it matters.
• Vendor documentation from Anthropic and OpenAI. Authoritative for how the tools behave, but naturally silent on where they fall short.

I left out figures I could only find in blog summaries without a primary source. There are many of them, and they tend to be the most dramatic ones.

What I kept running into

My own problems were not unusual, which is why they are worth listing:

1. Too much communication. Status checks, acknowledgements and briefings consumed the same allowance that the actual work needed.
2. Too much waiting. Sessions waited for each other, or for me, without anything useful happening.
3. Finding the right session. A saved conversation, a loaded one and a reachable one turned out to be three different things.
4. Friction between coordinator and workers. Handovers were missed, claims went stale, completions were not recognised.
5. My own feedback lost weight. Sessions followed the coordinator and older instructions more readily than a new correction from me.
6. The bridge became the only channel. Sessions in the same harness messaged each other through my tool, even though their harness had a native way to do that.

Each of these turned out to have a counterpart in the research.

The research says coordination is the hard part

Most failures are design failures, not model failures. The MAST study by Cemri et al. at UC Berkeley annotated more than 1,600 traces from seven multi-agent frameworks. It found 14 failure modes in three groups: system design issues, misalignment between agents, and missing or wrong verification. The modes include agents disobeying the task or their role, failing to ask for clarification, ignoring another agent's input, ending too early and checking results incompletely. Annotators agreed strongly (κ = 0.88), so the categories are not just one person's reading. The authors present this as a map for better system design rather than a list of tested fixes.

Coordination helps parallel work and hurts sequential work. A Google Research study by Kim, Liu and colleagues compared single-agent and multi-agent architectures systematically. The Google blog post describes 180 configurations across four benchmarks: centralised coordination improved a decomposable financial-analysis task by about 81%, while every multi-agent variant made a sequential planning task worse, by 39 to 70%. The current arXiv version extends this to 260 configurations and six benchmarks. It also describes a capability-saturation effect: once a single agent already performs well, coordination yields diminishing returns. An earlier version put that point at around 45% single-agent success; the current version no longer names a number.

Independent agents amplify errors. The same study reports that independent agents amplified errors 17.2-fold, against 4.4-fold for systems with a central coordinator. Tool-heavy tasks carried extra coordination overhead. This is the strongest argument I found for a coordinator: it is less a planner than a verification point.

Two coding agents do worse than one doing both jobs. CooperBench, by Khatua, Zhu, Yang and colleagues at Stanford, gives two agents separate features in the same real repository, over more than 600 tasks in four languages. Working together, they succeeded about 30% less often than when one agent implemented both features. The abstract names three problems I recognised immediately: communication channels jammed with "vague, ill-timed, and inaccurate messages", agents deviating from their own commitments even when communication worked, and agents holding wrong expectations about the other's plans. The paper is a preprint and is also listed on the ICLR 2026 site.

How the work is split matters more than how many agents there are. The Co-Coder preprint is the most encouraging result I found, and the most conditional one. It partitions a repository by how strongly files depend on each other, then runs agents on cohesive groups in dependency order. On 28 Python repositories with one small model, this raised pass rates (for example from 20% to 34% on the harder benchmark) while being faster and cheaper than working sequentially. Naive file-by-file parallelism, by contrast, cost 44 to 60% more with little or no quality gain. Claude Code's agent teams were the fastest configuration but had the lowest pass rates. Only Python and only one model, so I treat it as a direction, not a rule.

Practitioners reached the same conclusions

Anthropic's research system gives the most detailed account of what made an orchestrator–worker setup work:

• Multi-agent runs used about 15 times the tokens of a chat, so they only pay off for valuable tasks.
• Vague delegation caused duplicated work and gaps. Each worker needed an objective, an output format, guidance on tools and sources, and clear boundaries.
• Early versions spawned 50 subagents for simple questions. Effort had to be scaled by explicit rules.
• Results were written to external storage and passed back as references instead of being relayed through the coordinator.
• The coordinator could not steer workers mid-task, and workers could not coordinate with each other.
• Poor fits: tasks needing shared context, many dependencies, and most coding.

Cognition, the company behind Devin, argued against multi-agent architectures with two principles: share full context, not just messages, and remember that actions carry implicit decisions. Their example is two subagents building parts of a Flappy Bird clone and producing a mismatched background and bird, because neither saw the other's choices. Their default is a single linear agent, with subagents limited to answering well-defined questions.

Read together, these two sources don't really disagree. Anthropic's system works on research, where subtasks are genuinely independent and only results need to be merged. Cognition writes code, where every subtask leaves decisions in shared files.

The harnesses already solve part of this natively

The tools have changed a lot in 2026, and some of my own workarounds are now built-in features.

Claude Code describes a ladder of options and recommends the lightest one that works:

• Subagents handle side tasks in their own context and return a summary.
• Cross-session messaging lets Claude message other Claude sessions on the same machine, and across machines through Remote Control. It requires v2.1.224, or v2.1.234 on native Windows.
• A message arrives between tool calls, or starts a new turn when the receiver is idle.
• The receiver decides per session whether to accept, hold or refuse such messages.
• A peer message can never approve a permission prompt, and it counts towards usage like a typed prompt.
• The receiver queues at most 50 accepted messages, drops identical repeats and rate-limits each sender, so a message loop between two sessions stops on its own.
• notify_when_idle lets a session ask for one notice when another goes idle, without spending tokens in the watched session.
• Background sessions run under a supervisor. claude agents --json reports whether each is working, blocked, done, failed or stopped. Idle, unattached sessions have their process stopped after about an hour, while the conversation stays on disk.
• Agent teams add a shared task list and mailboxes. They are experimental and off by default. The documentation recommends three to five teammates, warns against two teammates editing the same file, and lists known limitations: no resumption, task status that can lag, and a lead that sometimes stops early.
• Hooks cover the session lifecycle. A Stop hook can keep Claude working, and an asynchronous hook can wake Claude when a background command finishes.
• Channels let an MCP server push events into a running session. They are a research preview, require an explicit opt-in at startup, and give no delivery confirmation.

Codex exposes its sessions through the documented app-server protocol:

• thread/resume reopens a thread, turn/start begins work, turn/steer adds input to the turn in progress and turn/interrupt stops it.
• Notifications such as turn/completed and thread/status/changed report what happened.
• The JSON schema can be generated for the exact installed version, which makes compatibility testable.
• Codex hooks include a Stop event that can force a continuation. They also include model-request events that report token usage, which is rare and useful for measuring cost.
• Codex subagents exist but are experimental, and the documentation warns that they use more tokens than a single agent.

The protocols have converged on durable tasks. The MCP Tasks extension returns a task handle with the states working, input required, completed, failed and cancelled, so a client can reconnect and continue polling. A2A, now under the Linux Foundation, models tasks with a lifecycle in the same spirit. Neither tells agents when to coordinate. Both make it easier to record whether they did.

Matching my problems to the evidence

When more agents are worth it

Taken together, the evidence suggests a short checklist. More agents tend to help when:

1. The work splits into genuinely independent parts, or is partitioned along real dependency boundaries rather than file by file.
2. The work is mostly reading, such as research, review, auditing or testing competing hypotheses, rather than parallel writing.
3. Each part has its own files or resources. Shared files are where implicit decisions collide.
4. The value justifies a multiple of the token cost. Anthropic measured about 15 times that of a chat.
5. A single agent is not already good at the task. Beyond that point the returns diminish.
6. Something central verifies the results, ideally against the end state, not the report.

They tend to hurt when the task is sequential, the parts share files or decisions, the task is small, or the delegation is vague. In those cases one agent with good context is the better default, and that matches what both vendors' documentation recommends.

One idea I could not find tested anywhere: whether a second agent from a different model family is a better reviewer than a second instance of the same model. Claude's own documentation describes competing hypotheses as a way to avoid anchoring on the first plausible explanation. Pairing Claude and Codex for exactly that is plausible, but it is my hypothesis, not a result.

What remains open

• I found no study of coordination across different commercial harnesses. Every benchmark I read used agents from one framework.
• The coding results come from benchmarks with tests. In my game project, much of the acceptance was a judgment about how something looks or plays, which no test covers.
• Several of the vendor features I rely on are experimental or research previews. Their behaviour can change with any release.
• I never measured what coordination cost me in tokens or time compared to a single session. My earlier articles say this openly. Without that baseline, I cannot claim a saving.

What I take from this

The most useful sentence I found is still the first one: more agents mainly let you spend more tokens on a problem. That is worth doing when the problem is valuable and genuinely divisible. It is a poor trade when the parts depend on each other, and in software they usually do.

Looking back, my attempts optimised the wrong thing. I tried to make messages arrive more reliably, when the evidence says the hard part is deciding whether to split the work at all, then verifying what comes back. A coordination tool that helps should probably result in less communication, not more, and should be able to show that.

When I write about the next version of my own tooling, this is the yardstick I will hold it to: compared against one well-prepared agent on the same tasks, did it finish more work, at what cost, and how often did I still have to step in?

Sources

• Anthropic, How we built our multi-agent research system
• Cemri et al., Why Do Multi-Agent LLM Systems Fail?, arXiv:2503.13657
• Kim, Liu et al., Towards a Science of Scaling Agent Systems, arXiv:2512.08296, and the Google Research summary
• Khatua et al., CooperBench: Why Coding Agents Cannot be Your Teammates Yet, arXiv:2601.13295
• When Parallelism Pays Off: Cohesion-Aware Task Partitioning for Multi-Agent Coding, arXiv:2606.00953
• Cognition, Don't Build Multi-Agents
• Claude Code documentation: Run agents in parallel, Cross-session messaging, Agent teams, Background sessions, Hooks, Channels reference
• Codex documentation: App Server, Hooks, Subagents
• Model Context Protocol, Tasks
• Agent2Agent (A2A) Protocol Specification