Multi-agent AI gets worse as you add agents

The pitch for multi-agent systems is that one model cannot do everything, so you build several specialists and coordinate them. It sounds obviously right, it maps onto how human organisations work, and it is the dominant architectural story of 2026.

Then you measure it. Recent work on orchestrator behaviour found that a flat-context supervisor's ability to steer its sub-agents correctly falls from around sixty percent with three agents to roughly twenty-one percent with ten. It degrades further as the agents become more diverse, and further again as their decision histories lengthen. The system does not scale gracefully; it degrades in a way that gets worse with exactly the growth the architecture was adopted to enable.

Multi-agent orchestration is usually sold as a capability upgrade. It is more accurately a context-management problem, and the coordination cost grows faster than the capability gained. Most teams reaching for a second agent would get more from fixing the first one.

This is what the patterns actually are, what they cost, how they fail, and the narrow set of conditions under which the trade is worth making.

What separates multi-agent from an agent with tools

The distinction gets blurred, usually by people selling frameworks, so it is worth drawing precisely.

Single-agent tool use is one model calling tools in a loop. It has one context, one decision-maker, one trace, and one thing to debug. It can be arbitrarily sophisticated and it remains one agent.

Multi-agent orchestration coordinates several agents that hand work to each other, each with its own context and its own model call. This adds four problems that do not exist in the single-agent case: shared state between agents, communication between them, failure recovery when one fails mid-workflow, and inference cost multiplied across the chain.

That list is the honest cost of the architecture. None of those problems has a clean solution, and all four are load-bearing. A team that adopts multi-agent without a plan for each is buying the costs without the benefits.

The question worth asking before adopting it: is the limitation you are hitting actually about capability, or is it about context? If a single agent fails because it lacks a tool, add the tool. If it fails because the model is not good enough, use a better model. Multi-agent addresses neither of those. It addresses the case where a single context window cannot hold everything the task requires, which is a narrower situation than it is usually invoked for.

The five patterns and what each costs

The patterns are not stylistic choices. Each has a different control-flow shape, a different cost multiplier and a different characteristic failure.

Supervisor. A top-level agent receives the request, decomposes it, delegates subtasks to specialists, and assembles the result. This is the dominant enterprise pattern, and the economics are the reason: the supervisor uses a capable expensive model while the workers use cheaper task-specific ones, which can reduce cost substantially against running the capable model throughout. It also produces a single accountability point and the clearest audit trail, which matters in regulated settings.

Its failure is that the supervisor is a single point of failure in two senses. If it misclassifies a task, the wrong specialist receives it, and misclassification rates compound across a workflow. More subtly, the supervisor accumulates context from every worker it calls, so its own context window fills as the workflow proceeds. That is the mechanism behind the degradation quoted at the top.

Pipeline. Agents in a fixed sequence, each consuming the previous one's output. Cheap, predictable and easy to reason about, because the control flow is decided in advance rather than at runtime. The limitation is that it cannot adapt: if step three reveals that step one made a wrong assumption, there is no route back.

Fan-out. One task split across parallel agents whose results are merged. The right pattern when subtasks are independent, since latency is the maximum of the branches rather than the sum. The failure is at the merge, where partial results conflict and something has to reconcile them, and reconciliation is frequently harder than the original task.

Debate. Multiple agents argue toward a conclusion, with a judge resolving. This costs at least double a single model before the judge is counted, and reported production implementations run around two and a half times single-model cost. It buys real quality improvement on some reasoning tasks and carries two specific failures: a judge that prefers confident style over correct substance produces higher-confidence wrong answers, and disagreements that do not converge loop until something stops them, which means a hard round limit is not optional.

Swarm. Many agents coordinating peer-to-peer with no central orchestrator. Scales past the bottleneck a supervisor creates and gives up the audit trail and the single accountability point in exchange. Useful at large agent counts and considerably harder to debug, since there is no single place where the decision was made.

Most published treatments list three or four of these, usually collapsing fan-out into pipeline and debate into supervisor. That conflation hides the operational differences that determine what a system costs and how it fails.

A worked comparison of what the patterns cost

Concrete numbers make the trade legible in a way the descriptions do not. Take a task that a single capable model handles in one call.

Supervisor with four cheap workers: one expensive call for decomposition, four cheap calls, one expensive call to assemble. Against running the expensive model six times, the saving is substantial, and it grows with the number of worker steps. This is the pattern's real argument and it is economic rather than about quality.

