Anthropic gave 45 AI agents separate virtual machines, one shared forum, and the same assignment: inspect 15 open-source projects for software vulnerabilities. The setup produced 266 findings judged novel and valid by an independent arbiter, but that number does not mean the system became 12 times more cost-efficient.
Anthropic published the experiment on August 13, 2026, in Patterns and problems in emerging multiagent systems. This article was checked against the research one day after publication, so the findings are current but still very new.
No project manager divided the codebase into 45 predefined slices. No human assigned one agent to search, another to reproduce, and a third to review. Every agent received the same task: find software vulnerabilities and peer-review the work posted by other agents.
Each agent controlled its own virtual machine. They could read one another’s leads, discuss evidence, and challenge claims through a shared forum. A separate arbiter agent then decided whether a submission was both novel and valid.
The headline number was 266. The more important result, however, was the structure that produced it: independent exploration, shared leads, peer review, and a single arbitration layer.
The agents did not suddenly acquire corporate awareness or elect a manager. The coordination system simply gave a group of similar agents enough shared memory and quality control to cover areas that isolated agents tended to miss.
How Anthropic’s 45-agent vulnerability experiment worked
Anthropic provisioned one virtual machine for each of the 45 agents. Every agent could inspect code, run tools, and test its own hypotheses without competing for the same terminal environment.
Their connection was deliberately simple: a shared forum.
That forum addressed two common failure modes in multi-agent systems.
The first was duplicated work. If all 45 instances operated in isolation, many of them could converge on the same obvious files and produce dozens of nearly identical results. The forum let an agent see which directions were already under investigation, then choose whether to validate a lead, take it further, or move to a different part of the codebase.
The second was an excess of unverified claims. Finding suspicious-looking code is not the same as demonstrating a vulnerability. A credible result needs evidence, reproduction, and a serious attempt to rule out false positives. Anthropic required the agents to review one another’s findings before the independent arbiter judged novelty and validity.
The workflow can be reduced to five stages:
Independent exploration
↓
Post the lead and supporting evidence to the shared forum
↓
Other agents review, challenge, reproduce, or extend the lead
↓
The arbiter agent deduplicates submissions and evaluates validity
↓
Confirmed findings enter the final result set
Independent exploration
↓
Post the lead and supporting evidence to the shared forum
↓
Other agents review, challenge, reproduce, or extend the lead
↓
The arbiter agent deduplicates submissions and evaluates validity
↓
Confirmed findings enter the final result set
The forum was not there to make the agents appear social. It served as the team’s external memory. The arbiter was not an extra model added for scale; it guarded the output boundary.
Without shared memory, agents repeat the same searches. Without arbitration, a system can turn similar claims and false positives into the appearance of progress.
21 versus 266 findings: why the multiplier is misleading
Anthropic compared the coordinated swarm with a conventional independent-parallel setup.
With Claude Mythos Preview, the independent setup used about 6.5 million tokens and produced 21 vulnerability findings. The coordinated swarm used about 27 million tokens and produced 266 findings that the arbitration system judged novel and valid.
A coordinated Opus 4.8 swarm produced 41 findings.
| Setup | Model | Token usage | Findings | Important condition |
|---|---|---|---|---|
| Independent parallel | Mythos Preview | About 6.5 million | 21 | Agents did not share their work process |
| Coordinated swarm | Mythos Preview | About 27 million | 266 | 45 agents, shared forum, peer review, and arbitration |
| Coordinated swarm | Opus 4.8 | No directly comparable budget was reported in the research summary | 41 | Do not convert this directly into a model-capability ratio |
Anthropic’s research chart. Solid lines represent coordinated swarms, stars represent independent-parallel runs, dashed lines show overlapping findings, and dotted lines count findings inside core directories only.
Dividing 266 by 21 gives roughly 12.7. That is a finding-count ratio, not a cost-efficiency result. The coordinated swarm consumed about 4.15 times as many tokens, ran longer, and allowed the agents to search more broadly.
The experiment therefore does not support the claim that multi-agent coordination improved unit-cost efficiency by 12.7 times. A fair efficiency comparison would require matched token budgets, time limits, search scope, and evaluation conditions.
Another result better explains the value of coordination: roughly half of the coordinated swarm’s findings came from outside the core directories. Isolated agents were more likely to focus on prominent locations emphasized by the prompt. The swarm had enough search capacity to inspect less obvious paths at the edges of the projects.
That broader coverage also explains why the coordinated run continued finding new issues after a longer period. It did not exhaust the most visible targets and then stall as quickly.
One more distinction matters. The 266 items should not be described as 266 critical vulnerabilities, 266 published CVEs, or 266 exploitable zero-days. They were vulnerability findings that the experiment’s arbitration process judged novel and valid. Public disclosure, human confirmation, severity classification, remediation, and maintainer review are separate steps.
What “the agents learned to specialize” really means
“Forty-five AIs formed their own security team” is a useful headline, but the mechanism was less anthropomorphic.
The agents did not elect a manager or create permanent departments. A more precise interpretation is that a shared environment made temporary specialization useful.
When one agent saw that a directory had already been inspected, it could spend compute elsewhere. When a new lead appeared on the forum, another agent could attempt to reproduce it. Once a finding had enough evidence, additional agents no longer needed to repeat the same proof. When two submissions described the same issue, the arbiter could deduplicate them.
Several functional positions emerged during the work:
- some agents expanded search coverage;
- some followed existing leads into greater depth;
- some checked whether a reported issue could be reproduced;
- some looked for counterexamples and challenged weak evidence;
- the arbiter controlled which findings entered the final output.
These positions did not have to be permanently assigned to specific agents to produce a division-of-labor effect.
The gain was therefore not “one model’s intelligence multiplied by 45.” It came from four concrete sources: independent contexts increased coverage, parallel execution increased the search budget, shared information let agents hand leads to one another, and arbitration imposed a quality threshold.
Multi-agent systems amplify weaknesses as well as capabilities
Anthropic called the broader study Patterns and problems in emerging multiagent systems. Successful collaboration was only one part of the work; coordination failure, collusion, and sabotage were also within scope.
That is the more important lesson for enterprise deployments.
When a single agent makes a mistake, the damage may remain inside one response. When the same mistake enters shared memory, other agents can build on it. The result may be a long chain of apparently independent evidence whose original assumption was wrong.
Other risks include:
- several agents inspecting the same direction, consuming tokens without increasing coverage;
- agents reinforcing one another’s weak evidence and making false positives easier to approve;
- a low-quality submission forcing several other agents to spend budget on review;
- so much collaboration traffic that agents spend more time reading the forum than doing the work;
- poorly designed objectives or scoring rules encouraging unwanted coordinated behavior;
- weak traceability when a final result is wrong and the team needs to identify which lead or review introduced the error.
As the number of agents grows, structured logs, explicit permissions, budget ceilings, and stopping conditions become more important. Adding model calls without those controls can produce an expensive discussion board rather than a reliable system.
Anthropic also tested groups of agents building games. That task depended more heavily on shared code and continuous merges, so it exposed a different coordination cost. As the number of agents increased from 10 to 80, merge rates fell for some models. Newer models often avoided conflicts by sharing less code.
This was a separate experiment from the vulnerability search. It reinforces the same boundary: parallel coverage can work well while tightly coupled collaboration still degrades.
This chart comes from Anthropic’s game-development experiment, not the 266-finding security run. It illustrates coordination costs as agent count grows and should not be combined with the vulnerability numbers as one benchmark.
A five-role enterprise multi-agent workflow
Most teams do not need to start with 45 agents. A smaller design with five explicit responsibilities makes it easier to test the result pipeline before scaling execution.
1. Coordinator agent
The coordinator receives the overall objective, divides it into areas that can be handled in parallel, and sets time, token, and tool-permission limits.
It should not mechanically split “write code,” “write tests,” and “review” among three agents when all three tasks require the same large context. A better partition uses relatively independent modules, data sources, customer cases, or code regions so that each agent can complete a coherent piece of work in its own context.
2. Explorer agent
Explorer agents expand coverage. Each instance needs a defined search scope and must attach sources, evidence, and unresolved questions to every submission.
3. Verifier agent
The verifier does not rewrite an answer to make it sound more credible. It reruns the important steps, checks whether the evidence can be reproduced, and records the conditions under which verification fails.
4. Challenger agent
The challenger actively looks for counterexamples. It asks when the claim would fail, whether the finding is a duplicate, and whether a simpler explanation fits the evidence.
5. Arbiter agent
The arbiter receives structured submissions only. It deduplicates, scores, and decides which items are eligible for final output. High-risk work should still require human approval; another model is not a substitute for an accountable owner.
Every agent can submit the same structured record:
finding_id: unique identifier
scope: area inspected
claim: finding or conclusion
evidence:
- source, log, or reproduction result
confidence: 0-1
duplicate_of: null
open_questions:
- unresolved question
risk_level: low | medium | high
recommended_action: proposed next step
finding_id: unique identifier
scope: area inspected
claim: finding or conclusion
evidence:
- source, log, or reproduction result
confidence: 0-1
duplicate_of: null
open_questions:
- unresolved question
risk_level: low | medium | high
recommended_action: proposed next step
This pattern also works outside security.
For content research, explorer agents can inspect primary sources, media coverage, community discussions, and critical viewpoints. A verifier checks the numbers, and an arbiter decides which facts are strong enough to enter the article.
For support troubleshooting, exploration can be split by customer environment, a verifier can reproduce proposed fixes, and an arbiter can assemble the final response. For code review, agents can inspect relatively independent modules while the workflow preserves a shared test and merge gate.
When to use multiple AI agents—and when not to
Anthropic’s practical guide includes a useful warning: some teams spent months building a complex multi-agent architecture, then discovered that a better prompt for one agent produced similar results.
Multi-agent systems are usually a better fit when:
- the search space is large and can be partitioned into relatively independent regions;
- several leads can advance in parallel with limited dependencies;
- subtasks require different tools or specialist viewpoints;
- the result is valuable enough to justify additional inference cost;
- a clear verification standard lets an arbiter evaluate whether a result is valid.
A single agent is usually simpler when:
- the task is highly sequential and later steps cannot begin until earlier steps finish;
- every worker needs the same large body of context;
- the task is low-value but would require extensive coordination messages;
- there is no verifiable result standard, leaving agents to vote on one another’s answers;
- the team has not yet solved logging, permissions, and failure handling for a single agent.
Anthropic’s implementation guidance says that multi-agent systems typically use 3 to 10 times as many tokens as comparable single-agent workflows. That cost may still be justified, but it should buy a measurable gain in coverage, speed, specialization, or verification quality.
Why the model access layer becomes infrastructure
Request management is straightforward when one agent makes one model call. With multiple agents running at once, request volume, concurrency, and token consumption grow quickly.
A production team needs to answer questions such as:
- Which role called which model?
- How many requests contributed to one final conclusion?
- Which agents are repeating work and consuming tokens?
- Do exploration and arbitration need the same model tier?
- What happens when a model becomes unavailable?
- Who approves high-risk tool calls?
One practical design is to assign broad exploration to a lower-cost model and reserve a stronger model for evidence review and final arbitration. All roles can call through one access layer while logs preserve task_id, agent_role, model, token_usage, latency, and result_status.
Apito.ai can serve as that model access layer by centralizing API keys, request endpoints, model calls, and usage records. It does not design agent responsibilities, replace sandboxing, control business permissions, or provide human approval. Its role is to make model access and usage management easier once calls become part of an engineered workflow.
What teams should take from the 45-agent experiment
The experiment did not prove that a group of AI agents can autonomously run a company. It demonstrated something narrower and more useful: when a task supports parallel search, and the system provides shared memory, peer review, and central arbitration, a group of agents can keep expanding coverage.
The same research also shows that collaboration creates system-level failure modes. Duplication, false positives, error propagation, collusion, and poor traceability cannot be fixed by adding one more agent.
If your team wants to test a multi-agent workflow, start with explicit roles and one structured submission format. Let explorers search, verifiers reproduce, challengers look for failure cases, arbiters guard the output, and accountable humans keep final approval.
Running 45 models at once is mainly a compute and budget question. Producing results that are verifiable, traceable, and attributable is the threshold that determines whether a multi-agent system is ready for business use.
FAQ
Were Anthropic’s 45 agents different models?
No. The experiment focused on multiple agents working toward the same objective in isolated environments while coordinating through a shared forum. Anthropic published separate coordinated results for Mythos Preview and Opus 4.8. Forty-five agents should not be read as 45 different model families.
Were all 266 findings critical or zero-day vulnerabilities?
No. The 266 figure refers to findings that the experiment’s arbitration process judged novel and valid. It does not mean 266 critical vulnerabilities, 266 CVEs, or 266 externally confirmed zero-days.
Was the coordinated swarm 12.7 times more efficient?
That conclusion is not supported. The coordinated swarm produced about 12.7 times as many findings, but it used about 4.15 times as many tokens and differed in runtime and search scope. Unit-cost efficiency would require a controlled, matched-budget comparison.
Are multiple agents always better than one agent?
No. Coordination can cost more than it returns when tasks are highly sequential, share heavy context, have low value, or lack objective verification criteria. Anthropic recommends identifying the limits of a single-agent design before adding a multi-agent architecture.
What is the first step for an enterprise multi-agent system?
Define how results will be verified before designing the roles. A minimum design can use explorer, verifier, and arbiter responsibilities, while recording a task ID, evidence, confidence, token usage, and human-approval status for each submission.
What does Apito.ai do in a multi-agent workflow?
Apito.ai provides a unified model API layer and usage records so different agents can call models through a consistent engineering interface. Task decomposition, permission controls, sandboxing, arbitration, and human approval remain responsibilities of the application and its operators.
Scope and terminology notes
- The experiment design and numbers in this article come from Anthropic’s public research page and were checked on August 14, 2026.
- “Formed a security team” and “learned to divide the work” are headline-level shorthand. The observed mechanism was an emerging pattern of specialization supported by shared information, peer review, and arbitration.
- Finding counts use the research paper’s terminology. They are not expanded into claims about critical severity, CVE assignment, or immediate exploitability.
- Anthropic, Claude, Mythos, Opus, and related marks belong to their respective owners. Apito.ai is an independent third-party technical service and is not authorized, operated, or endorsed by Anthropic.
