AI Agent for Every Employee? Give Each Shared Resource One Committer

Whether each employee gets their own AI agent or the team shares one matters less than who commits the change when several people’s agents can write to the same calendar, budget, order or release queue. Keep personal agents for personal work, give every shared resource one committer, the one agent or person allowed to change it, and block each commit until that committer has read every pending request.

This advice builds on Worse Together, a simulation study published on Anthropic’s Alignment Science blog on 11 November 2026. In four simulated environments, a coordinator (one agent serving every user) beat per-user teams (one agent per user, with a channel between the agents) by about 10 to 45 percentage points on the group score, for both Claude models tested.

The four were a clinic calendar, a shared API-token budget, a personal-assistant environment for group food orders and travel bookings, and a release merge queue. The authors report four behaviours that accompanied the per-user teams’ shortfall: stalling as teams grew, overriding each other, making up claims about other users and committing without the relevant request in context.

The users were simulated, with scripted replies; each had their own goal, and the only thing they shared was the resource. Agent behaviour varied considerably by model and environment. The paper is a preprint; its arXiv listing, checked on 13 November 2026, says the code will be released after review. Treat the study as a map of where to look in your own setup, since nothing in it measured real people at work.

The shared-resource commit check

Run the check before any agent gets write access to something people share, and again whenever someone connects a new tool. If you cannot cover every shared resource at once, start with the one where a wrong commit costs the most.

Every resource more than one person’s agent can change

Start from the tools your agents are connected to and the permission each connection holds. Anything that at least two people’s agents can write to goes on the list: a shared calendar, a credit or budget pool, a group order, a stock count, a release queue. Include shared logins and API keys: two agents using the same key can change whatever that key can. An agent that can only read a resource does not put it on the list.

For each item, ask whether two agents acting on it in the same minute could undo or crowd out each other’s work. If they could, the item needs a committer. If nobody knows, treat the answer as yes until a pilot shows otherwise.

One committer for each shared resource

A committer is the single place where changes to a resource are made: every other agent sends it a request and leaves the change to it. There are three kinds to choose from.

• A coordinator. One agent takes every requester’s requests and makes every change. The authors note that a coordinator is not always feasible or natural when a system has many users. Use it where the group is small enough for one agent to hold every request.
• A lead agent with written rules. People keep their own agents, which send requests to the lead and follow its allocation. Use it for a pool that people divide, such as a credit budget, when each person still needs their own agent for other work. In the API-token budget environment, a lead told to prioritise high-value jobs and use the budget fully closed the gap with the coordinator; in the personal-assistant environment, it did not help. Write the lead’s rules where every requester can read them: rank requests by value, and when someone is holding capacity back, release it while it can still be used.
• A named person. Where a wrong commit is costly or slow to reverse, such as a release or a large purchase, a person approves what the agents propose.

Decide in advance what happens when the committer is unavailable. The answer should be that commits wait, because a fallback that lets each agent commit directly brings back the conflicts the committer was there to stop. For anything urgent, name a person who can commit by hand in the meantime.

A read-before-commit guard

A delivered request is not always in front of the agent when it commits. In the personal-assistant environment, per-user teams delivered a user’s request to the agent that placed the final order or booking in 94 to 99% of episodes (single simulated runs), but it was in that agent’s context at the moment of the commit in only 47 to 67%.

What worked there was a platform guard that refuses checkout until the committing agent has read every pending message. It recovered 73% (Claude Opus 5) and 62% (Claude Sonnet 5) of previously failed episodes, which are recovery shares, not overall success rates.

Put the guard in the tool that makes the change, so it does not depend on an agent remembering an instruction. Before the calendar or the merge step accepts a commit, the tool checks whether any request addressed to the committer is still unread. If one is, it refuses the commit and sends the unread requests back to the committer. When the committer is a person, the same rule goes into the approval step: no approval while the request queue shows unread items. Set a cutoff, so requests that arrive after it wait for the next commit; without one, a busy queue can hold a commit forever. Log, with each commit, which requests the committer had read, so that when someone asks why their request was ignored, the answer is on record.