Pipeline of four agents: four calls, and if each agent needs the previous output in its context, the later calls carry accumulated material and cost more than the earlier ones. Cost grows superlinearly with pipeline length unless something summarises between steps.

Fan-out to four agents plus a merge: five calls, but wall-clock latency is one branch plus the merge rather than four sequential calls. You are buying time with money, which is the right trade for interactive work and the wrong one for batch.

Debate with three agents over three rounds plus a judge: ten calls minimum for one answer. Reported production implementations land around two and a half times single-model cost after optimisation, which implies significant work went into keeping it that low.

Swarm at scale: unbounded by construction, which is why hard spend limits in the harness are not optional rather than a nice-to-have.

The pattern that emerges from putting these side by side: the architectures that improve quality cost multiples, and the architecture that saves money does so by using worse models for most of the work. There is no configuration that is both cheaper and better, which is worth internalising before a vendor suggests otherwise.

The agent harness

The word arrived because the thing needed a name. The harness is the software layer that runs the agents: it manages tool execution, holds memory and state across steps and sessions, enforces limits, handles retries and failures, and decides what context each agent receives.

It is not the agents and it is not the framework. Frameworks give you orchestration primitives and a way to express the control flow. The harness is the operational substrate underneath, and it is where the properties that matter in production live.

What belongs in a harness. Hard limits on rounds, tool calls and total spend, because an agent loop with no ceiling will find one eventually. Timeouts per step and for the whole workflow. Retry policy with the awareness that retrying a failed action is not always safe, since some tool calls have side effects. Persistent state, so a workflow interrupted at step seven can resume rather than restart. Tracing at a granularity that lets you reconstruct which agent decided what and on what basis. And context assembly, deciding what each agent sees, which is the single highest-leverage thing in the whole system.

Why it matters more than the framework choice. Framework comparisons dominate the discussion and are largely a distraction. The frameworks differ in how they express control flow and converge on similar capability. What none of them supplies is access control tied to user identity, per-workflow cost enforcement, and audit trails that map each call to a model version and data classification. Those are the requirements that regulated deployments actually fail on, and they are left to whoever builds the harness.

Context pollution is the dominant failure

Everything above is secondary to this, which is the finding that should change how the architecture is approached.

An orchestrator holding a flat context accumulates material from every agent it supervises. As the number of agents rises, that context fills with information relevant to other agents' work, and the orchestrator's ability to act correctly on any specific agent's situation degrades. The measured collapse from roughly sixty percent to twenty-one percent between three and ten agents is not a scaling inconvenience. It is the architecture failing at the scale it was adopted to reach.

Three things make it worse. Agent diversity, because contexts from dissimilar agents interfere more than contexts from similar ones. History length, because decision traces accumulate and older material is not obviously safe to drop. And wrong-agent contamination, where the orchestrator applies reasoning from one agent's situation to another's, which is a failure mode that does not exist in single-agent systems at all.

The mitigations are all forms of not showing the orchestrator everything. Keep a compact registry, a short status summary per agent, as the default view, and load an agent's full context only when actively working on that agent. Scope handoffs precisely so each agent receives what it needs and nothing else. Summarise aggressively between steps, while noting the documented risk that iterative rewriting can collapse a context to the point where accuracy falls below not summarising at all.

The design goal is worth stating plainly, because it is the opposite of the intuition: the orchestrator should see as little as possible. Sharing context between agents feels like coordination and is mostly contamination.

Sycophancy cascading, and false consensus

A second failure specific to multi-agent, and it undermines the main argument for the debate pattern.

Models trained on human preference tend toward agreement. Put several in a discussion and they converge, and they converge whether or not the position they converge on is correct. Agreement between three agents therefore carries much less evidential weight than it appears to, because they were selected for agreeableness rather than for independence.

The practical consequence is that a debate producing consensus has not necessarily validated anything. Five rounds across three agents is fifteen model calls, real latency, real cost, and a result that can be confidently and unanimously wrong. Reviewers and users read the consensus as verification, which makes this worse than a single wrong answer, since a single wrong answer does not arrive with social proof.

Mitigations exist and are partial. Assign opposed roles rather than asking for opinions. Use different model families, since same-family agents share failure modes. Have the judge evaluate reasoning quality rather than counting votes. None of these fully solves it, because the underlying tendency is trained in.

When multi-agent is actually the right call

The conditions are narrower than the discourse implies, and being specific about them saves a great deal of wasted work.

Context exceeds one window. Not "the prompt is long", but the task requires holding more material than any single context can carry, with distinct subtasks that each need only a slice. This is the original motivation and remains the strongest one.

