Patterns and problems in emerging multi-agent systems

Models are improving and AI agents are taking on more tasks in shared codebases, markets, and other social systems. As a result, an increase in real-world interactions between agents is imminent. We've already begun studying this, but still have a lot of uncertainty regarding what this looks like at scale. The trajectory is easy to imagine and hard to slow: current institutions are designed by and for people, resting on assumptions about the sufficiency of oversight at human speed. Some institutions will become human-AI hybrids; others where agents outcompete on speed or cost will become agent-only. The volume of agent-agent interaction could plausibly exceed that of human-human and human-agent interactions before the world understands the conditions for making such interactions go well.

Agents are unlike people in many ways. They can work for longer, instantly grasp large bodies of information, and exhibit a breadth of knowledge surpassing any person. Yet they are also susceptible to confabulation and reward hacking, and despite progress in alignment, we know very little about how they behave in complex, real-world, multiagent environments. Moreover, benign behavioral quirks at the individual level might compound into unwanted global outcomes. Here, we identify a few examples of behavioral tendencies in current frontier models and show how they can produce unexpected systemic failures, in hopes of starting a conversation about mitigating these risks.

Measuring coordination

True multiagent systems are still in their infancy. For some time now, agents have excelled at tool use, and insofar as they are able to treat other agents as tool invocations—that is, with well-defined inputs (prompts) and outputs (responses and artifacts)—they can work together efficiently. Where agents currently stumble, however, is in treating each other as more like distinct, long-lived peers, with their own goals and behaviors, and no clear hierarchy between them. As autonomous agents become more and more prevalent in the world and operate in ever-more demanding settings, it is crucial that they learn how to effectively coordinate.

There are situations where we can make good use of simple multiagent swarms today. This is particularly true for problems that are highly parallelizable by default (i.e., problems that can be broken into many independent sub-problems) but where agents still have opportunities to specialize or learn from each other. One such problem is software vulnerability detection. The easiest way to use agents to find software vulnerabilities is to point individual agents at individual codebases (or individual files or modules within codebases), and ask them to find vulnerabilities in the code. This can then be run in parallel for many independent agents. This is an approach we use ourselves—in, for example, our work scanning open-source software as part of Project Glasswing.

But could multiagent cooperation make this process more effective? To find out, we tried a different approach: we initiated 45 different agents and gave each one its own virtual machine, a shared forum on which they could coordinate, and an identical prompt that asked them to find vulnerabilities in a set of 15 open-source software projects. We asked the agents to peer-review each other's findings, and initiated a separate arbiter agent to make final decisions on whether or not a vulnerability submitted by the agent team was both new and valid.

The graph below shows how this method (in the solid lines) compares against the standard parallel approach (stars) for two models: Claude Mythos Preview and Opus 4.8. The coordinating swarm of agents was allowed to run for a long time, and found new vulnerabilities at a roughly constant rate. The fully independent parallel agents, in contrast, were directed to find vulnerabilities in a limited set of locations. There is no clear ordering to the parallel agents’ findings, so we report only the total number of tokens spent for them.

Cumulative vulnerabilities found via a coordinating swarm of agents (solid lines) compared to vulnerabilities found via independent agents each pointed at different sections of code (stars). Dashed lines show the cumulative vulnerabilities found by the swarm that were also found by the independent agents. The dotted line (Mythos Preview only) shows only vulnerabilities in the core code of each project where the independent agents were told to look.

For Mythos Preview, the simple independent parallelized method produces 21 vulnerabilities over a 6.5 million token run, while the coordinating agent swarm found 266 vulnerabilities over a 27 million token run. However, roughly half of these vulnerabilities were found outside of the core directories in which the simple independent parallel agents (stars in the above plot) were told to focus. If we limit the swarm's outputs to only the vulnerabilities in the core directories, the two methods seem comparable in terms of tokens per vulnerability found.

