Multi Agent AI: When Two Agents Beat One

Multi agent AI beats a single agent in exactly three situations. The second agent's working transcript would damage the first agent's context if they shared it. The job splits into pieces that don't depend on each other, so they can run at the same time. Or the second agent must be allowed something the first must be forbidden, like approving work it didn't write. If none of those three holds, one agent with one more tool is cheaper, faster to debug, and usually better, and the vendors who sell multi-agent platforms say so in their own guides.

That's the whole decision. The rest of this article gives you a test for each of the three reasons, the cost side with the only measured numbers I could find, a calculation that shows where the money and the context actually go, and the smallest two-agent setup that I think earns its keep in a coding workflow. It also names the ways two agents fail, which the pages ranking for this query leave out entirely.

What Multi Agent AI Means, Precisely

Microsoft's decision guide has the cleanest pair of definitions. A single-agent system consolidates all logic into one agent. A multi-agent system divides responsibilities across specialized agents and requires additional coordination and orchestration. Each agent inside the system is still an agent in the ordinary sense, a model with tools in a loop, which the how to build an AI agent post walks through one file at a time.

The arrangements come in two shapes. OpenAI's agent guide calls them the manager pattern, where a central agent calls the others as tools and keeps the user, and the decentralized pattern, where peers hand off execution to each other and whoever holds the task talks to the user. IBM's page describes the same split as centralized versus decentralized networks and then adds organizational structures on top, hierarchical, holonic, coalition, team. Those labels are fine for a whiteboard. For deciding whether to build one, the three mechanisms matter more than the shape.

The Three Reasons A Second Agent Helps

Run the three tests on the job in front of you. A research question that fans out over twenty sources passes the first two. A refund flow where one agent drafts and another approves passes the third. A bug fix in one module usually fails all three, and Anthropic's own engineering post says as much, noting that most coding tasks involve fewer truly parallelizable pieces than research does.

The test I'd apply hardest is the second one. "Independent" means you can name the subtasks before the run. If the split only becomes clear after the first agent has read half the codebase, that's one agent doing the reading and then deciding, which is a single-agent system with a planning step.

The Cost Side, With Numbers

Anthropic's post on their multi-agent research system is the only page I found that measured both sides. Their lead-plus-subagents setup, with Claude Opus 4 leading and Claude Sonnet 4 workers, beat a single Opus 4 agent by 90.2 percent on their internal research eval. That's their eval and their models at the time, so treat it as one data point rather than a law. The costs they report travel better. Agents use about four times the tokens of a chat interaction, and multi-agent systems about fifteen times. Token usage alone explained 80 percent of the performance variance in their analysis, which is a polite way of saying the improvement is mostly bought.

Microsoft's guide lists the overheads without numbers. Each agent processes redundant context, communication overhead multiplies with agent count, latency accumulates at every handoff, and every component needs its own prompt, monitoring, and debugging. All true, and all things you can see in a transcript.

Where does the money go, then? I worked it through for a job that passes the first two tests. Ten documents of 5,000 tokens each, a 2,000-token fixed prefix, one document read per turn, and the whole conversation resent every call, which is how the API works.

Uncached, the single agent's input is quadratic in the number of documents, because turn eleven resends the first ten, and it costs about three and a half times the two-tier version. With prompt caching, which the models page prices at 10 percent of the base input rate for cache reads, the repeats get cheap and the two approaches land within a few cents of each other at Opus 5 rates, roughly $0.38 against $0.43 for input. I've left cache writes and output tokens out, and the worker summaries add output the single agent never produces.

So the money mostly washes out once you cache. What doesn't wash out is the last two columns. The single agent makes its final decision over 52,000 tokens of raw documents. The lead makes it over 7,000 tokens of summaries, in a fraction of the wall-clock time, and that compression is the thing Anthropic names as the reason the design works. It's also the thing that fails, because a summary drops detail, and I'll come back to that.

The Smallest Two-Agent System Worth Building

For coding work, the two-agent setup I'd build first is a reviewer that cannot edit. It passes the first test, because a review reads a lot of files you don't want in the implementing agent's transcript, and it passes the third, because the autonomous agent post argued that no agent should approve its own work, and a reviewer with no write tools is that rule enforced in configuration.

In Claude Code that's one file. The subagent docs put project subagents in .claude/agents/, with YAML frontmatter and the system prompt below it:

---
name: reviewer
description: Reviews a diff for contract violations, test weakening, and scope creep. Use after any multi-file change and before a commit.
tools: Read, Grep, Glob
model: sonnet
maxTurns: 15
---

You review changes. You cannot edit files and you must not suggest that you can.

Read the diff and the tests it touches. Report, in this order:
1. Any behavior the task did not ask for.
2. Any test that was loosened, skipped, or deleted.
3. Any file outside the stated scope.
4. Whether the new tests would fail on the old code, with the reason.

