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.<\/p>\n
This advice builds on Worse Together<\/em>, a simulation study published on Anthropic’s Alignment Science blog<\/a> 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.<\/p>\n 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.<\/p>\n 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<\/a>, 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.<\/p>\n 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.<\/p>\n Start from the tools your agents are connected to and the permission each connection holds<\/a>. 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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%.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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).<\/p>\n 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<\/a> 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nThe shared-resource commit check<\/h2>\n
Every resource more than one person’s agent can change<\/h3>\n
One committer for each shared resource<\/h3>\n
\n
A read-before-commit guard<\/h3>\n
Who may see each request<\/h3>\n
\n\n
\n \nShared resource<\/th>\n Agents that can change it now<\/th>\n Committer<\/th>\n Rule the committer follows<\/th>\n Guard<\/th>\n Who may see the requests<\/th>\n<\/tr>\n<\/thead>\n \n Customer demo calendar<\/td>\n 9<\/td>\n A coordinator: one scheduling agent for all nine people<\/td>\n Urgent requests first, then in order of arrival<\/td>\n No booking confirmed while a request to the coordinator is unread<\/td>\n The coordinator and the team lead; each requester sees only their own<\/td>\n<\/tr>\n \n Monthly AI tool credit pool<\/td>\n 9<\/td>\n A lead agent; the other agents send it requests<\/td>\n Rank requests by value; release held-back credit while it can still be spent<\/td>\n No spend approved while a request to the lead is unread<\/td>\n The lead agent and the budget owner<\/td>\n<\/tr>\n \n Offsite travel booking<\/td>\n 4<\/td>\n The office manager<\/td>\n Each traveller’s stated needs first, then the lowest fare<\/td>\n No booking made while a traveller’s request is unread<\/td>\n The four travellers and the office manager<\/td>\n<\/tr>\n \n Release queue<\/td>\n 5<\/td>\n The release manager<\/td>\n Merge in queue order; requests after the cutoff wait for the next release<\/td>\n No merge while a request on the queue is unread<\/td>\n The five engineers and the release manager<\/td>\n<\/tr>\n \n Total<\/strong><\/td>\n 27<\/strong><\/td>\n 4 committers<\/strong><\/td>\n 4 written rules<\/strong><\/td>\n 4 guards<\/strong><\/td>\n 4 access decisions<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What to count in a pilot besides the total<\/h2>\n