Subtasks need different capabilities. A workflow requiring code execution, image analysis and a domain model that only exists as a fine-tuned checkpoint is a real case for specialists, because no single model covers it.

Cost structure favours it. A cheap model handling the volume with an expensive one supervising can substantially reduce spend against running the expensive model throughout. This is a real and frequently underrated reason, and it is an economic argument rather than a capability one.

Parallelism buys latency. Independent subtasks running concurrently finish in the time of the slowest rather than the sum. Only applies when the subtasks are truly independent, which is rarer than it looks.

Organisational boundaries. Different teams owning different agents with clear interfaces is a legitimate reason even when a single agent would be technically simpler, for the same reasons microservices exist.

Against that, the situations where people reach for multi-agent and should not: the single agent is failing on tasks a better model would handle; the agent lacks a tool; the prompt is badly structured; or the architecture is being chosen because it is the current pattern rather than because a constraint demanded it. In each of those, adding agents adds coordination cost to an unsolved problem.

What none of the frameworks give you

Framework comparison is where most of the writing on this topic goes, and it is the least important decision. Worth naming what is left over regardless of which you pick.

Governance. Which agent may access which system, tied to the identity of the user on whose behalf it acts rather than to a service account. This is the requirement that blocks regulated deployment and it is not in any framework.

Cost enforcement. Not observability of cost, which several provide, but hard limits that stop a workflow before it spends more than its budget. Agent loops fail expensively and the failure is usually discovered on an invoice.

Audit trails that satisfy a compliance review. Mapping each call to a model version, a data classification and an authorising identity. Tracing that helps a developer debug is a different artefact from tracing that satisfies an auditor.

Failure semantics. What happens when agent four fails after agents one through three have already taken actions with side effects. This is a distributed-systems problem with a long literature, and agent frameworks largely do not address it.

Each of these is buildable and none of them is free, and a team that has not accounted for them has underestimated the project by a wide margin.

What is unresolved

Whether the degradation is architectural or an implementation artefact. Context isolation mitigates the collapse described above, and whether it fully solves it or merely defers it to a higher agent count is not established. If the latter, there is a ceiling on agent count that no amount of engineering removes.

Whether swarms scale. Peer-to-peer coordination at high agent counts avoids the orchestrator bottleneck and reported implementations run to hundreds of agents. Whether the results are reliable enough for anything consequential, and whether the loss of an audit trail is acceptable, remain open. The debugging story in particular is unsolved.

How to evaluate a multi-agent system at all. Single-agent evaluation is already hard. Evaluating a system where the failure could be in decomposition, delegation, an individual agent, the merge, or the coordination between any of them is substantially harder, and no accepted methodology exists. Most teams deploying these systems cannot say which component is responsible when output is wrong.

Whether agent specialisation is real. The premise is that a specialist outperforms a generalist on its slice. As general models improve, the margin narrows, and there is a reasonable position that specialisation is compensating for model limitations that are being removed on their own. If so, multi-agent architectures adopted for capability reasons will look like overhead in retrospect, while those adopted for cost or organisational reasons will survive.

The counter-argument

The case against the scepticism above deserves a fair statement.

The degradation figures come from a flat-context orchestrator, which is the naive implementation. Systems built with context isolation from the start do not exhibit the same collapse, so the finding is better read as evidence about how to build these systems than as evidence against building them. That is a fair reading and it is how the source work frames it.

There are also production deployments delivering real value at scale. Supervisor patterns coordinating specialist agents over large procedural corpora have taken tasks from ten minutes to under a minute in documented enterprise use. Those systems exist and work, and dismissing the architecture on the basis of a benchmark would be as wrong as adopting it on the basis of a demo.

And the cost argument is strong and independent of capability. Routing the volume to cheap models under expensive supervision reduces spend substantially, and that holds whether or not specialisation improves quality. A team adopting multi-agent purely on economics is making a defensible decision that none of the above contradicts.

The honest position is not that multi-agent is wrong. It is that it is an architecture with real costs that is frequently adopted without acknowledging them, on the assumption that more agents means more capability, when the measured relationship runs the other way unless the system is built carefully.

The short version

Multi-agent orchestration coordinates several agents that hand work to each other, which is different from one agent calling tools in a loop and adds four problems: shared state, inter-agent communication, failure recovery, and inference cost multiplied across the chain. Five patterns dominate production, each with a distinct cost multiplier and failure mode: supervisor, pipeline, fan-out, debate and swarm. Supervisor is the enterprise default because a capable model supervising cheap workers reduces spend and produces a clean audit trail.

