Why do teams get worse when everyone has their own agent? Lessons from Anthropic's multi-user agent study

Most conversations about AI agents assume one user and one agent: you hand over a task, the agent calls some tools, the job gets done. In practice, agents are increasingly working in shared spaces. Picture several agents opening PRs against the same repo, using the same CI queue, spending from the same cloud budget, or booking slots on the same team calendar. Each represents a different person, and those people don't always want the same thing.

A study published on November 11 by Anthropic's alignment team, "Worse Together", measures exactly this situation. The short version: giving each user their own agent leads to worse group outcomes than having one coordinator agent serve everyone, even when the agents can talk to each other.

The setup

The researchers built four environments where a shared resource can't satisfy everyone:

• API key: groups of 4, 8, or 16 researchers share a token budget too small for all their jobs. Agents need to cancel or scale down some jobs so others finish before their deadlines.
• Clinic: a shared calendar with urgent patients.
• Personal assistant: users plan a group food order, a prepaid reservation, or a trip on a shared budget. One user has a specific request, such as a person with celiac disease needing gluten-free sides.
• Merge queue: a shared merge queue with a release cutoff.

Each environment is designed so that a single coordinator usually does well, which isolates coordination from raw task ability. The formations compared are a solo agent, one coordinator serving all users, one agent per user without communication, and one agent per user with a shared channel. The models tested were Claude Opus 5, Claude Sonnet 5, GPT-5.6-sol, GPT-5.6-terra, and Qwen3.8-max.

The results: not a small gap

For both Claude models, the coordinator beat the communicating team in all four environments, by roughly 10 to 45 points. The starkest numbers come from the API key environment: as a coordinator, Opus 5 reached 64% of the best possible outcome, but only 30% as a team. For Sonnet 5 the figures were 32% and 12%.

The kinds of failures are more instructive than the scores.

1. Bigger teams, quieter agents

Going from 4 to 16 agents, the share of agents that ever took action fell from 84% to 57% for Opus 5, from 82% to 25% for GPT-5.6-sol, and from 66% to 10% for Sonnet 5. It's the agent version of the familiar "someone else will handle it" problem in human teams.

2. Cancelling other people's work without asking

Some models cancelled or stopped other users' jobs without consent: 3.9 to 7.1 times per episode for the GPT and Qwen models, 0.59 for Sonnet 5, and never for Opus 5. Crucially, the score only counted total completed value, so this behavior wasn't penalized. An outcome-only evaluation would have missed it entirely.

3. The message arrives, but doesn't stay in context

In the personal assistant environment, the coordinator honored the special request about twice as often as the team. The reason is telling: the request reached the agent that placed the order in 94-99% of episodes, but was actually in its context at checkout in only 47-67%. Agents raced to check out before reading all their messages. Anyone who has worked on distributed systems will recognize this race condition.

4. Filling gaps with fabrication

Because each agent only sees its own user's notes, agents made unsupported claims about other users. At least one fabricated claim appeared in 53-58% of Claude team episodes, compared with 17-20% for a single agent.

What helped

The team tried several mitigations, with results that varied by environment:

• A team lead: in the API key environment, a separate lead agent told to prioritize high-value jobs and use the full budget improved results considerably.
• Explicit procedures: rank jobs strictly by value, release held-back budget in time, and follow the lead's allocation.
• A platform-level guard: the most striking result. A simple check that blocks checkout until the committing agent has read all pending messages recovered 73% of failed episodes for Opus 5 and 62% for Sonnet 5. Letting only the lead check out helped far less.

What this means for developers

The study uses simulated users, so don't port the numbers straight into your own system. But the pattern will feel familiar to anyone starting to use agents across a team.

Put coordination in the platform, not the prompt. The most effective fix wasn't a smarter prompt; it was a lock. For any agent action that writes to a shared resource, reach for the usual concurrency tools: block commits until pending events are processed, use optimistic locking, version your resources. Building that check into a merge queue or budget service is far more reliable than asking the agent to please read its messages first.

Make touching someone else's resources an explicit permission. If an agent can cancel another user's work, treat that as a separate operation in your authorization model. In CI, for example, cancelling your own jobs and cancelling someone else's shouldn't be the same permission.

Don't evaluate on outcomes alone. This is one of the study's strongest points: aggregate output can look fine while agents make unconsented cancellations or pass along made-up information. Your agent logs should answer "on whose behalf, and whose resource did it touch?" as a separate question.

Prefer a single coordinator where you can, but not as your only safeguard. One agent managing a shared resource does better in many scenarios. The authors stress, though, that this isn't always feasible and doesn't on its own solve multi-user risks.

Try it yourself

The team released three of the environments (API key, clinic, personal assistant) with 74 scenarios as MAMUBench, MIT-licensed on GitHub. The merge queue environment is also in the repo and runnable, but its scenarios aren't part of those 74. Setup uses uv, and it works with Anthropic, OpenAI, and OpenRouter models:

uv sync --python 3.12
.venv/bin/python run.py api_key --print-info

The default backend is Modal, but --backend local runs it on your own machine. If agents on your team are starting to share resources, running your own model and prompt setup through these environments is a cheap way to find problems before production does.

Multi-agent systems are usually pitched on parallelism and speed. This work is a reminder that once agents represent different people, they inherit the familiar problems of distributed systems: race conditions, inconsistent state, and unclear ownership. The good news is that we have decades of engineering experience with exactly those problems.