When Do Multiple AI Agents Beat a Single Agent?

In one week of June 2025, two of the most respected AI engineering teams in the world gave the opposite advice on the same question.

Anthropic published how it built a multi-agent research system and reported that a team of agents beat a single agent by 90.2 percent on its internal research eval. Days earlier, Cognition, the team behind the coding agent Devin, published an essay with a blunt title: Don’t Build Multi-Agents.

Both teams are excellent. Both were honest. They still disagreed. That disagreement is the most useful thing an enterprise leader can study right now, because it exposes the question most AI roadmaps skip.

The question is not how to coordinate many agents. The question is whether you should use many agents at all, and what you have to build before you do.

The Decision Most AI Roadmaps Skip

Here is the pattern we see again and again. A company ships one AI agent. It works. Metrics improve. Leadership approves expansion. The roadmap then assumes more agents, as if going from one agent to ten is just addition.

It is not. Adding agents adds a new system that did not exist before: the coordination layer. And coordination is where most of the trouble lives.

Gartner predicts that more than 40 percent of agentic AI projects will be canceled by the end of 2027, based on a poll of more than 3,400 organizations. Gartner points to rising costs, unclear business value, and weak risk controls. Multi-agent designs make all three of those harder, because they cost more to run, they are harder to tie to a clear outcome, and they spread accountability across a chain.

So the first move is not technical. It is a decision. For each customer journey you want to automate, ask whether it actually needs a team of agents, or whether one strong agent with good tools would do the job at a fraction of the cost and risk.

What Anthropic Found When Many Agents Beat One

Anthropic’s result is real, and it is worth understanding precisely, because the details tell you when multi-agent pays off.

A system with a lead agent (Claude Opus 4) directing several subagents (Claude Sonnet 4) beat a single Opus 4 agent by 90.2 percent on an internal research eval. The reason matters. Research is a breadth-first task. It splits into many independent searches that can run at the same time. Parallel agents cover more ground, then a lead agent pulls the findings together.

But there is a cost. Anthropic reported that its multi-agent system used about fifteen times the tokens of a normal chat. The team was direct about why the approach works at all. In its own analysis, token usage alone explained roughly 80 percent of the performance difference in one eval. Multiple agents win in large part because they spend far more compute on the problem.

That gives leaders a clean test. Multi-agent makes sense when the work is broad, splits into parallel parts, and the value of a better answer clearly beats a fifteen-times cost. A complex research task for a high-value client can clear that bar. A routine password reset cannot.

Why Cognition Says Don’t Build Them

Cognition looked at a different kind of work and reached a different conclusion. Its essay argues that splitting a task across agents tends to produce fragile systems, because context is shared poorly and decisions conflict.

The core idea is simple and sharp: actions carry implicit decisions, and conflicting decisions carry bad results. When two agents each handle part of a task, they do not see each other’s assumptions. One agent decides the customer wants a refund. Another, working in parallel, decides the customer wants to keep the service and get a credit. Each acts reasonably on its own. Together they produce a mess.

Cognition’s advice for most tasks is to keep the work in a single, continuous thread of context, and to treat the real skill as context engineering rather than agent count. Anthropic makes a similar point in its guidance on effective context engineering. That is the discipline of deciding what information the system needs, in what form, and at what moment.

The two views are not actually a contradiction. They describe different tasks. Breadth-first work that parallelizes well favors multiple agents. Step-by-step work, where each decision depends on the last, favors one agent with strong context. The mistake is choosing an architecture by fashion instead of by the shape of the task.

How Cascade Failure Actually Happens

When a multi-agent system does fail, it usually fails in a chain, not in one place. We call this cascade failure.

An early agent makes a small error. It miscategorizes a customer’s intent, misreads an account flag, or applies a policy rule that does not fit. That error then becomes the premise for every agent after it. Each later agent acts correctly on what it was told. The problem is that what it was told was wrong.

This is different from single-agent failure in one important way. In a single-agent setup, a human can review the output and catch the mistake before it reaches the customer. In a chain, the error can pass through several automated steps before any person sees it. By then the customer may have received wrong information, a resolution that does not fit their case, or an automated action like a cancellation, a booking, or a refund that should never have happened.

Anthropic’s own write-up describes early versions of its system making coordination errors, such as spawning far too many subagents for a simple request or chasing sources that did not exist. The fix was largely better instructions and better context, not a better model. That is the recurring lesson. The model is rarely the constraint.

Designing against cascade failure takes three habits.

