---
title: 'In the News: November 12, 2026 (Midday)'
description: 'An Anthropic Fellows study finds one agent per user does worse than one shared agent in four test environments, a merge queue among them.'
canonical_url: 'https://darkfactory.dev/news/2026-11-12-midday'
markdown_url: 'https://darkfactory.dev/news/2026-11-12-midday.md'
collection: news
date_published: '2026-11-12T13:12:00-05:00'
date_modified: '2026-11-12T13:12:00-05:00'
---

# In the News: November 12, 2026 (Midday)


When several people each send their own agent at one shared resource, the group gets less done than when a single agent serves all of them. That is the result of a study from the Anthropic Fellows Program across four simulated environments, one of them a merge queue ahead of a release freeze. A second paper, accepted to ICSE 2027, measured students reading code with an AI assistant: their cognitive load went up and their own ratings of the work did not.

## 1. One agent per user did worse than one shared agent in every environment an Anthropic Fellows study tested

**[Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams](https://alignment.anthropic.com/2026/worse-together/)** · Sahan Paliskara and Nattaput Namchittai, Anthropic Fellows Program; Jacqueline Tay, independent; Avery Griffin and Andrew Lampinen, Anthropic · Anthropic Alignment Science Blog, November 11, 2026

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](https://arxiv.org/abs/2610.00583), 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](https://github.com/safety-research/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.

## 2. Students reading code with an AI assistant carried more cognitive load and did not report it

**[Feeling Easier, Working Harder: Cognitive Load in AI-Assisted Code Comprehension](https://arxiv.org/abs/2611.12019)** · Maryangela White, Maximilian Rose, Matthew Buckman, Amy McDonnell, Francisco Ortega and Bianca Trinkenreich, Colorado State University · arXiv, submitted November 9, 2026; accepted to ICSE 2027

Twenty students from two Java courses each read six Java snippets of about 30, 45 and 70 lines, half with a Gemini chat window open on a second monitor and half without, then answered four comprehension questions per snippet without the assistant. Throughout, a small motor on the shoulder or arm vibrated every three to five seconds and the participant pressed a button in response. Slower responses indicate that the main task is taking more attention. The method is an ISO-standardized detection-response task, and the authors say that to their knowledge it has not been applied in software engineering before.

With the assistant, reaction times were 11.2% higher overall (p < .001): 12.7% higher while reading, and still 6.9% higher during the quiz, when the assistant was no longer available. Self-reported workload (NASA-TLX) and task difficulty (SEQ) did not differ significantly between conditions. Neither did comprehension: mean quiz scores were 3.22 of 4 with the assistant and 3.23 without. Scores clustered near the maximum, and the authors read the result as "an absence of evidence for a benefit, not as evidence that AI confers none." Java experience did not change the effect. In open-text answers, roughly a quarter of participants described letting the assistant's explanation replace reading the code.

The sample is 20 students, the code is short, and the assistant sat in a separate browser window, not in an IDE. The authors also note that higher load is not necessarily harmful; it can reflect engagement.

**Why it matters:** If you judge an AI tool by asking developers how hard the work felt, this experiment is a caution: that question missed an increase the instrument measured. The authors recommend adding objective load and performance measures. The study covers students with a chat window, not professionals reviewing agent-written changes.