Source-linked AI summary
Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams
Sahan Paliskara, Nattaput Namchittai, Andrew Lampinen
TL;DR
When agents serve different users over shared resources, their interactions can produce poor system-level outcomes. The paper compares multi-agent teams with single-agent coordinators across environments and analyzes failures and interventions. Separate agents often perform worse than a coordinator, with the gap varying by model, environment, and intervention.
Problem
When agents act for different users pursuing different objectives over a shared resource, their interacting decisions can produce poor system-level outcomes.
Source: §1 · p. 1Method
Results
Across four environments, separate agents often perform worse than a single coordinator, with the gap depending on model, environment, and intervention.
Source: §9 · p. 9Takeaways & Limitations
Finding effective mitigations requires accounting for both shared and individual interests.
Source: §9 · p. 9Team leads or added guidance can recover performance in controlled settings, but cannot be assumed to exist in shared workspaces.
Source: §9 · p. 9
Abstract
from arXiv · showhide
People are increasingly delegating tasks to AI agents, and those agents are increasingly encountering other people's agents over shared resources such as a codebase, a calendar, or a budget. When each agent acts for a different user with different goals, coordination often fails, and the group ends up worse off than if a single agent had acted for everyone. We study this multi-user, multi-agent setting across five frontier models and 77 scenarios in four environments: an API key environment in which agents share a compute budget, a clinic in which they share a calendar, a personal assistant environment in which they share a group order or booking, and a merge queue in which they share a release cutoff. In each scenario, we compare a single agent that serves every user (a coordinator) to a team in which each agent serves one user, with and without a communication channel between the agents. Teams deliver worse group outcomes than the coordinator in every environment: without a channel, they completely collapse in two environments, and even with one, coordination overhead creates substantial gaps. For example, in the personal assistant environment, the coordinator fulfills a targeted user request about twice as often as teams. We identify distinct behaviors associated with this poor group-level performance, including stalling as teams grow, overriding each other's actions, and fabricating claims. We find effective but environment-specific mitigations, such as a team lead, explicit procedural instructions, and a platform check that makes an agent read its peers' messages before committing. We will release the API key, clinic, and personal assistant environments as MAMUBench, comprising 74 scenarios for evaluating multi-user, multi-agent coordination.
1 INTRODUCTION
The paper examines how separate agents serving different users affect outcomes when their requests compete for shared resources. It compares multi-agent teams with a single-agent coordinator and analyzes coordination failures and mitigations.
1 INTRODUCTION
- Multi-user, multi-agent systems arise when agents serving different users interact over shared resources, potentially producing poor system-level outcomes despite reasonable individual actions.Source: §1 · p. 1
- The silent team collapses in the API key and personal assistant environments.Source: Figure 1 · p. 2
- Coordination failures can reduce system-level performance versus a single-agent coordinator across four environments and varied scenarios.Source: §1 · p. 2
- The paper identifies environment-varying failure modes and proposes mitigations intended to improve them.Source: §1 · p. 2
- MAMUBench evaluates multi-user, multi-agent coordination across 74 scenarios in three environments.Source: §1 · p. 2
2 RELATED WORK
Prior work examines multi-agent coordination, shared-resource cooperation, and systems serving multiple users, but most evaluations do not model separate agents acting for different people in tangible deployment settings.
2 RELATED WORK
- Multi-agent workflows can improve standard-benchmark results (Wang et al., 2024; Li et al., 2024), but gains are not robust across studies of homogeneous workflows and sequential tasks.Source: §2 · p. 2
- Shared-resource studies such as GovSim [Piatti et al., 2024] and CoopEval [Tewolde et al., 2026] score game payoffs rather than tangible user outcomes.Source: §2 · p. 2
- Most multi-user systems use one agent for several users, while this work evaluates 77 scenarios in four tool-using environments against a single-agent coordinator.Prior studies also include market and calendar settings with separate agents for different parties.Source: §2 · p. 3
3 EXPERIMENTAL SETUP
The study compares agent formations across four shared-resource environments, varying scenarios and models, then examines behavior and tests targeted interventions.
3 EXPERIMENTAL SETUP
- The study compares a coordinator, silent team, and peer-to-peer team; solo controls appear where meaningful in the API key and merge queue environments.Source: §3 · p. 3
- Four environments cover shared API-token budgets, merge queues, urgent clinic appointments, and shared reservations, deliveries, and trips.The environments were selected so individual requests are within current frontier models’ capabilities.Source: §3 · p. 3
- Each environment has 3–25 scenarios that vary requests or resource constraints; the default is 20 episodes per scenario and formation.Reported intervals are 95% and condition on the evaluated scenario set.Source: §3 · p. 3
- Agents operate in separate contexts with environment-specific tools and communication; the study compares formation metrics, analyzes episode records, and tests targeted interventions across up to five models.Source: §3 · p. 3
4 API KEY: AGENTS SHARING A CONTESTED RESOURCE
In the API key environment, peer-to-peer teams and silent teams achieve much less of the optimal job value than coordinators. Participation declines as teams grow, while agents also interfere with peers; adding a lead with value-based instructions improves Claude teams’ results.
API key setup
- Researchers share an overnight API-token budget below total demand, and their agents prioritize jobs using the importance conveyed by deadlines and consequences.The agents can submit, kill or scale running jobs, and cancel queued jobs.Source: §4 · p. 3
API key results
- Peer-to-peer teams reach 30% of the optimum for Opus 5 and 12% for Sonnet 5, compared with coordinators’ 64% and 32%; silent teams reach 7% and 2%.Source: §4 · p. 4
Observed behaviors
- From four to sixteen agents, the share that ever act falls from 66% to 10% for Sonnet 5 and from 82% to 25% for GPT-5.6-sol; participation is associated with scores.GPT and Qwen agents kill or downsize peers’ jobs without consent 3.9 to 7.1 times per episode, versus 0.59 for Sonnet 5 and never for Opus 5.Source: §4 · p. 4, Figure 3 · p. 4, Figure 5 · p. 5
Mitigations
- Every Claude team-lead arm beats the leaderless team at every size, and value-based instructions let lead arms outperform the coordinator in four- and eight-user scenarios.The authors interpret this pattern as consistent with a lead supplying responsibility for prioritizing the shared budget, except in the largest teams.Source: §4 · p. 4, Figure 4 · p. 5
5 CLINIC: URGENT SCHEDULING AND DISPLACED PATIENTS
In the clinic, peer-to-peer teams trail coordinators on joint scheduling success, especially when urgency facts are scattered. Procedural instructions can raise team performance above the coordinator’s across both evaluated models.
Setup
- The clinic is fully booked, so urgent appointments require displacing and rebooking routine patients; success requires both booking by the deadline and rebooking the displaced patient.Teams have 17–52 patient-specific agents and can communicate through shared notes, the calendar, and messaging across 24 scenarios.Source: §5 · p. 6
Results
- With scattered facts, peer-to-peer joint success trails coordinator success for every model, including 70.2% versus 84.6% for Opus 5.With assembled facts, gaps shrink for Sonnet 5, GPT-5.6-sol, and GPT-5.6-terra, but remain for Opus 5 and Qwen3.8-max.Source: §5 · p. 6
Notable behaviors
- Opus 5 often misses scattered-fact patients despite agents holding all urgency facts, consistent with a shortfall in acting on available information.For missed scattered cases, an agent held all facts by episode end in 80% of cases and the acting agent had them at its last action in 57%.Source: §5 · p. 7
Mitigations
- 95.3% joint success for Opus 5 and 91.8% for Sonnet 5 with the full instruction stack exceed their coordinators’ 84.3% and 74.2%.The stack combines stricter same-day booking, acting on information heard through another caller, and booking before ending the call.Source: §5 · p. 7
6 PERSONAL ASSISTANT
In shared orders and bookings, coordinators honor the targeted user’s ask more often than teams, while communication can arrive too late to inform a commit. A read-before-checkout guard improves recovery from failed team episodes.
Setup
- Groups of 4, 8, or 16 users share a food cart or booking, with one explicit ask tested across 25 scenarios, including nine safety-related scenarios.The outcome is whether the committed order or booking honors that ask.Source: §6 · p. 7
Results
- Across all 25 scenarios, coordinators fulfill the ask about twice as often as peer-to-peer teams, and silent teams rarely fulfill it.The coordinator leads for every model, including on safety-related asks.Source: §6 · p. 7
- In 94–99% of committed team episodes the ask was sent to the committing agent, but it was in context at commit in only 47–67%; keeping it was less common without it in context.Ask-kept rates were 19–36% when the ask was absent from context, versus 56–68% when present.Source: §6 · p. 7
Notable behaviors
- Overrides occur in 65–77% of team episodes across four models, while fabrications occur in 58% of Opus 5 and 53% of Sonnet 5 episodes.The analyses do not establish that either behavior causes the performance gap.Source: §6 · p. 8
Mitigations
- A guard blocking checkout until the committing agent reads pending DMs recovers 73.1% of failed Opus 5 episodes and 62.3% of Sonnet 5 episodes.Adding line notes and owner acknowledgements recovers 78.9% and 72.0%, respectively; these recovery rates have overlapping intervals.Source: §6 · pp. 8–9
7 IMPLICATIONS FOR SAFETY
Separate agents for users with different goals can create safety-relevant coordination problems in shared environments. The paper argues these interactions warrant study, including where team leads are unavailable.
Implications for safety
- Separate agents can create safety-relevant coordination problems, supporting attention to system design as multi-user agent use grows.The paper notes shared resources such as Slurm clusters, merge queues, and group carts.Source: §7 · p. 9
- Miscoordination and conflict can degrade group outcomes and carry a chance of catastrophic risk when agents represent users without a guaranteed shared goal.The authors argue these settings need study because a team lead may not be available in systems that arise on their own.Source: §7 · p. 9
8 LIMITATIONS
The study’s scale is costly, slow, and stochastic, and some behavioral labels lack human validation. The authors call for faster, cheaper iteration and a standard harness and protocol.
Limitations
- One Claude Opus 5 peer-to-peer pass through MAMUBench’s 74 scenarios processes about 3.4 billion tokens.Serially running all formations takes about 370 hours and 5.4 billion tokens.Source: §8 · p. 9
- Token use can grow quickly as communicating teams, environments, and tasks become more complex, limiting researchers’ ability to afford experiments.The authors identify faster and cheaper iteration as a priority.Source: §8 · p. 9
- Outcomes and costs are stochastic, and Claude-judged consent and fabrication labels were not validated against human judgments.Outcomes are scored mechanically from environment logs; the authors note that no standard harness yet exists for these systems.Source: §8 · p. 9
9 CONCLUSION
The conclusion surveys how separate agents perform relative to a single coordinator across four environments, alongside an example of Maya’s overnight request to manage mixed-priority jobs on a shared cluster. It identifies coordination failures and misalignment as priorities for mitigation and future study.
9 CONCLUSION
- Across four environments, separate agents often underperform a single coordinator, with gap size and direction varying by model, environment, and intervention.Failures include declining participation, unfinished work, and requests that do not reach or influence an agent; effective mitigation must account for shared and individual interests.Source: §9 · p. 9
- Future work should study and monitor misalignment, develop practical mitigations, and train agents to consider other agents’ and users’ welfare.Team leads or added guidance can recover performance in controlled settings, but may not be available in shared workspaces; incompatible goals can escalate into a turf war (Anthropic, 2026b).Source: §9 · p. 9
- LLMs assisted scenario creation, judging, mitigation-prompt refinement, analysis, writing, and figure-making; the authors reviewed the work and take responsibility for its final content.An LLM judge, for example, determined whether a peer agreed before its job was killed or downsized in the API key environment.Source: AI USE STATEMENT · p. 10
A.1 API KEY ENVIRONMENT EXAMPLE
- The API key example’s 25 scenarios vary jobs, priorities, team size, and budget to create fairness-versus-completion tradeoffs, with scores measured against scenario optima.The optimum is the highest-value job set that fits both token budget and rate cap; the passage says coordinators’ higher scores indicate that the priority order was respected.Source: §A.1 · pp. 13–14
- The 100M shared budget and 400,000 TPM cap constrain 92 staged jobs, including a two-stage feature build whose second stage depends on the first.Stage 1 alone is useful, while stage 2 needs stage 1.Source: §A.1 · p. 18
- Maya asks the solo agent to manage the jobs with labctl, do its best across the set, and provide final status in the morning.The request points to the cluster policy at /opt/labctl/POLICY.md.Source: §A.1 · p. 18
- Maya’s overnight workload distinguishes urgent launch-qualification evidence and camera-ready ablations from routine unit evaluations and a feature build that can wait until Friday.The request says missing launch shards leave open questions for Monday’s launch review, while all ten ablations are wanted overnight for the paper’s camera-ready grid.Source: §A.1 · p. 18
A.2 API KEY ENVIRONMENT RESULTS BY SCENARIO AND MODEL
Across models, coordinators outperform teams in the larger API key scenarios, while peer-to-peer teams also struggle in many four-person scenarios.
A.2 API KEY ENVIRONMENT RESULTS BY SCENARIO AND MODEL
- Coordinators clearly outperform teams in 8- and 16-person scenarios, while peer-to-peer teams struggle in many 4-person scenarios.Figure 10 shows scenario-level global outcomes across models; crosses mark three Opus 5 scenarios excluded because of API errors.Source: Figure 10 · p. 19
- Figure 10 uses scenario codes as identifiers, dashed lines to separate user counts, and whiskers for 95% confidence intervals.The three excluded Opus 5 scenarios are stakes 130, cls 197, and duo 409.Source: Figure 10 · p. 19
- Figure 11 measures the share of peer-to-peer agents that attempt at least one action, averaged over episodes by model and team size.The main-text Figure 3 plots these participation values against team scores.Source: Figure 11 · p. 20
A.3 API KEY ENVIRONMENT MITIGATIONS
The passages cover API-key team-lead and clause comparisons, alongside a merge-queue example in which a solo release engineer must land four open PRs before a freeze.
A.3 API KEY ENVIRONMENT MITIGATIONS
- Lead arms add a lead who controls jobs or advises, and every lead brief urges early, portfolio-wide allocation rather than equal sharing.In the lead-only arm, the lead alone can change cluster jobs; advisory leads do not have that exclusive control.Source: §A.3 · p. 21
- Adding release and defer clauses to the value clause changes pooled scores by less than 0.01 across models, lead families, and team sizes.The value clause ranks allocations by value per resource unit and bars disclosure quality or cooperation from shifting allocations by themselves.Source: §A.3 · p. 21
- In 96% of sixteen-agent GPT-5.6-terra peer-to-peer episodes, no action attempt is logged during the final third.The passage identifies early cessation of action attempts as a behavior in large teams.Source: §A.3 · p. 21
- Lead arms score 0.13 to 0.57 of the optimum above leaderless teams at every team size.Figure 12 groups outcomes by team size and marks the coordinator as a dashed-line reference.Source: §A.3 · p. 21, Figure 12 · p. 22
B.1 MERGE QUEUE ENVIRONMENT EXAMPLE
- The merge-queue example gives four pull requests one CI runner for 105 minutes, with 130 runner-minutes needed; the best feasible plan merges #201–#203 and drops #204.The example describes a shared runner and release freeze that prevent all four requests from clearing in time.Source: §B.1 · pp. 24, 27
- The merge-queue example assigns a solo release engineer four open PRs to land before the freeze, covering sandbox security, async streaming, bytecode-cache writes, and URL trimming.The requesters are heads-down until the freeze and will ask for a wrap-up afterward.Source: §B.1 · p. 28
C.2 CLINIC ENVIRONMENT RESULTS BY SCENARIO AND MODEL
Clinic success requires urgent patients to be booked by the deadline and displaced patients to be rebooked; the section also describes instruction-stack mitigations that change agents’ booking procedures.
C.2 CLINIC ENVIRONMENT RESULTS BY SCENARIO AND MODEL
- Clinic success jointly requires urgent patients booked by the deadline and displaced patients rebooked; scenarios were screened for 80% Claude Sonnet 5 coordinator success.The figure reports each bar as a share of the maximum joint success rate pooled over episodes.Source: Figure 16 · p. 40
- Table 3 tracks missed urgent patients by model and condition, and whether scattered-scenario information was collected before the last action affecting a patient or episode end.It reports these information-collection counts both for all urgent patients and for the subset that failed.Source: Table 3 · p. 41
C.3 CLINIC ENVIRONMENT MITIGATIONS
- All three instruction stacks share stricter booking behavior (A), then combine look-once-and-act, book-before-ending, or cancel-and-book-together rules.The tested stacks are s1 = A + B + D, s2 = A + B + E, and s3 = A + C + D.Source: §C.3 · p. 42
- Other rules tell agents to act on same-day information about absent patients and notify the desk handling the earlier call, or to book before leaving the console.For a same-day caller, the procedure also directs agents to move a routine visit and rebook the displaced patient in the same sitting.Source: §C.3 · p. 42
- Figure 17 pools joint success across 24 scenarios by information condition, while Figure 18 shows instruction-stack outcomes by model, information condition, and scenario.Figure 17 distinguishes assembled from scattered facts; Figure 18 places assembled scenarios above scattered ones, with one scenario per row.Source: Figure 17 · p. 43, Figure 18 · p. 44
D.1 PERSONAL ASSISTANT ENVIRONMENT EXAMPLE
The example contrasts a coordinator handling a shared dinner order with separate assistants serving individual diners. Their shared cart has a $92 budget, a strict dietary request, per-person meal rules, and a near-term ordering deadline.
D.1 PERSONAL ASSISTANT ENVIRONMENT EXAMPLE
- Darius’s scenario combines a $92 shared budget with a strict gluten-free requirement and a note asking the team not to spend the budget on certified gluten-free food for him.His note says two plain gluten-free sides are an acceptable dinner; his health note says only GF-labeled items are safe.Source: §D.1 · pp. 45–46
- Each peer-to-peer assistant is a separate process with thirteen tools, including shared-cart operations, personal memory access, and direct messaging.The cart creator alone can check out or cancel, and the platform rejects additions above the cart limit.Source: §D.1 · pp. 45–46
- The generated Copperleaf cart contains Darius’s Little Gem salad and crispy smashed potatoes, with a $91.90 subtotal and $0.10 remaining.The other diners’ items bring the cart to the stated budget limit.Source: §D.1 · p. 46
- The example gives the assistants about 21 minutes to submit the order, while the coordinator’s opening brief includes instructions from all four diners.The brief says the meal benefit is per-person and asks the assistant to make decisions without waiting for users who are busy.Source: §D.1 · p. 46
D.2 PERSONAL ASSISTANT ENVIRONMENT RESULTS BY SCENARIO AND MODEL
Figure 19 reports personal-assistant request fulfillment by scenario and model, with uncommitted episodes counted as unfulfilled.
D.2 PERSONAL ASSISTANT ENVIRONMENT RESULTS BY SCENARIO AND MODEL
- Each bar gives the share of a scenario’s usable episodes whose committed order or booking honors the user’s ask.An episode with no committed order or booking counts as unfulfilled.Source: Figure 19 · p. 48
- The figure presents one row per model and uses 95% Wilson intervals as whiskers.Episode counts are provided in Appendix E.Source: Figure 19 · p. 48
- A silent-team bar at zero indicates its whisker only; the bar itself remains at zero.Source: Figure 19 · p. 48
D.3 PERSONAL ASSISTANT ENVIRONMENT MITIGATIONS
The section tests platform and procedural mitigations for personal-assistant teams, measures behavioral patterns, and reports that house rules improve request fulfillment without closing the coordinator gap.
D.3 PERSONAL ASSISTANT ENVIRONMENT MITIGATIONS
- Mitigations include enforced checks for unread messages, checkout previews, and owner acknowledgements, plus limits on editing another person’s items and a designated team lead.The full platform stack combines unread-message checks, per-line notes, and owner acknowledgements.Source: §D.3 · p. 49
- The mitigation reruns compare failed peer-to-peer episodes against unchanged controls; the reported flip rate is the share that keeps the ask on rerun, not fresh-sample success.The figure gives separate control rates by model and rerun group; its ask-in-context adjustment is an association, not an identified causal path.Source: §D.3 · pp. 49–50, Figure 20 · p. 50, Figure 21 · p. 51
D.4 BEHAVIORAL MEASURES AND REPORTING POPULATIONS
- Behavioral reporting defines overrides as pre-commit edits that worsen a user’s outcome under the scenario contract, and fabrications as unsupported claims about a person.The tables also report committed episodes, whether the ask was in context at commit, and override-edit counts.Source: Table 4 · p. 52, Table 5 · p. 52
D.5 PERSONAL ASSISTANT WITH AGENTS.MD IN CONTEXT
- AGENTS.md supplies house rules such as waiting for everyone’s cart item before checkout and not changing another user’s items without their agent’s DM.GPT-5.6-sol and GPT-5.6-terra were not rerun for this mitigation.Source: §D.5 · p. 53
- The AGENTS.md house rules raise peer-to-peer request fulfillment from 44% to 58% for Claude Opus 5 and from 37% to 61% for Claude Sonnet 5, but both remain below coordinator rates of 88% and 75%.With rules in context, overrides persist in 73% and 58% of episodes, respectively; over 90% of override edits to others’ items still precede a DM from that user’s agent.Source: Figure 22 · p. 53, §D.5 · p. 53
E RUN DETAILS
This section documents the study’s run and harness details, including episode counts, validity exclusions, follow-up designs and samples, consent and fabrication-judging procedures, and the stability of rankings under alternative value assignments.
E RUN DETAILS
- 2,418 Opus 5, 2,374 Sonnet 5, 1,220 GPT-5.6-sol, and 1,236 GPT-5.6-terra team episodes had canary-admissible valid analysis records.Recorded provider failures and 7 non-committed episodes whose canary fired were excluded; fabrication labels covered 2,415 Opus 5 episodes.Source: E RUN DETAILS · p. 56
- For Opus 5 lead-only mitigation runs, episode counts across 4 / 8 / 16 users were 188 / 151 / 129 for lead alone and 199 / 149 / 134 for the full stack.These counts are pooled across all 25 scenarios; the passages also report provider-error exclusions for each size.Source: Table 8 · p. 56, E RUN DETAILS · p. 57
- For advisory Opus 5 runs, counts across 4 / 8 / 16 users were 196 / 153 / 135 for lead alone and 200 / 151 / 136 for + value.The advisory full-stack arm had 197 / 158 / 136 episodes; counts are pooled across 25 scenarios per team size.Source: E RUN DETAILS · p. 57
- Merge-queue follow-ups covered oversubscription and two volatility scenarios, with rerun arms including lead-alone, portfolio, value, release, defer, full-stack, and crew-charter variants.The passages specify paired seeds from the first five control episodes and describe additional explicit-prioritization, team-lead cut-line, and charter-plus-stakes interventions.Source: E RUN DETAILS · pp. 57–58
- Clinic follow-up rescored all 24 instruction stacks, while its failed-team sample included 142 Opus 5 and 186 Sonnet 5 episodes.The mitigation comparison used control, lead, guard, and full-platform arms; admissible counts per arm were 119–134 for Opus 5 and 163–178 for Sonnet 5.Source: E RUN DETAILS · p. 58
- Run details record subset-scenario runs and provider-error exclusions across enforced-arm and full-platform-stack runs.The reported examples include Opus 5 and Sonnet 5 runs.Source: E RUN DETAILS · p. 58
E.1 HARNESS
- API key and clinic agents run sequentially on a shared simulated clock; merge queue and personal assistant agents run as separate pi coding-agent processes.Teams alone require scheduling and messages; silent merge-queue teams cannot see peers’ comments, and episodes cut off by step or wall-clock limits in API key and clinic are not scored.Source: §E.1 · p. 59, Table 9 · p. 59
F.1 API KEY CONSENT JUDGE
- The API key consent judge labels peer actions as consented, informed after, unconsented, or unclear; only unconsented verdicts count as takeovers.A blanket plan counts as consent only when the owner agreed and it specifically covers the job or an explicit class including it.Source: §F.1 · p. 60
F.2 PERSONAL ASSISTANT FABRICATION JUDGE
- The fabrication judge flags only factual claims about principals unsupported by the speaking assistant’s available information, and verifies a claim only if it is upheld, stated as fact, and originated by that speaker.Available information includes the speaker’s brief, read memory, received DMs, and platform tool results; the verify pass searches for plausible support and defaults to refuted when uncertain.Source: §F.2 · pp. 60, 62
G SENSITIVITY OF THE API KEY AND MERGE QUEUE PER-SCENARIO RANKINGS TO THE ASSIGNED VALUES
- Rank values change the winner in one scenario (GPT-5.6-terra, API key), while random-value ranges stay within 2 of the original counts.Three Opus 5 scenarios are excluded due to API errors.Source: Table 10 · p. 63