Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams · Sahan Paliskara and Nattaput Namchittai, Anthropic Fellows Program; Jacqueline Tay, independent; Avery Griffin and Andrew Lampinen, Anthropic · Anthropic Alignment Science Blog, November 11, 2026
One agent per user did worse than one shared agent in every environment an Anthropic Fellows study tested
Machine-readable
Download Markdown
The authors built four environments in which simulated users each hand a task to an agent and the agents draw on one resource that cannot satisfy everyone: an API-token budget, a clinic calendar, a group order or booking, and a merge queue with a release cutoff. They compared a coordinator, one agent serving every user, with teams of one agent per user, with and without a channel between the agents. They ran models from Anthropic, OpenAI and Alibaba. The coordinator beat the team that could communicate in all four environments for both Claude models, by about 10 to 45 percentage points.
The merge queue is the case closest to a shared repository. In the paper, four users each want a buggy pull request fixed and merged before a freeze, and their agents share one or two CI runners that cannot clear every PR in time. Averaged over three scenarios, teams merged 81% (Claude Opus 5) and 78% (Claude Sonnet 5) of the value of the best feasible release plan, against 92% and 93% for the coordinator. Teams rarely ordered work by value: their merge order matched the value order for 19% to 49% of merged PR pairs, against 97% to 100% for the coordinator.
The fixes differed by environment. On the hardest merge-queue scenario, adding a team lead with no written guidance lowered the result, from 65% and 55% of the best plan to 38% and 44%. Telling the lead and every agent the release manager's priority order, with the lead cutting the last PR in its first post, raised it to 95% and 96%. The paper adds that a lead was not required: Opus 5 agents that were told the order did about as well without one. In the group-order environment, the agent that placed the order had been sent one user's special request in 94% to 99% of episodes, but had it in context when it committed in only 47% to 67%. A platform guard that blocked checkout until the agent had read its pending messages recovered 73% (Opus 5) and 62% (Sonnet 5) of failed episodes.
In the shared-budget environment the post says team agents "act too little and too late". From four agents to 16, the share of agents that took any action fell from 66% to 10% for Sonnet 5 and from 82% to 25% for GPT-5.6-sol. GPT and Qwen agents cancelled or stopped other users' jobs without asking 3.9 to 7.1 times per episode, against 0.59 for Sonnet 5 and never for Opus 5.
Users are simulated. The merge-queue result rests on three scenarios, and its strongest mitigation ran five episodes per scenario. Consent and fabrication were labelled by Claude models acting as judges, which the authors did not validate against human judgments. The work comes from an Anthropic program and compares Anthropic's models with competitors'. Three environments are released as MAMUBench, 74 scenarios under an MIT license with a script that compares a run with the paper's numbers; the merge queue is in the repository but outside the 74. We did not run it. The paper puts one pass of the 74 scenarios with an Opus 5 team at about 3.4 billion tokens. We read the post in full and the merge-queue sections of the 63-page paper.
Why it matters: A team where every engineer points an agent at the same merge queue or CI budget is the setup this study tested, and the authors note the same problem can arise when one person runs several agent sessions in one codebase. In the merge-queue runs, what closed the gap was shared information, a stated priority order and a cut line, and a lead agent without it made things worse. In the group-order runs, a check enforced by the platform recovered more failures than rerunning did.