First, pass confidence, not just answers. If an early agent is only 55 percent sure about a customer’s intent, every agent downstream needs to know that. An agent receiving a low-confidence input should slow down, ask for clarification, or escalate, rather than treat a guess as a fact.

Second, place human checkpoints before irreversible actions. Processing a refund, changing a contract, or booking an appointment should not happen downstream of an uncertain step without a person confirming it.

Third, keep traceability. When something goes wrong, you must be able to point to the exact agent and decision that started the cascade. Without that, debugging is guesswork and governance is for show. Our enterprise AI control gap analysis goes deeper on why traceability is the backbone of trustworthy automation.

Treat Agent Handoffs as Knowledge Transfer

Contact center leaders already know this problem in human form.

When a frontline agent escalates a hard case to a specialist, the result depends on how well context transfers. If the specialist gets a full briefing, account history, what the customer already tried, what the frontline agent ruled out, the conversation continues smoothly. If that context is lost, the customer has to start over. Frustration climbs with every repeat.

Multi-agent AI fails the same way. Agents pass outputs, not understanding. An agent that correctly identifies a problem hands the next agent a short summary. That summary is an interpretation. It carries the conclusion but often drops the evidence and the constraints that produced it. The receiving agent acts on the summary. If the summary missed a detail that matters two steps later, there is no way to recover it.

So design each handoff on purpose. For every agent-to-agent transfer, answer four questions. What is the minimum information that must move? In what format? At what confidence level? And what does the receiving agent do when the information it gets is not enough? These are the same questions that make human escalation and fallback flows work, applied to software.

Give Every Agent a Job Description

Microsoft Research’s AutoGen project, which studies multi-agent conversation, keeps surfacing a requirement that teams underestimate: clear, non-overlapping roles.

When two agents can both do the same task, and no rule says which one acts, you get one of two bad outcomes. Either both act, causing duplicate emails or double bookings, or neither acts, each waiting for the other while the customer sits and waits.

Any leader who has managed people recognizes this. A handoff works when both sides know exactly where one person’s job ends and the next begins. The same precision is required for agents.

Here is a practical test. If you cannot explain an agent’s role clearly enough for a new team member to understand without questions, the role is not precise enough for an agent either. Write agent roles the way you write job descriptions: specific duties, clear decision limits, explicit escalation rules, and defined handoffs to neighboring roles. That precision is not paperwork. It is the specification that decides whether your agents coordinate or collide.

The Protocols That Make Coordination Auditable

Agents that work together need a shared way to communicate. Two open standards now matter here.

The first is Anthropic’s Model Context Protocol (MCP). MCP gives agents one consistent interface to connect to data sources and tools. Instead of building a custom connection between every agent and every system, each side implements the standard once. That lowers integration work and, just as important, lets you log what information moved between which agents at each step.

The second is the Agent2Agent (A2A) protocol, which Google released in April 2025 and donated to the Linux Foundation in June 2025 with backers including AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. A2A handles a different problem: how agents built on different models or platforms talk to each other. Enterprise systems usually span more than one platform, so a shared protocol prevents every connection from becoming its own fragile, custom integration.

These standards matter for two reasons beyond convenience. They cut the cost and fragility of custom interfaces. And they enable governance, because communication that follows a known standard can be logged in a structured way. When you evaluate a multi-agent platform, ask whether it builds on open standards or locks you into proprietary connections, and ask exactly how it logs cross-agent activity. A demo that looks smooth but hides its coordination is a governance risk waiting to scale.

Governance Has to Move to the Orchestration Layer

Most AI governance frameworks were built for one agent at a time. A single agent has an owner, a policy, a log, and an approval step for risky outputs. Accountability is local, so governance is tractable.

Multi-agent systems break that model. When four agents produce one customer-facing answer, who is accountable? The agent that acted last? The agent whose early error drove the cascade? The team that designed the orchestration? The question is genuinely hard, and that is exactly where regulators are looking.

The EU AI Act sets the standard for high-risk systems. It requires automatic record-keeping so a system’s actions can be traced (Article 12) and effective human oversight (Article 14). In a multi-agent system, per-agent logs alone cannot meet that bar, because the story of any outcome lives across the chain. If your CX automation could touch high-risk decisions, our EU AI Act CX deadline guide covers what to prepare.

The NIST AI Risk Management Framework helps here because it is built around system-level functions: govern, map, measure, and manage. Applied to a full orchestration rather than to single models, it scales more naturally than governance designed for one agent. For a deeper operating model, see our work on ISO 42001 enterprise AI governance.