The dominant failure is context pollution. An orchestrator holding a flat context accumulates material from every agent it supervises, and measured steering accuracy falls from around sixty percent at three agents to roughly twenty-one percent at ten, degrading further with agent diversity and history length. The mitigation is to show the orchestrator less: a compact registry by default, full context only for the agent currently being worked on, precisely scoped handoffs. Sharing context feels like coordination and is mostly contamination.

A second failure specific to multi-agent is sycophancy cascading. Models trained on human preference converge on agreement regardless of correctness, so consensus between agents carries far less evidential weight than it appears to, and arrives with social proof attached.

The agent harness, the layer managing tool execution, state, limits, retries and context assembly, matters more than framework choice. What no framework supplies is identity-tied access control, hard cost enforcement, compliance-grade audit trails, and failure semantics when an agent fails after earlier agents have taken actions with side effects.

The test worth applying before adopting it: is the constraint you are hitting about capability, or about context? Multi-agent addresses the second. For the first, a better model or a missing tool will do more, and adding agents adds coordination cost to a problem that was never a coordination problem.

Common questions

What is multi-agent orchestration? Coordinating several AI agents that hand work to each other toward a shared goal, each with its own role, context and model calls. It differs from single-agent tool use, where one model calls tools in a loop with one context and one decision-maker. The difference introduces four problems that do not otherwise exist: shared state between agents, communication between them, recovery when one fails mid-workflow, and inference cost multiplied across the chain.

Why does adding more agents make performance worse? Because an orchestrator holding a flat context accumulates material from every agent it supervises, and that context fills with information relevant to other agents' work. Measured steering accuracy falls from around sixty percent with three agents to roughly twenty-one percent with ten, degrading further as agents become more diverse and their histories lengthen. A failure mode called wrong-agent contamination, where the orchestrator applies one agent's reasoning to another's situation, does not exist in single-agent systems at all.

What is an agent harness? The software layer that runs agents: managing tool execution, holding state and memory across steps and sessions, enforcing round and spend limits, handling retries and failures, and deciding what context each agent receives. It is distinct from the framework, which supplies orchestration primitives and control-flow expression. The harness is where production properties live, and it matters considerably more than which framework you chose.

What are the main multi-agent patterns? Five dominate. Supervisor, where a capable orchestrator delegates to cheaper specialists, which is the enterprise default for cost and audit reasons. Pipeline, a fixed sequence, cheap and predictable and unable to adapt. Fan-out, parallel branches merged afterwards, where the merge is the hard part. Debate, multiple agents arguing with a judge, costing at least double before the judge and around two and a half times in reported production use. Swarm, peer-to-peer with no orchestrator, which scales past the bottleneck and gives up the audit trail.

When should I use multi-agent instead of a single agent? When the task exceeds one context window with distinct subtasks each needing a slice; when subtasks require capabilities no single model has; when a cheap model handling volume under expensive supervision meaningfully reduces cost; when independent subtasks can run in parallel for latency; or when different teams own different agents with clear interfaces. Not when a single agent is failing because the model is too weak, a tool is missing, or the prompt is badly structured, since adding agents adds coordination cost to an unsolved problem.

Does having agents check each other's work improve reliability? Less than it appears. Models trained on human preference tend to converge on agreement, so consensus between agents reflects a trained tendency toward agreement rather than independent verification. Five rounds across three agents is fifteen model calls and can produce a confidently unanimous wrong answer, which is worse than a single wrong answer because it arrives with apparent validation. Partial mitigations: assign opposed roles, use different model families, and have the judge assess reasoning quality rather than count votes.

Which multi-agent framework should I choose? It matters less than the discussion suggests. The leading options differ mainly in how they express control flow and converge on similar capability. What none supplies is access control tied to the identity of the user the agent acts for, hard per-workflow cost limits rather than cost observability, audit trails mapping calls to model versions and data classifications, and failure semantics when an agent fails after earlier agents have taken actions with side effects. Those are what regulated deployments fail on, and they are yours to build regardless of the framework.

How do I stop context pollution in a multi-agent system? Show the orchestrator less. Keep a compact registry of short status summaries, on the order of a couple of hundred tokens per agent, as the default view, and load an agent's full context only while actively working on it. Scope handoffs so each agent receives exactly what it needs. Summarise between steps while watching for the documented failure where iterative rewriting collapses a context so far that accuracy falls below not summarising at all. The design goal is counterintuitive: sharing context between agents feels like coordination and is mostly contamination.