Finish with one line: APPROVE or REQUEST CHANGES, and why.

Three fields do the work. tools: Read, Grep, Glob is the docs' own read-only trio, so the reviewer physically can't edit, the same "cannot call what doesn't exist" boundary from the single-agent post. maxTurns: 15 is the stop set. And description is what the main agent uses to decide when to delegate on its own, though you can also invoke it by name or with an @-mention. The docs list model values of sonnet, opus, haiku, fable, a full model ID, or inherit, and a cheaper reviewer is fine here because the report format is fixed.

The report format is the part people skip. A subagent returns only its summary to the main conversation, and the full transcript stays behind. So the summary has to carry everything the main agent needs, which is why the prompt dictates a numbered report and a one-line verdict rather than "give feedback". Whatever the reviewer noticed and didn't write down is gone.

Two limits from the docs are worth knowing before you get ambitious. Subagents can spawn their own, up to three layers below the main conversation by default, and a session allows 20 concurrent subagents before spawning fails. Both are configurable. I would not raise either until a single reviewer has caught a real problem.

Where Two Agents Fail

The first row is the one I'd expect to hit first. It's the direct cost of the compression that made the design worth it. Every time I've seen a "the orchestrator got it wrong" complaint, the interesting question was what the worker's summary format allowed it to leave out.

When One Agent Is Still Right

Microsoft's guide makes a point I'd underline. Distinct roles such as planner, reviewer, and executor might suggest multiple agents, but they don't automatically justify them, and a single agent using persona switching, conditional prompting, and tool permissioning often does the job. OpenAI's guide says to maximize a single agent first and to split only when the prompt has grown too many conditional branches or the tools overlap, and offers the detail that some deployments manage more than fifteen distinct tools while others struggle with fewer than ten overlapping ones.

That matches what I see in my own monorepo, where almost everything that runs unattended is one agent with a short tool list and a checker. The reviewer above is the exception, and it earns the exception through the permissions row rather than through capability. If your reason for a second agent is "the prompt is getting long", the fix is a shorter prompt or a better tool description. If the reason is "this agent must not be able to do that", you've found a real boundary, and a second agent is how you draw it.

Is Copilot A Multi-Agent System?

Copilot is several products, so the honest answer is per product. The cloud agent that you assign an issue to is a single agent per task. GitHub's documentation says it works on one branch at a time, opens exactly one pull request per task, and stops at a hard 59 minutes. You can define custom agents for different kinds of task, but those are separate single agents chosen at assignment time rather than agents spawned inside one run. What GitHub does enforce across the boundary is the separation-of-duties rule, since the person who requested the PR can't approve it, which is the third mechanism above implemented in repository plumbing rather than in a second agent.

Is Multi-Agent The Same As Agentic AI?

No. Agentic AI describes one agent acting on its own through tools, the loop in the single-agent post. Multi-agent describes an arrangement of two or more of those loops. Every multi-agent system is agentic. Most agentic systems are single agents, and by the three tests above most of them should stay that way.

What Are Some Examples Of Multi-Agent AI Systems?

The documented ones are more useful than the imagined ones. Anthropic's research feature is a lead agent that plans, spawns parallel subagents to search, and synthesizes their summaries. OpenAI's guide shows a manager agent that exposes Spanish, French, and Italian translator agents as tools, and a decentralized triage agent that hands a customer off to support, sales, or orders. Microsoft's guide describes a payment flow with one agent preparing a transaction and a different agent validating it. And a Claude Code session with the reviewer file above is a two-agent system the moment the main agent delegates a review. Each of those passes at least one of the three tests, and it's worth noticing which one.

What Are The Top 3 AI Agents?

By arrangement they tie, since every hosted coding agent is a single agent per task, and the hosted research features are all a lead with workers. What separates products is the permission ledger and how they score on a task you can rerun. The AI coding assistant scorecard is the way I'd answer that question for your own work rather than from a list.

The other two questions that show up beside this one have their own posts. The seven-type taxonomy is about how a single agent decides, and the types of AI agent post explains why multi-agent systems get appended to it as a category error. And ChatGPT the chat app is not an agent, though the Codex it ships with is a single one.

Start With The Reviewer

If you've built the single-agent loop and it runs clean, add the reviewer file and nothing else. Run a real change through it and read the report. If the report catches something, you have a two-agent system that paid for itself on the permissions test. If it approves everything, tighten the rubric before adding a third agent, because a third agent inherits every weakness of the summary format that the second one had.

Then, and only then, try the parallel case, on a job where you can write the subtasks down before the run starts. Count the tokens. Anthropic's fifteen-times figure is the honest expectation, and the calculation above shows that caching removes most of the money argument for splitting. What's left is context quality and wall-clock time, which are real, and which are only worth buying when the three tests say the job needs them.