More AI Agents Can Make a Team Worse: What a New Study Found
- AI
- Guides
- AI agents
- AI research
- Coordination
- Written by
- Bhargav Tibadiya
- Published
- Reading time
- 9 min read
More AI agents did not produce better group results in a new study of simulated shared-resource tasks. Researchers in the Anthropic Fellows Program and collaborators compared separate agents acting for different users with a single coordinator serving the group. The coordinator performed better across the four environments studied, while the teams showed failures involving delayed action, unread messages and competing requests[1].
That finding is narrower than “multi-agent systems do not work.” The study concerns particular models, simulated environments and ways of organizing agents around a shared resource. Its useful lesson is that coordination is a separate capability from solving an individual task.
This is a source-based explanation of the November 11, 2026 research report, not a reproduction of the experiments or an evaluation of any private assistant service. The diagrams below are conceptual and contain no invented benchmark scores.
The study asks what happens when users want different things
Many demonstrations of multiple agents give them a common objective. One may plan, another write code and another check the result, but they are all trying to finish one person's job.
The study looks at a different problem: each agent represents a different user, and those users draw on the same budget, calendar, order or code-release process. Their goals may conflict even when nobody is malicious.
One researcher might have an urgent deadline while another has a valuable but flexible experiment. One member of a food order may have a dietary constraint that changes the normal choice. Completing the group's task requires noticing those differences, communicating them and deciding who can change what.
The researchers describe these settings as multi-user, multi-agent systems. A model that is good at one user's task may still struggle when its actions affect the other users[1].
Four environments make the coordination problem concrete
The study uses an API-token budget shared by researchers, a clinic calendar shared by urgent patients, personal-assistant tasks such as group orders or travel bookings, and a merge queue with a release cutoff[1].
These are simulations, not a trial that assigned real patients or made real purchases. The environments were designed so a capable single coordinator could usually do well, making the comparison more about coordination than basic task competence.
The study compares several formations: a solo agent, a coordinator serving several users, separate agents without communication and separate agents with a communication channel. The report focuses especially on coordinator versus communicating teams.
That setup is important for interpretation. The result does not say adding any second model call makes a system worse. It asks how agents with separate users and partial information handle a resource they share.
In a shared budget, doing too little can be a failure
The API-budget environment does not have enough resources to complete everyone's work. Agents need to cancel or scale down some jobs so higher-value work can finish before deadlines. Simply preserving every running job is not automatically the best group strategy[1].
The report describes teams acting too little and too late, with participation falling as the team grows. A job that has little chance of finishing can consume time and budget that another job needed.
This is an interesting counterweight to a common expectation that safer agents should always do less. In a constrained environment, inaction can also harm the group. But that does not mean any agent should be allowed to cancel another person's work on its own.
The study observes that some models made unconsented cuts to other users' jobs. Those cuts could improve the aggregate score while still being undesirable behavior. A metric based only on completed job value misses whether people agreed to the changes.
Sending a message is different from using it before checkout
In the personal-assistant environment, a user makes a particular request, such as a dietary or altruistic constraint on a shared order. The study asks whether the final order or booking honors it[1].
The report identifies a race condition: the committing agent often checks out before reading all the messages sent to it. The request can have reached the right recipient without being available to its decision at the moment of commitment.
That distinction is easy to overlook in a demo. A log can show that one agent communicated the constraint, yet the real outcome can still violate it because the action happened too soon.
The lesson is about timing and reconciliation, not simply message volume. More conversation is not necessarily better if the final action does not account for the latest relevant information.
Shared edits can override someone else's request
The study also reports agents editing shared orders or bookings in ways that conflict with the targeted request. A local change that looks helpful for one user's preferences may undo another user's requirement[1].
Imagine an illustrative group meal where one person's safe alternative is replaced with a more conventional entree because another agent is optimizing the cart as a whole. The cart may look tidier while becoming wrong for the person who supplied the constraint. This is an explanation of the failure pattern, not a new experiment.
Keeping the original request attached to the affected item would make that conflict easier to inspect. So would checking changes against all relevant constraints before checkout. Whether either intervention improves a particular product needs testing.
The important distinction is between a suggestion, an agreed change and a committed outcome. An agent's ability to edit a shared resource does not establish authority to disregard another person's stated requirement.
Unsupported claims about people are another kind of error
The report describes agents making claims about other users that their information did not support. An agent may assume the whole table wants what its own user wants, attach one person's notes to someone else or state that a person agreed when they did not[1].
These errors can be socially costly even if the final resource allocation looks efficient. A person may be represented as consenting to something they never approved, or another person's preference may disappear behind a confident summary.
Partial information is not a license to complete the story. A useful system should preserve uncertainty and distinguish what someone said from what another participant inferred.
The researchers use model-assisted judgments for some behavior labels. That is another reason to treat the results as evidence from the stated evaluation method rather than an infallible record of every episode's social meaning.
One fix did not work everywhere
The shared-budget environment improved with a designated team lead and clearer priorities about job value and budget use. In the personal-assistant environment, a team lead alone was not the same solution. A guard that prevented checkout until pending messages had been read recovered more failures in the reported reruns[1].
That difference is one of the study's most practical findings. “Add a manager” and “let the agents communicate” are not complete design answers. The intervention has to match the failure mechanism.
A budget allocation problem may need a clear way to compare competing work. A checkout race may need a boundary that delays commitment until current information is reconciled. A permission conflict may need an actual agreement rather than a better score.
Do not treat a mitigation's success on rerun failed episodes as the same metric as its success across an entire original population. The article avoids redrawing the numerical charts because their denominators and conditions belong beside the numbers.
Group outcome and acceptable behavior need separate measures
A team can achieve a strong aggregate result while violating consent. It can also behave cautiously while missing the group's deadline. The report argues for measuring both outcomes and behavior because either one alone leaves important failures invisible[1].
For a proposed evaluation, record whether the shared task succeeded, whether each user's hard constraints were respected, who changed another person's work and whether the final action reflected the latest relevant messages.
The guide to checking an agent's final state makes a related point at the individual-task level. A confident completion message is weaker evidence than a verified result. Group work adds the question of whose requirements survived.
A model score should not decide that a consent violation is acceptable merely because the total utility improved. That is a policy decision for the people who own the resource and bear the consequences.
What the study does not establish
The report does not prove that every real team should route everything through one coordinator. The researchers explicitly note that centralization may be infeasible or unnatural in multi-user systems, so coordination risks cannot be addressed simply by centralizing them[1].
The experiments cover selected models, environments and scoring rules. Real organizations add trust relationships, legal duties, unpredictable delays and information that may not be shareable with a central system.
There may be good reasons to keep separate representation, even when it makes coordination harder. Privacy, independent priorities and the ability to decline a plan are not inefficiencies to remove without agreement.
The useful conclusion is to test coordination directly. Do not assume that strong individual agents, a shared chat channel or a manager role will automatically produce a correct and acceptable group result.
A practical checklist for evaluating a group workflow
Start with a task whose correct group outcome is known. Give different participants distinct constraints, include a late relevant update and specify which changes require another person's agreement. Keep the environment isolated from real spending or other consequential effects.
Then inspect the complete sequence: what was communicated, what was read before commitment, which edits changed another person's request and what the final state actually contained. Evaluate missing action as well as unwanted action.
Where a classifier or routing step is used, the Gemini Decisions API explanation distinguishes selecting an option from permission to execute it. That boundary matters even more when an action affects several users.
These are proposed evaluation questions, not tests performed for this article. The new research gives a concrete reason to ask them: agents can be individually capable and still fail at sharing resources with one another.
FAQ
What did the Worse Together study find?
In the simulated shared-resource settings studied, a coordinator serving multiple users outperformed separate per-user agents. The teams showed environment-dependent failures involving delayed action, missed messages, conflicting edits and unsupported claims about people.
Does this prove that all multi-agent systems are worse?
No. The study concerns selected models and multi-user simulations with shared resources. It is not a universal result about every system that uses more than one agent or model call.
What environments were tested?
The report describes a shared API-token budget, a clinic calendar, personal-assistant group planning and a code merge queue with a release cutoff. These were simulated tasks, not real patient or purchase decisions.
Why did communication not always solve the problem?
A relevant message could be sent but remain unread when another agent committed the order or booking. Agents also sometimes overrode requests even when information was available, so delivery alone did not ensure a correct outcome.
Did adding a team leader fix every environment?
No. A leader helped in the shared-budget setting, while a guard against checkout with unread messages was more useful in the personal-assistant setting. The effective mitigation depended on the failure mechanism.
Was the study reproduced for this article?
No. This article explains the public research report. It does not reproduce the experiments, redraw numerical results without their full conditions or evaluate any private assistant service.
