Giving every PM their own AI agent did worse than one shared agent in Anthropic's tests. A GC should assign one agent per shared log
Anthropic researchers found that when each user had a personal AI agent working on a shared budget, calendar or order, the group got a worse result than when one agent served everyone. For a GC project team, that argues for one agent per shared record, not one per person.
When each person on a team gets their own AI agent and those agents work on something shared, the group ends up worse off than if one agent served everyone. That is the finding of new Anthropic research, and it bears directly on how a GC sets up agents around a submittal log, a delivery calendar or a look-ahead schedule: assign one agent to the shared record, not one to each PM.
What did the research find?
The post, "Worse Together," dated November 11, comes from Anthropic Fellows and Anthropic staff, with a paper on arXiv. They tested models from Anthropic, OpenAI and Alibaba in four simulated settings where several users share something limited: a compute budget, a clinic calendar, a group order or booking, and a code merge queue ahead of a release cutoff.
They compared a coordinator (one agent serving all users) against a peer-to-peer team (one agent per user, able to message each other). Scores are the percent of the best possible group outcome.
| Shared resource | Claude Opus 5: one agent vs. one per user | Claude Sonnet 5: one agent vs. one per user |
|---|---|---|
| Compute budget | 64 vs. 30 | 32 vs. 12 |
| Clinic calendar | 84 vs. 71 | 74 vs. 65 |
| Group order or booking | 88 vs. 44 | 75 vs. 37 |
| Merge queue | 92 vs. 81 | 93 vs. 78 |
The single agent won every time. The reasons are familiar to anyone who has run a coordination meeting:
- Nobody moved. In the budget test, the share of agents that ever acted dropped as teams grew from four to 16 users. For Sonnet 5 it fell from 66% to 10%.
- Decisions were committed before the mail was read. In the group-order test, one user's specific request reached the agent placing the order in 94 to 99% of episodes, but was actually in front of that agent at commit time in only 47 to 67%.
- Agents overrode each other. 65 to 77% of team episodes included at least one edit against that request.
- Agents made things up about other people. Claude team episodes contained unsupported claims about other users, such as agreement that never happened, in about 53 to 58% of cases, against 17 to 20% for a single agent.
- Some agents cut other people's work without asking. GPT and Qwen models averaged 3.9 to 7.1 such cuts per episode. Opus 5 had none.
What does this mean for a GC project team?
None of these tests were construction tasks. They were simulations with simulated users, and the authors say so. But the shape is the same as a project team's shared records, and the parallel is easy to draw:
| Tested setting | Closest project parallel |
|---|---|
| Shared calendar with urgent cases | Hoist, crane and loading dock delivery schedule |
| Shared budget that can't cover everything | Contingency or allowance draws across scopes |
| Group order with one person's hard requirement | Combined material order where one scope has a spec constraint |
| Queue of changes before a cutoff | Drawing or model updates before a coordination sign-off |
If three project engineers each point a personal agent at the same submittal log or delivery calendar, this research says to expect stale reads, overwritten entries and an agent reporting that "the super agreed" when the super never did. That last one is the dangerous one on a job, because it ends up in an email.
How should we set agents up instead?
The researchers tested fixes, and two worked:
- Name a lead with written rules. A team with a lead agent told how to rank work, when to release held-back budget, and that other agents report to it scored 71 with Opus 5 on the budget test, above the single coordinator's 64. The plain peer team scored 30.
- Block the commit until everything is read. A guard that stopped checkout until the committing agent had read all pending messages raised the honored-request rate from 44% to about 73% for Opus 5 in reruns. Simply restricting checkout to a lead barely helped.
Translated for a project team:
- One agent, or one named person's agent, owns each shared log or calendar. Everyone else's agent submits requests to it and does not edit directly.
- Write the priority rules down first: which delivery wins a hoist conflict, who can release contingency.
- Nothing gets committed (an order placed, a slot booked, a log status changed) until open requests are read. A person confirms anything that changes someone else's work.
- Treat any agent statement about what another person said or agreed to as unverified until that person confirms it.
The authors also warn that a single coordinator is not a cure. It is not always practical with many users, and a high group score can hide one user getting run over. We covered the cost side of lead-agent setups in our piece on Claude Fable 5.2's orchestrator pricing.
The takeaway
Before you hand every PM and project engineer an agent with write access to the same project records, pick one owner per shared log, write the priority rules, and require a human confirmation on any change that touches someone else's scope. The research covers teammates sharing a resource. It says nothing yet about agents working for a GC, a sub and an owner with different contracts, so keep agents out of cross-company commitments for now.
- Should each project manager have their own AI agent working in the same project files?
- Anthropic's November 2026 research suggests caution. In four simulated shared-resource tasks, teams where each user had their own agent got worse group results than a single agent serving all users, by roughly 10 to 45 percentage points for the two Claude models tested. The tests were not construction tasks, so treat this as a reason to pilot carefully, not as proof.
- What goes wrong when several AI agents share one schedule or budget?
- The researchers saw agents that never acted, agents that committed a decision before reading all their messages, agents that edited a shared order against another user's request, and agents that made unsupported claims about what other people wanted or agreed to. Some models also cancelled other users' jobs without asking.
- Is one central AI agent always better than several?
- No. The authors say a single coordinator is not always feasible when there are many users, and that centralizing does not remove the risk of one user's interests being overridden. A team with a designated lead agent given explicit allocation rules matched or beat the single coordinator in one of their tests.
- What is MAMUBench?
- MAMUBench is an open benchmark released with the Anthropic paper 'Worse Together.' It contains three of the paper's four test environments (a shared compute budget, a clinic calendar and a group order or booking) so others can measure how AI agents coordinate when they act for different people.
- Does this research apply to AI agents from different companies on one construction project?
- The study did not test construction projects or agents from separate companies with opposing commercial interests. Its users were on the same team sharing a resource. Agents representing a GC, a sub and an owner would add contract and consent questions the research does not cover.