A group trip looks simple until everyone sends an assistant to arrange it. One person wants to spend less, another has a strict arrival time, and a third offers to cover more of the bill. Each assistant may understand its own user perfectly. The shared booking still needs someone, or some process, to reconcile those requests before it becomes final.
That is the kind of problem explored in Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams. Anthropic published an explanation of the work on November 11, 2026. The paper itself was submitted to arXiv on September 30, so November 11 should not be treated as the research’s first appearance. The associated MAMUBench repository is now publicly readable.
The setting matters: different users, one shared resource
Many familiar multi-agent workflows divide one person’s task among several assistants. This study looks at a different arrangement. Each agent represents a separate user, and the users’ requests compete for something they cannot all have in full.
The researchers built four simulated environments: researchers sharing an API-token budget, patients sharing a clinic calendar, personal assistants arranging a group order or booking, and developers working through a merge queue before a release cutoff. Across the study, they evaluated five models from Anthropic, OpenAI and Alibaba, although model coverage differed by environment.
The main comparison was between one coordinator serving everyone and a team with one agent per user. The study also examined teams without a direct communication channel and, where appropriate, a single-user baseline.
For the two Claude models, the coordinator achieved better average group outcomes than the communicating team in all four environments. That is a finding about these particular tasks and configurations, not a rule that adding agents always makes a system worse.
Where cooperation broke down
The shared-budget experiments exposed a surprisingly ordinary failure: work was left waiting. Some agents acted too late or never acted, while jobs with little chance of finishing continued to consume limited resources. Increasing the team size did not reliably produce more useful activity.
The personal-assistant experiments revealed a different problem. A request could be sent to the agent responsible for placing an order without being read before checkout. In other words, the communication system could deliver the message while the decision still proceeded without it.
Agents also sometimes changed a shared order against another user’s request or made unsupported statements about what someone wanted. These are relevant failures even when the overall task appears to finish. A completed booking is not much of a success for the person whose constraint disappeared along the way.
There is a similar measurement problem in the budget task. Canceling someone else’s work can improve a group’s numerical score while violating that person’s expectations or consent. An evaluation that records only total output will miss that distinction.
The useful result is in the fixes
The researchers did not stop at comparing scores. They changed the organization and the rules around the agents.
In the shared-budget environment, assigning a team lead and giving clearer instructions about priorities improved results. In the personal-assistant environment, giving one agent the final say did little on its own. A more effective intervention was a platform check that prevented checkout while the acting agent still had unread messages.
When previously failed episodes were rerun with that check, it recovered 73.1% of failures for Claude Opus 5 and 62.3% for Claude Sonnet 5. Those percentages describe recovery within the failed cases selected for rerunning. They are not the success rate of all new group orders, nor a measured improvement in a live commercial service.
For developers, a reasonable lesson is to identify the decisions that need shared agreement and enforce the relevant checks there. A reminder to “coordinate carefully” leaves the timing to the model. A checkout condition makes the requirement part of the system. That is an engineering interpretation of the research, not a claim that one guard will solve every collaboration problem.
What is available to try
MAMUBench’s core benchmark contains 74 scenarios across three environments: API key, clinic and personal assistant. The paper covers four environments and 77 scenarios in total. The repository also includes runnable merge-queue code, but those scenarios are outside the core set of 74.
The repository uses an MIT license. Running an evaluation still requires the relevant model API keys and computing resources. The project supports a local backend as well as Modal; open-source access does not make model calls free. Its food-ordering integration is simulated and does not place real orders.
Limits worth keeping in view
These experiments use constructed scenarios and simulated users. They do not establish how every real team, model or agent framework will behave. The paper also notes that consent and fabrication labels were produced by model judges and were not validated against human judgments.
Central coordination is a useful baseline, but it may be impractical when users need separate assistants or cannot share all their information. MAMUBench offers a way to study those tensions. Its most valuable question is whether the system can preserve individual requests while producing a workable shared outcome.
DigIntoAI has not run the benchmark. This article is based on the research paper, Anthropic’s explanation and the public repository, checked on November 12, 2026.