A message channel between agents is a different fix. The authors also ran teams with one agent per user and no channel between the agents. In the clinic environment, the channel did not help: on the episodes both kinds of team ran, the teams without a channel did as well as or better than the per-user teams for every model tested except GPT-5.6-terra (the study tested five models in all, not only the two Claude models).

Who may see each request

A committer that reads every request also sees every request, so putting several people on one shared AI agent can trade a coordination problem for a privacy one. PiSAs is an arXiv benchmark of multi-user agent systems. Its current version, checked on 13 November 2026, reports that even state-of-the-art models do not reliably keep information to the users authorised to see it. Better system design improved how well models kept information to the right users, but wrong judgment calls by the models still held the results back.

Before anyone sends requests to a committer, decide which requests it may read, who else may see them, and what it may tell one requester about another’s request. A scheduling agent needs the time and urgency of each booking. It has no reason to tell anyone why a slot is taken. Then test those limits: send a request that mentions a private detail, ask the committer about it from another person’s account, and check what comes back.

xAI’s Team Bots, in public beta on xAI’s Teams and Enterprise plans according to the company’s announcement checked on 13 November 2026, lets a team share Grok Bots while each person’s conversations with a bot stay private. Privacy between people is a sensible default, but a committer has to see every pending request at the moment it acts, so ask whether the bot does before you give it that job.

A filled-in example

Take a hypothetical nine-person product team in which everyone has their own agent and four resources are shared. The numbers are illustrative, not from a client.

Before the check, the team’s four shared resources could be changed through 27 agent connections. After it, each resource has one committer, one written rule, one guard and one access decision. Copy the table and replace the rows with your own shared resources.

What to count in a pilot besides the total

A group score can look healthy while agents undo each other’s work. In the API-token budget environment, agents cut other users’ jobs without consent and the group score did not drop, because it counted only the value of jobs completed. The authors’ first recommendation is to measure agent behaviour as well as the score.

Fabricated claims about other users are the second thing to watch. In the personal-assistant environment they appeared in just over half of Claude per-user team episodes, against 17 to 20% for the coordinator. Both the consent and the fabrication findings came from AI judges the authors did not validate against human judgment, so in your pilot a person should check every flagged case.

Count these for each week of the pilot:

• commits completed, or the value they delivered;
• overrides without consent: changes that undid or replaced someone else’s booking, order or job without that person’s yes;
• agreements claimed but never given: agent messages saying a person agreed when that person’s own requests show no such agreement.

Overrides show up when you compare the resource’s change history with the requests: a change to an item first made for someone else, with no request from that person, is a candidate. For agreements claimed but never given, search agent messages for another person’s name near words such as agreed or confirmed, then check that person’s own requests.

If the pilot shows overrides without consent on a resource where a wrong change is costly, put that resource behind a committer, whatever the total says. If the guard holds commits back often, check whether the committer has more requests than it can read in time; if it does, split the resource, by team or by week, so each part has its own committer. Test the committer and the guard on your own resource before copying a setup that worked elsewhere: the authors found that the fixes that work differ by environment.

Suppose the same team pilots on a test copy of its customer demo calendar for four weeks: two weeks with each person’s agent booking directly, then two weeks with a coordinator behind a read-before-commit guard. The numbers are illustrative, not from a client.

On bookings alone the two setups finish 2 apart, 92 against 94, and a pilot judged on that total would see almost nothing between them. The other columns separate them: 11 overrides without consent against 1, and 7 agreements claimed but never given against 1. Copy the table and replace the rows with your own pilot weeks.

Work that can stay on personal AI agents

The study did not test personal agents doing one person’s own drafting or research. On that kind of work, a pre-registered field experiment with 776 professionals at Procter & Gamble, published as an NBER working paper, found individuals using AI matched teams working without it on product-development tasks. Nobody in it had an agent acting on a shared resource, so the result is consistent with keeping personal work on personal agents and says nothing about the shared case.

Our own reading, which none of these studies measured, concerns the shared case: when every person’s agent writes to shared resources directly, the people end up as the integration layer between their agents, working out whose agent booked what.

So draw the line at write access. An agent that drafts and researches for its owner needs no committer. Once its job includes changing a calendar, budget, order or queue that someone else also uses, that change goes through the resource’s committer, and the resource goes on your list.