In practice, extending governance to the orchestration layer means four things: audit logs that follow decisions across the whole chain, one named owner accountable for the full system, the ability to halt the chain when any agent produces a low-confidence or non-compliant output, and a review path that any agent can trigger when it hits uncertainty.

What CX Leaders Should Do Now

Decide whether you need multiple agents before you build them. For each journey, weigh breadth and value against cost. Reserve multi-agent designs for broad, parallel, high-value work. Use a single strong agent for narrow, step-by-step tasks. This one decision will keep you out of the 40 percent Gartner expects to be canceled.

Design the coordination layer first. Before you add a second agent, define what information moves between agents, in what format, at what confidence level, and where a human reviews the chain. Coordination does not emerge from proximity. It has to be designed.

Write agent roles like job descriptions. Specific duties, clear limits, explicit escalation, defined handoffs. If a new hire would be confused by the role, an agent will fail at it.

Run the human handoff test. Look at how well your people transfer context during escalations today. Where it works, copy the structure into your AI design. Where it fails, fix the human process first, because multi-agent AI will inherit that same loss. Then measure it with a real agentic AI measurement framework and ongoing agent evaluation.

Extend governance to the whole system. Move ownership, audit, and approval from the single agent up to the orchestration. Identify which interactions could count as high-risk, and build human oversight into exactly those points.

Buy on standards and audit, not on demos. Prefer platforms built on open standards like MCP and A2A. Ask how they detect cascade failure and how they pass confidence from one agent to the next. See our view on the Anthropic enterprise agent stack for how these pieces fit together.

The Real Constraint Is Coordination, Not the Model

A well-designed multi-agent system can handle a full customer journey: contact, verification, diagnosis, resolution, and follow-up. Each agent is specialized and fast. Context moves cleanly between them. The customer feels one smooth conversation, and the organization holds a complete, auditable record of every step.

That outcome is real, and Anthropic’s results show how strong it can be. But it depends on treating coordination as the main design task, not as something engineering will sort out after the agents exist. Cognition’s warning and Gartner’s forecast point at the same risk from the other side: teams that keep adding agents without building the coordination layer do not compound value. They compound failure.

The models are not the constraint. The coordination design is. Decide whether you need a team of agents, then build the handoffs, roles, protocols, and governance that let a team actually act like one.

---

ICX helps organizations make the single-versus-multi-agent decision, then design the orchestration, agent roles, handoff protocols, and governance that make agentic AI reliable in production. Visit the services page or book a discovery call to talk through what coordinated agent design means for your program.

---

Key Takeaways

• The first question is whether to use multiple agents at all, not how to coordinate them. Anthropic showed many agents beating one by 90.2 percent on research, while Cognition warned that splitting work breaks context. They are both right, for different kinds of tasks.
• Multi-agent wins on broad, parallel, high-value work and loses on narrow, step-by-step work. Anthropic’s system used about fifteen times the tokens of a normal chat, so the better outcome has to justify the cost.
• Most multi-agent failures are coordination failures, not model failures. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, driven by cost, unclear value, and weak controls.
• Cascade failure is the signature multi-agent risk. One early error becomes the premise for every later agent and stays invisible until it reaches the customer. Pass confidence, place human checkpoints before irreversible actions, and keep full traceability.
• Agent handoffs are knowledge transfer problems. Agents pass summaries, not full context. Design each handoff on purpose, the same way good human escalation works.
• Governance must move from the single agent to the orchestration layer. Per-agent logs cannot satisfy EU AI Act record-keeping and human-oversight requirements in a multi-agent chain.
• Open standards like MCP and A2A lower integration cost and make cross-agent activity auditable. Buy on standards and audit capability, not on a polished demo.

---

Sources

1. Anthropic: How we built our multi-agent research system
2. Cognition: Don’t Build Multi-Agents
3. Gartner: Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027
4. Anthropic: Model Context Protocol
5. Anthropic: Effective Context Engineering for AI Agents
6. Google Developers Blog: Google Cloud donates A2A to the Linux Foundation
7. Linux Foundation: Linux Foundation Launches the Agent2Agent Protocol Project
8. Microsoft Research: AutoGen Project
9. European Union: EU AI Act, Article 12: Record-Keeping
10. European Union: EU AI Act, Article 14: Human Oversight
11. European Commission: Regulatory Framework for AI
12. NIST: AI Risk Management Framework

---

Human Review & AI Assistance

This article was developed using AI-assisted research, analysis, and drafting workflows. A human reviewer evaluated the content before publication. Sources were reviewed for accuracy at the time of publication. While every effort has been made to ensure accuracy, readers should independently verify information before making business, legal, financial, regulatory, or technical decisions.