The two methods are largely complementary: there were only 12 vulnerabilities in common between them. The coordinating swarm was able to focus its attention wherever it thought it could most easily mine vulnerabilities, whereas the independent agents were pre-assigned where to search. The agents in the swarm built themselves tools and learned to specialize in particular types of vulnerability discovery. In the future, we predict that this sort of specialization and coordination will dominate over uncoordinated brute-force search.

In the experiment above, agents in the agent swarm don’t directly rely on one-another’s work: if one misses a bug, it won’t directly undermine the work of another. But when agents do depend on one-another, coordination gets much more difficult. Larger software engineering projects are one place this matters: they typically develop rich—and dynamic—interdependencies as they evolve.

To test how well swarms of agents could coordinate on a project like this, we directed several swarms to each create a text-based, web-playable, open-world fantasy game. Each agent within each swarm was again given its own virtual machine, as well as access to a shared forum and self-hosted repository. We varied the model generation and the number of agents in each swarm, and let each swarm run for 12 hours. We also varied the prompt: the baseline prompt simply told agents to form teams and work with each other, but we also tried two others: a prompt with prescriptive roles (which told agents which types of teams to form—such as core programming, artistic direction, or play testers), and a “CEO hierarchy” prompt, which designated one agent as the CEO, and told all subsequent agents to take assignments from it. But these prompts did not make much difference. In all three versions the resulting games were (perhaps predictably) bad: they did not run at human speed, their interfaces were inscrutable, and they had precipitous learning curves. Models have poor taste in this arena and currently require significant human direction.

Left: Fraction of PRs that have been merged by the end of each simulation. Right: The median agent’s degree of code sharing in each simulation. Both metrics are averaged over the three different prompt types for varying simulation size. Only Sonnet 5 is able to maintain both a high merge fraction while directly collaborating and sharing code with other agents.

PR progress over the course of a 12 hour simulation for each of five different models. Sonnet 4.6 and Opus 4.6 do a terrible job of merging PRs compared to newer models that are able to merge most of the PRs that they open.

Though the end product was consistently poor, the different model generations we tested (Sonnet 4.6 and 5, Opus 4.6 and 4.8, and Mythos Preview) coordinated in strikingly different ways.

Here, we track two important metrics: the fraction of PRs (pull requests) that get merged into the master branch, and the median amount of code shared across agents' files. For a single agent and file, we define “code sharing” as the proportion of that file written by other agents. The average code sharing for an agent is defined as a weighted average across all files, weighted by the proportion of code on each file that that agent wrote itself. A code sharing score of zero indicates that the agent never touched any files that are shared with other agents, while a code sharing score close to one indicates that the agent mostly makes relatively small contributions to files that it does not own.

The earliest models we tested (Sonnet 4.6 and Opus 4.6) coordinated very poorly. Agents on these models worked together insofar as they committed code to the same sets of files, but a very low fraction of these PRs were merged, which suggests a lack of coordination—the PRs often conflicted with one-another, at which point they were then abandoned. More recent models (in particular, Opus 4.8 and Mythos Preview) have “solved” this problem, but only by hardly working together at all: the median agent maintained very high ownership of each of its files, reducing the potential for conflict. It was only our most recent model, Sonnet 5, that worked on shared resources (relatively high code sharing) while also maintaining a high PR throughput.

Failures from conformity

The lack of coordination shown by agents in the fantasy game challenge above—in which they siloed themselves and largely failed to merge their work—roughly mirrors some ways in which humans can fail to coordinate. Other failure modes of agentic coordination, however, look very different.

Individual agents are “low variance”: they often act the same in situations where different people might take a much more diverse range of actions. All that differentiates one agent from another is its context, its scaffolding, and the model that underlies it. When these factors are all the same (or similar), different agents will take very similar actions, even when the action space is very large. And, by implication, this means that when one agent makes a bad decision, it is likely that many agents will make that same bad decision. What would have been isolated problems can quickly become systemic failures.