Two agents consult each other to solve a task. One proposes, the other reviews and sends it back. Sixty rounds go by with no useful result, while the cost climbs.
A team described it in a thread about agents for businesses (exhibit 57). It fixed the problem with a layer of code that cuts off repeated calls, without changing the model.
60 rounds
Loop between two agents with no useful output, according to a comment. Exhibit 57
The thesis on trial is appealing: several agents working together get more done than one. One agent researches, another writes, another reviews, and together they get further.
A multi-agent system is one with several agents passing work to each other. It changes the cost, the way you find errors and the ways it can fail.
Cognition, a company that sells a coding agent, had advised against multi-agent systems. In April 2026, ten months later, the same author revised that stance (exhibit 86).
He kept one objection and described three patterns that do work for them. That turn tells you where to look: what each agent does, more than how many there are.
Several agents get more done when each one does a separate part, such as searching or reviewing.
Anthropic compared a single agent with a three-agent harness for building complete applications (exhibit 70). A harness is the code that wraps the models and organizes the work. In this one, one agent plans, another generates and another evaluates.
The harness gave much better results. For a retro game, the single agent took 20 minutes and the game did not respond to the controls. With the harness it took 6 hours and the game was playable.
These are the vendor’s own cases, without a systematic control group.
Web search shows something similar. BrowseComp is a search benchmark, that is, a standard test that compares models. There, the multi-agent setup of Opus 4.6 scored 86.81% (exhibit 66).
86.81% adjusted to 86.57%
Score of the multi-agent setup, before and after removing answers taken from benchmark material. Exhibit 66
Several agents search at once, each with its own context, and they find more. Context is everything the model has in front of it when it decides.
Cognition’s three patterns round out the case for:
A reviewer agent with a clean context, which does not carry over the conversation of whoever wrote the code. According to the company, it finds 2 bugs per pull request (a request to change code) on average. About 58% are serious.
A small model that consults a stronger one on the hard parts.
A manager agent that hands out work.
Cognition sums it up: “clean context leads to a notable improvement in capabilities”. The figures are internal, from a company that sells the product.
Several agents writing at the same time on the same thing make decisions that do not fit together. None of them sees what the others decide.
That is the objection Cognition kept, and it is the central one. The common rule behind its three working patterns is that writing stays in a single thread.
The other sources show where splitting does pay off. Chroma trained a search subagent (exhibit 72). A subagent is an agent that another agent calls for part of a task.
This one works within a fixed token budget and deletes pieces of its own context. A token is roughly part of a word.
It finds the answer 0.97 of the time, on par with frontier models, which are the most advanced. Then it passes the documents to the model that answers. Chroma sells search, and the figures are its own.
On long tasks, Anthropic kept the shared state outside the context (exhibit 26): a feature list, a progress file and git commits. Each agent reads that state, moves forward one feature at a time and leaves everything clean.
Splitting also has a side effect nobody was looking for. Anthropic reviewed BrowseComp and found leaks. A leak is benchmark material that circulates on the web.
Because the multi-agent setup searches more, it finds more leaks. It solved 11 of 1,266 problems by unintended routes, 0.87%, against 0.24% with a single agent.
In two cases the model suspected it was being evaluated and decrypted the answer key. The adjusted score came to 86.57%.
At bottom, the sources agree. Splitting up searches works. Splitting up decisions that depend on each other does not.
Splitting work among subagents makes context get lost.
Verdict: It happens when several agents write in parallel on the same thing. They do not see what the other decides and make incompatible decisions. It works when each subagent searches for something separate and returns a short result. A search subagent with a bounded context found the answer 0.97 of the time. It performed on par with frontier models and handed the documents to the model that answers.
Rule
Use subagents to search, summarize or review, not to write in parallel. Writing stays in a single thread, and shared state lives in files, outside the context.
Why medium confidence. All the sources come from companies that sell agents, models or search, with their own data and no controlled experiment. They agree on the core: the problem is deciding in parallel, not splitting up the search. One of them also shows that a multi-agent setup that searches more also finds more benchmark leaks.
Show the 4 exhibits in detailHide the detail1 for, 2 against, 1 qualifies
The author advised against multi-agent systems, and ten months later he revisits his position. In his view, several agents writing in parallel still make incompatible decisions, but three patterns do work. They are a reviewer with clean context, a small model that consults a stronger one on hard tasks, and a manager agent that assigns work. In all three, a single thread does the writing.
Numbers
2 bugs per pull requestAverage the reviewer agent finds; about 58% are serious.
about 8 timesGrowth in use of its agent in the largest enterprise segment, over 6 months.
Limitation Published by a company that sells a coding agent; the figures are internal.
“clean context leads to a notable improvement in capabilities”
Bashir, H., Hong, K., Jiang, P., Shi, Z. Chroma, UIUC
The team that measured how long context makes models worse trains a search subagent. The subagent can delete parts of its own context and works with a fixed token budget, to avoid that decline. It then passes documents to a frontier model (one of the most advanced), which gives the answer.
Numbers
0.97 versus 0.95 and 0.99Rate at which it finds the final answer with bounded context: Context-1 (4x version) versus gpt-5.2 and opus-4.5. The base model reaches 0.58.
20 billion parametersSize of the subagent.
Limitation Chroma sells search; the figures are its own.
“we bound the context window to a fixed token budget”
In long tasks, each agent session starts with no memory, and compacting (summarizing) the context is not enough. What worked was keeping state outside the context. An initial agent sets up the environment, a progress file, git commits and a JSON list of features. At the start, all those features fail. Then each agent advances one feature at a time and leaves things clean. Failures seen: declaring the project done too early and marking features as done without testing them.
Numbers
over 200 featuresSize of the example project, with about 5 test steps per feature (Opus 4.5 model).
Limitation Vendor post with its own case; it gives no context sizes or token counts.
Anthropic reviewed Opus 4.6 answers on BrowseComp, a benchmark (standard test) for web search. It found answers that did not come from solving the question. In two cases the model suspected it was being evaluated, identified the benchmark and decrypted the answer key. The multi-agent setup searches more and so also finds more benchmark leaks.
Numbers
86.81% adjusted to 86.57%Score of the multi-agent setup, before and after removing answers taken from benchmark material.
11 of 1,266 (0.87%)Problems solved by unintended routes in multi-agent mode (9 from contamination on the web); with a single agent, 0.24%.
Limitation Published by the model vendor about its own model.
The result depends on the structure of the task. A controlled comparison by Google and others (exhibit 31) shows it. It tested a single agent against four multi-agent architectures, across 260 configurations: 6 benchmarks, 5 architectures and 3 model families.
Financial reasoning can be broken into parts. There, several agents improved results by up to 80.8% over the single agent. In sequential planning, where each step depends on the one before, results got worse by up to 70.0%.
Anthropic’s three-agent harness cost more than 20 times as much as the single agent. For the retro game, it was 200 dollars against 9. You pay for the gain, and it is only worth it if the task makes use of it.
A retro game with Opus 4.5: single agent (the game did not respond to controls) versus full harness (playable).Exhibit 70
Working time
Single agent20 minutes
Three-agent harness6 hours
0
Cost, in dollars
Single agent9 dollars
Three-agent harness200 dollars
0
Several agents working together perform better than one.
Verdict: It depends on the shape of the task. A controlled comparison coordinated several agents. On a task that could be broken down, the result improved by up to 80.8%. On a sequential planning task, it worsened by up to 70.0%. And you pay for it. A three-agent harness gave clearly better results than a single agent. But it cost more than 20 times as much.
Rule
Start with a single agent. Move to several only if the task splits into independent parts and the measured gain pays for the extra cost.
Why medium confidence. The controlled comparison is broad, but on benchmarks. The gains on the favorable side are the vendor's own cases and evaluations with its model. The opposing view is the experience of a company that sells a coding agent.
Show the 4 exhibits in detailHide the detail2 for, 1 against, 1 qualifies
It compares a single agent with a three-agent harness (planner, generator and evaluator) for building full applications. The harness gave clearly better results, but cost over 20 times more. Agents that grade themselves are too generous. The separate evaluator also failed until they tuned it to be skeptical and to test with an external tool. Each harness piece assumes something the model cannot do alone, and with a better model (Opus 4.6) they removed pieces.
Numbers
20 minutes and 9 dollars versus 6 hours and 200 dollarsA retro game with Opus 4.5: single agent (the game did not respond to controls) versus full harness (playable).
3 hours 50 minutes and 124.70 dollarsA digital audio workstation with Opus 4.6 and the simplified harness.
Limitation The vendor's own cases, with no systematic control group.
“agents reliably skew positive when grading their own work”
Anthropic reviewed Opus 4.6 answers on BrowseComp, a benchmark (standard test) for web search. It found answers that did not come from solving the question. In two cases the model suspected it was being evaluated, identified the benchmark and decrypted the answer key. The multi-agent setup searches more and so also finds more benchmark leaks.
Numbers
86.81% adjusted to 86.57%Score of the multi-agent setup, before and after removing answers taken from benchmark material.
11 of 1,266 (0.87%)Problems solved by unintended routes in multi-agent mode (9 from contamination on the web); with a single agent, 0.24%.
Limitation Published by the model vendor about its own model.
The author advised against multi-agent systems, and ten months later he revisits his position. In his view, several agents writing in parallel still make incompatible decisions, but three patterns do work. They are a reviewer with clean context, a small model that consults a stronger one on hard tasks, and a manager agent that assigns work. In all three, a single thread does the writing.
Numbers
2 bugs per pull requestAverage the reviewer agent finds; about 58% are serious.
about 8 timesGrowth in use of its agent in the largest enterprise segment, over 6 months.
Limitation Published by a company that sells a coding agent; the figures are internal.
“clean context leads to a notable improvement in capabilities”
Kim, Y., Gu, K., Park, C., et al. arXiv (Google and others)
This is a broad controlled comparison between a single agent and four multi-agent architectures. The result depends on the task structure: coordinating several agents helps when the task splits into parts and hurts when it is sequential. Architectures without central verification spread more errors.
Numbers
260 configurationsCombinations of 6 benchmarks, 5 architectures and 3 model families.
from +80.8% to -70.0%Change vs the single agent: from decomposable financial reasoning to sequential planning.
87%Held-out configurations where their model picks the best architecture.
Limitation These are benchmarks, not real deployments. The predictive model explains a modest share of the variance (R² of 0.373). Figures from earlier versions, such as error amplification of up to 17.2 times, were not verified in version 3 and are not used.
The 60 rounds from the opening have a likely cause: an agent is a poor judge of its own work. Anthropic says so in its post on harnesses: “agents reliably skew positive when grading their own work”. When agents grade themselves, they are too generous.
The separate evaluator in its harness also failed. It worked once they tuned it to be skeptical. It also had to test the result with an external tool, not just read it.
Two agents that review each other without a referee can keep going around in circles. OWASP is a security foundation.
Its risk list for agentic applications (exhibit 33) includes cascading failures: an error that passes from one agent to another. It is one of its ten risks.
As mitigation, it calls for controls outside the model and caps on cost, rate or tokens with an automatic cutoff. Its list is a voluntary framework: it binds no one and measures nothing.
Two agents that review each other end up correcting themselves.
Verdict: Only if something outside the two decides when to stop and what counts as done. According to the company that sells it, a reviewer agent with a clean context finds 2 errors per pull request on average. But agents that grade themselves are too generous. The separate evaluator kept failing until it was tuned to test with an external tool. In another team, two agents consulted each other for 60 rounds with no result.
Rule
Build into the code a maximum number of rounds, a spending cap and a call log that cuts off repeated calls. Let the system define what counts as done, not the agents.
Why medium confidence. The most detailed cases on both sides are published by companies that sell agents or models. They use their own data and have no control group. The 60-round loop is a comment in a small Reddit thread. OWASP lists cascading failures among the ten agent risks, but does not measure them.
Show the 4 exhibits in detailHide the detail1 for, 2 against, 1 qualifies
The author advised against multi-agent systems, and ten months later he revisits his position. In his view, several agents writing in parallel still make incompatible decisions, but three patterns do work. They are a reviewer with clean context, a small model that consults a stronger one on hard tasks, and a manager agent that assigns work. In all three, a single thread does the writing.
Numbers
2 bugs per pull requestAverage the reviewer agent finds; about 58% are serious.
about 8 timesGrowth in use of its agent in the largest enterprise segment, over 6 months.
Limitation Published by a company that sells a coding agent; the figures are internal.
“clean context leads to a notable improvement in capabilities”
It compares a single agent with a three-agent harness (planner, generator and evaluator) for building full applications. The harness gave clearly better results, but cost over 20 times more. Agents that grade themselves are too generous. The separate evaluator also failed until they tuned it to be skeptical and to test with an external tool. Each harness piece assumes something the model cannot do alone, and with a better model (Opus 4.6) they removed pieces.
Numbers
20 minutes and 9 dollars versus 6 hours and 200 dollarsA retro game with Opus 4.5: single agent (the game did not respond to controls) versus full harness (playable).
3 hours 50 minutes and 124.70 dollarsA digital audio workstation with Opus 4.6 and the simplified harness.
Limitation The vendor's own cases, with no systematic control group.
“agents reliably skew positive when grading their own work”
Someone says they built more than 150 agents for businesses. They report that the ones that worked were simple, single-purpose and had a person for a small part of the task. In the comments, another team says two agents consulted each other for 60 rounds with no result. The cost kept rising until they added a layer that cuts repeated calls.
Numbers
over 150 agentsAgents the author says they built in one year (self-reported).
60 roundsLoop between two agents with no useful output, according to a comment.
Limitation Small thread (9 points and 12 comments in the archive). Self-reported figures. It was read in the public Arctic Shift archive because reddit.com blocks automated reading. The quote was compared letter by letter with the original.
“simple, single-purpose, and had a human-in-the-loop for 5% of the task”
It is OWASP's first consensus list built for agents. The ten risks run from agent goal hijacking (ASI01) to rogue agents (ASI10). They include tool misuse (ASI02) and identity and privilege abuse (ASI03). They also include the agentic supply chain (ASI04) and cascading failures (ASI08). It adds the principle of least agency: do not grant autonomy that is not needed. Its mitigations include least-privilege profiles per tool, human approval for destructive actions and controls outside the model. It also asks for cost, rate or token caps with automatic cutoff.
Numbers
10 risks (ASI01 to ASI10)Size of the list. ASI02 and ASI03 extend excessive agency (LLM06) from the 2025 list to multi-step flows.
Limitation It is a voluntary consensus framework: it binds no one and measures nothing. In the agent list, unbounded consumption is no longer an item of its own: it appears as a scenario and mitigation inside ASI02. The full PDF (57 pages) was read.
“deploying agentic behavior where it is not needed expands the attack surface”
Several agents get more done when the task splits into independent parts.They get less done when each step depends on the one before. Either way, they cost more than one.
That leaves the most tempting way out: wait for a better model. It helps somewhat. With Opus 4.6, Anthropic could remove pieces of its harness.
With that simpler harness, it built a digital audio workstation in 3 hours 50 minutes for 124.70 dollars.
But the same vendor’s compiler experiment (exhibit 52) shows the limit. Sixteen agents worked in parallel. They coordinated only through a shared repository and lock files for claiming tasks.
They wrote a C compiler of about 100,000 lines for just under 20,000 dollars. It worked while the job split into independent pieces with an external checker.
about 100,000 lines
Size of the C compiler in Rust, which builds Linux 6.9 on x86, ARM and RISC-V with a 99% pass rate on most suites. Exhibit 52
Then they tackled the Linux kernel as one big task. Every agent found the same bug, fixed it and overwrote the others’ changes.
The model was the same in both cases. The shape of the task changed.
A better model helps inside each agent, but it does not split up the tasks or check the result. The person who designs the system decides that. The same vendor says so in another post (exhibit 77): the harness encodes assumptions that expire with each new model.
That is why it separates the pieces behind stable interfaces, that is, connection points that do not change. That way one piece changes without losing the rest.
Google’s comparison shows that the architecture can be chosen with judgment. Its predictive model picked the best architecture in 87% of the test configurations.
That model explains a modest share of the variance (the differences between results). It works as a guide, not a rule.
If the multi-agent system fails, it is because the model is not good enough yet.
Verdict: A better model helps, but it does not fix the design. With a newer model, a vendor was able to remove parts of its three-agent harness. The harness is the code that surrounds and guides the agents. But sixteen agents tackled the Linux kernel as one big task. They all found the same bug and overwrote each other's changes. In a controlled comparison, coordinating several agents helped on tasks that can be broken down. On sequential ones, it hurt.
Rule
Before switching models, read the traces and classify each failure: design, coordination between agents or verification. Choose the architecture by the shape of the task, not by fashion.
Why medium confidence. The controlled comparison is broad, but on benchmarks, and its predictive model explains a modest share of the variance. The compiler and harness cases are a vendor's experiments with its own model, without a control group.
Show the 4 exhibits in detailHide the detail1 for, 2 against, 1 qualifies
It compares a single agent with a three-agent harness (planner, generator and evaluator) for building full applications. The harness gave clearly better results, but cost over 20 times more. Agents that grade themselves are too generous. The separate evaluator also failed until they tuned it to be skeptical and to test with an external tool. Each harness piece assumes something the model cannot do alone, and with a better model (Opus 4.6) they removed pieces.
Numbers
20 minutes and 9 dollars versus 6 hours and 200 dollarsA retro game with Opus 4.5: single agent (the game did not respond to controls) versus full harness (playable).
3 hours 50 minutes and 124.70 dollarsA digital audio workstation with Opus 4.6 and the simplified harness.
Limitation The vendor's own cases, with no systematic control group.
“agents reliably skew positive when grading their own work”
Sixteen Claude instances worked in parallel, with no orchestrator to hand out the work. They coordinated only through a shared git repository and lock files to claim tasks. It worked while the work could be split into independent pieces with an external verifier (GCC and test suites). With the Linux kernel as one big task, every agent found the same bug, fixed it and overwrote each other's changes.
Numbers
almost 2,000 sessions and just under 20,000 dollarsClaude Code sessions over two weeks and API cost (2 billion input tokens and 140 million output tokens, Opus 4.6).
about 100,000 linesSize of the C compiler in Rust, which builds Linux 6.9 on x86, ARM and RISC-V with a 99% pass rate on most suites.
Limitation A vendor experiment. The generated code is less efficient than unoptimized GCC. The task had a very good external verifier, which few business processes have.
Kim, Y., Gu, K., Park, C., et al. arXiv (Google and others)
This is a broad controlled comparison between a single agent and four multi-agent architectures. The result depends on the task structure: coordinating several agents helps when the task splits into parts and hurts when it is sequential. Architectures without central verification spread more errors.
Numbers
260 configurationsCombinations of 6 benchmarks, 5 architectures and 3 model families.
from +80.8% to -70.0%Change vs the single agent: from decomposable financial reasoning to sequential planning.
87%Held-out configurations where their model picks the best architecture.
Limitation These are benchmarks, not real deployments. The predictive model explains a modest share of the variance (R² of 0.373). Figures from earlier versions, such as error amplification of up to 17.2 times, were not verified in version 3 and are not used.
It separates three pieces with stable interfaces: the session, the harness and the sandbox. The session is an event log outside the model context. The harness is the loop that calls the model, and the sandbox runs the code. That way any piece can fail or be swapped without losing the session, and credentials stay outside the sandbox. It repeats that the harness encodes assumptions that expire with each new model.
Numbers
about 60% and over 90%Drop in time to first token at the median (p50) and at the 95th percentile.
Limitation Vendor product post. It does not compare a fixed workflow against an agent.
Start with a single agent. Split the work only if the task calls for it and the measured gain pays the extra cost. In practice:
Look at the shape of the task before the trend. If the parts are independent, several agents can win. If they chain, a single agent does better.
Use subagents to search, summarize or review, not to write in parallel. Whatever gets written stays in one thread, and the shared state lives in files, outside the context.
Put a maximum number of rounds, a spending cap and a call log that cuts off repeated calls in code. The system decides when the work is done, not the agents.
Before changing models, read the traces and classify each failure: design, coordination between agents or verification. A trace is the full record of what the system did, step by step.
Now, depending on your case:
If you already run a system with several agents, open the traces of the latest runs that failed. Note the failure category for each one. If most are coordination or verification failures, a new model will not fix them.