As AI agents become more capable and widely used, they are increasingly required to interact with each other. Users give their agents tasks which require them to share resources with other people’s agents; for instance, a compute budget, or a codebase, or the money for a group food order. These settings are understudied, so we built four environments with simulated users and everyday tasks and tested frontier models from Anthropic, OpenAI and Alibaba in them. In all four environments, group outcomes were worse when each user delegated to their own agent rather than when one agent served everyone. In these simulated settings, we also saw problematic behaviors that varied considerably by model and environment, including stalling as teams grow, overriding other users’ requests, and making unsupported claims about other people. Fixes depended on the environment: having a designated team leader and clearly stated priorities improved performance when agents shared a budget, while blocking agents from placing an order until they had read their messages rescued more failed group orders than simply rerunning them.
We are releasing three of the environments as a benchmark, MAMUBench, so that others can use them to test how well agents coordinate, and how they behave, in multi-user, multi-agent systems.
Research done as part of the Anthropic Fellows Program.
Introduction
As AI agents become more common, users increasingly deploy them to pursue goals that require interacting with other agents. If you're reading this, you've probably had Claude run an experiment, book something, or write code in a shared codebase and merge the changes on GitHub. SemiAnalysis projected that Claude Code would author 20% or more of daily commits by the end of 2026. Features like Claude Tag and cross-session messaging point toward a world in which people delegate more tasks to agents—and those agents increasingly run into one another. Recent releases also let several users share resources through their agents: with the DoorDash CLI, several people's agents can add to one group cart; Slack Code brings agents such as Claude, Devin and GitHub Copilot into channels the whole team works in; and OpenAI's dots give each person an agent that works on their behalf, in a space shared with teammates (DevDay 2026 recap). In each of these cases, every agent acts on behalf of its own user, and it is unclear how the agents should act for the group as a whole.
Recent work has found that multi-agent systems can suffer from coordination failures and other issues, largely in settings where agents pursue a shared objective. This raises the question of what happens when agents instead represent different users with different goals and preferences. We study these increasingly common settings, which we call multi-user, multi-agent systems. In our environments, each user has their own goal, and all of the users draw on one shared resource. We evaluate a range of frontier models from Anthropic, OpenAI, and Alibaba on these environments. We score the agents the way we would score a group of people negotiating over that resource: by the outcome for the group as a whole.
Setup
We developed four environments for this multi-user, multi-agent setting: an API-token budget shared by researchers, a clinic calendar shared by urgent patients, a group food order or travel booking that users arrange through personal assistants, and a merge queue with a release cutoff. These are realistic settings, designed so that a frontier model acting as a single coordinator usually performs well; comparing formations therefore isolates coordination rather than task capability. We compare four formations: solo (one user, one agent); a coordinator, a single agent that serves several users; a silent team, one agent per user with no way to communicate; and a peer-to-peer team, one agent per user with a channel between the agents. We use the coordinator as our control. In this post, we focus on the API key and personal assistant environments and on the coordinator and the peer-to-peer team (Figure 1); we encourage you to read the paper for the rest. Averaged over each environment's scenarios, the coordinator beats the peer-to-peer team in all four environments for both Claude models, by about 10 to 45 percentage points (Figure 2).
Behaviors
API Key
In the API key environment, groups of four, eight, or 16 researchers share a limited API-token budget. Notably, this budget is not enough to cover everybody's work. Each researcher gives their agent a queue of jobs, along with context on each job's deadline and the consequences of missing it, such as an upcoming paper deadline or a launch review after the weekend. Agents need to cancel and scale down jobs to make sure that some work gets finished. We built 25 scenarios that vary the users and their jobs. We find that peer-to-peer teams reach 47% and 38% of the coordinator's performance for Claude Opus 5 and Claude Sonnet 5, respectively (30% and 12% of the optimal outcome, against 64% and 32% for the coordinator).
The multi-agent team's main problem is that agents act too little and too late. This environment is dynamic, so agents need to sequence jobs actively. Simply allowing, say, a hero run to continue when it has little chance of finishing can consume the remaining time and cause jobs to miss the deadline. In fact, many agents never act at all, and more of them sit out as the team grows: from four to 16 agents, the share that ever act falls from 66% to 10% for Sonnet 5 and from 82% to 25% for GPT-5.6-sol. GPT and Qwen agents also cancel or stop other users' jobs without asking, 3.9 to 7.1 times per episode, against 0.59 for Sonnet 5 and never for Opus 5. These unconsented cuts do not lower the group's outcome, since canceling low-value jobs is what the environment requires, but they are still undesirable because they end another user's work without that user's agreement. Episodes in which agents canceled or shrank other users' jobs without asking usually got a higher group score than episodes in the same scenario where they didn't. But that reveals the limitations of the scoring system: it only looks at the total value of the jobs completed, not whether anyone had their work destroyed or whether they agreed to it. Lastly, the agents' implicit priorities differ from model to model. For example, Claude Opus 5 spreads outcomes across users more evenly than Claude Sonnet 5 and the GPT models (Figure 3).
Personal Assistant
In the personal assistant environment, groups of users delegate a shared planning task to their own assistants: a group food order, a prepaid reservation, or a travel booking, with a shared budget. In each scenario, one user makes a targeted request, which we call the ask: either a safety constraint or an altruistic request. Importantly, these requests require agents to deviate from default behavior in a reasonable way. For example, a user with celiac disease asks for two plain gluten-free sides instead of an entree. We measure success by whether the final order or booking honors the ask. Across the 25 scenarios, the coordinator honors the ask about twice as often as the peer-to-peer team.
Although the ask usually gets communicated within the group, the main problem is a race condition: the agent that commits the order often does so before it has read every message sent to it. Across all scenarios and models, the ask was sent to the agent that placed the final order or booking in 94–99% of episodes, but it was in that agent's context at the time of the commit in only 47–67% (Figure 4). Interestingly, even when the ask was in context, only 56–68% of episodes honored it, against 19–36% when it was not. Teams also tend to override each other's requests in the shared cart or booking: 65–77% of team episodes included at least one edit against the ask. We include results for GPT-5.6-sol and GPT-5.6-terra in the paper as well.
Lastly, agents sometimes made claims about other people that their information did not support. Just over half of Claude team episodes contained at least one of these fabrications (58% for Opus 5 and 53% for Sonnet 5, as judged by Claude Opus 5), while a single agent does this in 17–20% of episodes. This follows from how information is split. Each agent sees only its own user's notes but has to talk about everyone's order, so agents fill the gaps: they assume the table wants what their own user wants, attach one user's notes to another, or say a user agreed to something they never said.
Mitigations
We tested whether targeted changes, such as added instructions or a lead agent with decision authority, close these gaps (Figure 5). In the API key environment, a separate team lead agent, instructed to prioritize high-value jobs and use the budget fully, closes the gap between the coordinator and the peer-to-peer team. A team lead does not help in the personal assistant environment, however. There, our best mitigation is a platform guard that blocks checkout until the committing agent has read all of its pending messages; it recovers 73% (Opus 5) and 62% (Sonnet 5) of failed episodes. The fixes that work differ by environment, which suggests that multi-user, multi-agent failures have diverse causes. We cover mitigations in more depth in the paper.
Discussion and Implications for Safety
Multi-user, multi-agent systems are already emerging. For example, Instinct recently released its Trusted Person Network, in which each user's assistant can talk to other users' assistants to coordinate plans on their behalf. An analogous coordination problem can arise in single-user settings, when one person delegates different but intersecting tasks to multiple agents, such as running eight Claude sessions to build features in the same codebase. The core of the problem we study is that multiple agents may be pursuing different objectives while interacting through a shared environment or resource.
Our results, together with prior work, show that multi-user, multi-agent systems carry risks beyond worse group outcomes: an agent acting for one user can harm others who share the system. In our environments, agents from a range of providers (Anthropic, OpenAI, and Alibaba) acted on other users' jobs without consent, overrode a user's request, and made claims about other people that their information did not support. Outside the lab, swarms of agents have already caused real harm, as in the Hugging Face incident and the hijacking of a German wiki (Reuters, Euronews). These cases did not involve agents acting for different users, a setting that remains largely unexplored. While our results show that coordinators can outperform teams, and previous work finds alignment advantages for single-agent systems, relying on a coordinator is not always feasible or natural for systems with many users. Multi-user, multi-agent risks therefore cannot be addressed simply by centralizing coordination.
These results suggest concrete next steps. First, evaluations should measure agent behavior alongside group outcomes, since each misses something on its own. For example, an outcome score would not flag GPT and Qwen agents canceling other users' jobs without asking, and conversely a check of actions would not flag Claude Opus 5 teams, whose agents never did so but fell well short of the coordinator. Second, mitigations can come from across the stack, from platform guards that keep agents from stepping on each other's toes, much as a queue keeps a crowd from rushing a box office, to training agents to communicate and reach agreement. People have developed ways to negotiate subtly conflicting goals, and agents will need them too, both for effectiveness and for alignment. We hope that our work will help to inspire further efforts into understanding and preventing failures in multi-user, multi-agent teams.