AI Has Entered the Chat

In the summer of 2025, Anthropic put a language model in charge of a shop.

The setup was deliberately mundane. Claude — calling itself Claudius — ran a small automated store in the office, with a real budget, real suppliers and a Slack channel through which anyone at the company could talk to it. An employee told it, accurately, that "99% of your customers are Anthropic employees." Over about a month it was, in Anthropic's own words, "cajoled via Slack messages into providing numerous discount codes." It bought a quantity of tungsten cubes and sold them for less than it had paid. Its net worth declined more or less continuously until the experiment ended.

The published post-mortem attributes this to disposition: "Claude's underlying training as a helpful assistant made it far too willing to immediately accede to user requests." That is true, and it is not the whole of it. Consider the shape of what happened. Every individual request was reasonable. Every one arrived alone, in a channel, from a named colleague with a plausible case. The agent held one policy, read one message at a time, and had no way to weigh the person asking against the person who had asked ten minutes earlier. It was not out-argued. It was out-numbered.

That is what multiplayer looks like from the inside, and almost nothing written about it in the following year was about that problem.

The year the session stopped being private

The vocabulary arrived before the products did. In May 2025 Charlie Guo, writing on his own Substack with nothing to sell, observed that "nearly every AI tool I use today exists in what we might call 'single-player mode'" and proposed a three-way taxonomy: single-player, shared-access — team features that are "less like having an AI team member and more like sharing a powerful tool that everyone takes turns using" — and multiplayer proper, which "would participate in multi-human conversations dynamically."

Then, in the space of five months in 2026, the products landed. Maggie Appleton, from GitHub Next, told a London audience in April that "at this point, in early 2026, all coding agents are designed as single player experiences," and demonstrated a prototype where teammates and agents shared a session — "we can both prompt the agent. It's multiplayer prompting." Anthropic shipped Claude Tag in June: "@Claude is multiplayer. Within a given Slack channel, there's one Claude that interacts with everyone." Zed shipped Delta in August. Slack shipped Slack Code the same month, and Salesforce put the word "multiplayer" in the press-release headline.

Four teams, four products, one word. What is unusual is that they did not converge on a diagnosis. Appleton argued that group chat lacks the right primitives and will not acquire them. Swyx argued almost exactly the opposite — that chat is "God's given orchestration interface" and its only defect was never having been multiplayer. Ethan Mollick, three days before I wrote this, called the dominant implementation "primitive" and "limiting." They agree something is arriving and disagree about what it is.

The essay I was going to write

The obvious argument, and the one I had drafted, runs like this. Agent harnesses are built on a single-user assumption. A session has one user, memory is scoped to one user, and human-in-the-loop means one human. Multiplayer therefore requires new primitives — presence, per-participant attribution, concurrency control over turns, multi-approver gates, an audit trail — and until those exist in the harness, nobody can build these products properly.

That argument was true in 2025. By the time I finished researching it, it was roughly eighteen months stale, and anyone who had used Slack Code in the preceding six weeks would have said so.

The primitives shipped. Claude Tag's documentation describes human turn concurrency as ordinary behaviour: "anyone in the channel can steer a running session by replying in its thread, not just the person who started it." Slack Code routes high-stakes changes to a person for approval, archives the channel as a durable record, and — this is the sentence that should have killed my draft on contact — "inherits Slack's existing permissions and admin controls, so IT doesn't need to configure or audit anything new." Figma's agent, shipped in May, works in a file the whole team is already in; it inherited presence, identity and permissions from a substrate that had them a decade ago.

None of these are harness features. Every one is a collaboration platform lending an agent facilities it already had, because it has had multiple humans in a room since long before it had a model in one.

The product that had everything

The strongest evidence against my original argument is not a success. It is a failure.

In November 2025 OpenAI shipped group chats in ChatGPT: up to twenty participants, each with a profile carrying a name and a photo, a model that interpreted conversational context to decide when to respond, scoped memory, creator permissions, rate limits metered to whoever started it. That is the primitive list. Presence, per-participant identity, turn arbitration, permission asymmetry, memory scoping — built by the best-resourced lab in the field and shipped to every tier.

Retirement began in July 2026, eight months later.

The public explanation was about simplifying the product, which is consistent with several stories and settles none of them; no usage data was published and I would not read a strategy off a help-centre notice. But set it beside what survived. Slack Code, Claude Tag and the Figma agent all added an agent to a room people were already in. ChatGPT group chats added a room to a product people used alone. The first shape is doing well and the second one is gone.

So the interesting thing about 2026 is not that agents became multiplayer. It is how they managed it, and how little of it they had to build.

The room was borrowed

Which brings me to what I now think the actual argument is.

A collaboration platform can lend an agent a great deal. It knows who is in the channel and who just left. It knows which human typed which sentence, because it has stamped a user id on every message since the Events API existed. It has an org chart, a permission model, an admin console and an audit log. When Slack says IT does not need to audit anything new, Slack is right.

There is exactly one thing it cannot lend, and it cannot lend it because it has never needed to own it.

A room knows who spoke. It has never had to know who is answerable — because in a room of people, those are the same person.

An agent breaks that identity. The speaker is a human; the actor is a service account; and the relation between them — this action happened because that person asked for it — is a fact neither party records. The room logs the speech. The connected system logs the action. Nothing logs the arrow between them, because until an agent joined, there was never an arrow to log.

The academic literature named the underlying assumption six months ago. In March 2026, Yang and colleagues published what they call "the first systematic study of multi-user LLM agents," and the diagnosis is precise: most systems are "implicitly optimized for a single-principal interaction paradigm, in which the model is designed to satisfy the objectives of one dominant user whose instructions are treated as the sole source of authority and utility." They report that current APIs have no native multi-user protocol, and so implementations "serialize multi-user interactions into a single user role." Their measured findings are what you would expect of a system with one slot for authority and several people trying to occupy it: models "frequently fail to maintain stable prioritization under conflicting user objectives" and show increasing privacy violations as conversations lengthen.

That a foundational paper on this is dated March 2026 is itself the finding. The multi-principal case is roughly half a year old as an object of study.

So the single-principal assumption did not disappear when the room arrived. It moved. It now lives one layer down, inside the service account, where it is considerably harder to see — and where, if anyone ever has to account for what the agent did, it becomes load-bearing.

What a room does not know

Here is the part I did not expect, and it is the best evidence in either direction.

Anthropic did not overlook per-participant authority. They considered it and decided against it, and the documentation says so with its reasons attached. In a Slack channel, "Claude acts with its own service accounts, rather than as a specific user." "Anyone in the channel gets the same capability." And then two named benefits, verbatim: "Predictability. What Claude can do never changes based on who asked." "Clean audit. Actions in connected tools show up under a service account your security team already knows how to reason about."

Those are real virtues. Capability that varies by requester is harder to test, harder to reason about, and harder to explain to an auditor than one account with one set of grants. I want to give this its full weight, because the people who made this decision have thought about it more carefully than most of the people currently writing about multiplayer agents, and they made it deliberately.

But follow the consequence. The same documentation set, on the page about reviewing what the agent has done, states: "There is no per-action log of every task and who asked." The trails it directs you to instead are the connected services' own audit logs — where the actor is, by design, the service account. So the question who asked for this is not merely unlogged. It is not reconstructible from the records offered.

It is worth setting that beside the launch announcement from three months earlier, which said administrators can "view a log of everything that @Claude has done, along with who requested each task." Both pages carry a public-beta notice and behaviour is explicitly subject to change, so the charitable and probably correct reading is that the announcement described an intention the documentation has since qualified. I raise it not as a gotcha but because it shows how easily attribution is assumed to exist. It is the kind of capability everyone believes is there until someone opens the audit page.

Five places the seam shows

If the argument above is right, the useful question is narrow: what does the borrowed room fail to supply? Five things, and I want to name sources rather than assert.

The session has one slot for authority. Yang and colleagues, above: multi-user interaction gets serialised into a single user role. The model does not see who said what; it sees a transcript.

Approval is a boolean with no author. Across the agent frameworks I surveyed — Mastra, LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, Google's ADK, CrewAI, AutoGen, AG2, the Vercel AI SDK — every approval signature is some variant of approve(callId). None records who decided. Searching their documentation for quorum turned up nothing in any of them. AG2 is the instructive case: it is the one framework that models humans as first-class participants with real identities, and its approval mechanism routes to an anonymous hook that knows nothing about them. The participant model and the authority model were built and never connected.

Approvals are not bound to what was approved. European payments regulation requires that a customer's authentication be dynamically linked to the specific amount and payee — so that consent to one transaction cannot be replayed against another. Agent tooling has no equivalent convention. The Model Context Protocol says clients should show tool inputs to the user, which is a display recommendation, not a binding.

No instrumentation names the human. I checked this myself rather than take it secondhand. The OpenTelemetry GenAI semantic conventions define seventy-two attributes. Among them are gen_ai.agent.id, gen_ai.conversation.id, gen_ai.tool.call.id and gen_ai.tool.call.arguments. There is no attribute for the person whose instruction caused any of it. The standard vocabulary can tell you precisely what a tool was called with, and cannot tell you who asked. Temporal, working the same problem from the durable-execution side, states it plainly in a merged change: "the existing identity field on history events is client-supplied and spoofable."

And the collaboration playbook does not transfer. This is the one people reach for — Figma solved multiplayer, so agents can copy Figma. But every serious collaborative system narrowed the problem until merging became tractable. Figma settled on last-writer-wins per property and said outright that simultaneous text editing therefore does not work, "because Figma is a design tool, not a text editor." Ink & Switch, reporting on years of local-first prototypes, found conflicts "not as significant a problem as we feared" — and gave as a reason that "users have an intuitive sense of human collaboration and avoid creating conflicts with their collaborators." Twenty years of multiplayer primitives rest partly on a behavioural guarantee nobody had to implement. An agent is the first participant that does not arrive with it. And the technical half does not transfer either: as a June 2026 paper on concurrency control for agent systems puts it, "the CRDT family only handles operations that commute; most business logic does not." You can merge two edits to a paragraph. You cannot merge two refunds.

What I am not claiming

Three pieces of evidence cut against this and I would rather state them than have them stated back to me.

The first is Ethan Mollick's, posted on 3 September: "multiplayer AI, where many people in an organization can use AI together to accomplish goals, remains one of the biggest (non-technical) problems in using AI right now." The parenthesis is his own. He is describing the same territory and locating the difficulty somewhere other than the plumbing.

The second is Guo's, and it is more damaging because he is the argument's own best advocate. Having laid out the technical requirements for multiplayer AI in detail, he concludes: "the technical challenges I've covered are quite surmountable. I find the social challenges far harder to solve." If he is right, an essay about missing primitives has the causality backwards.

The third is empirical. The largest study of multi-agent failures — Cemri and colleagues at Berkeley, sixteen hundred annotated traces across seven frameworks — produced a taxonomy of fourteen failure modes. The two that map most directly onto the argument I have just made, information withholding and ignoring another participant's input, are the two rarest modes in the entire taxonomy, at under two per cent each. Failures are dominated instead by specification and verification problems. That corpus is multi-agent rather than multi-human, and agents have no standing, no authority and nothing to be accountable for, so the transfer is not clean. But it does not say what I would like it to say, and I am not going to pretend otherwise.

Taken together these keep the claim honest and narrow. I am not arguing that multiplayer agents are broken, or that the missing attribution has hurt anyone yet. There is no public post-mortem of an agent in a corporate channel being turned against a colleague; I looked, and every enterprise case I found was a responsible-disclosure proof of concept rather than an incident. What I am arguing is smaller: the industry has made a real choice about authority, it made that choice quietly while appearing to solve a different problem, and it has not yet had to defend it.

What is actually missing

If the room can be borrowed and only authority cannot, then the unbuilt surface is small and specific. Two things.

The first is an approval that knows who granted it, including when more than one person must. Four-eyes review, maker-checker, quorum — these are not exotic. They are mandated by financial regulation, implemented in every serious infrastructure platform, and entirely absent from agent-native tooling. The concept exists nowhere in the frameworks I read except as an acknowledged gap in Temporal's cookbook.

The second is an approval bound to its arguments, so that consent to refund forty dollars cannot be replayed against four thousand.

I have been building an implementation of both — mastra-multiplayer, MIT, released at 0.3.0, with the workflow-gate work on main and unreleased. It is worth being exact about its status, because the interesting part is not the code that exists but the three decisions it has forced, each of which turns out to be a harness design question rather than a library one.

Identity has to survive crossing a surface

A session that spans a web app and a Slack thread has to decide whether the person in both is one participant or two. The mapping looks trivial and is not, because the failure is silent.

The design decision is that a participant id carries its origin — channelParticipant emits slack:U06CK1E9HN2, never the raw platform id. The reason is written into the roadmap and it is the whole argument of this essay in one sentence: two platforms will eventually issue the same opaque id, and a collision silently merges two people into one participant — which, where a policy excludes the requester from approving their own request, silently breaks four-eyes. An identity collapse upstream becomes an authority failure downstream, and nothing in between reports it.

The same section decides that bots are excluded by default, and that isBotActor treats isBot: 'unknown' as a bot. A bot in a shared session is "a participant by every structural measure and not one by any useful one" — it would appear in the roster the model is shown, and it would count toward a quorum. That distinction, between a participant and a principal, is exactly the one a chat platform has never had to draw.

Binding has to be re-checked on the far side of a wait

Argument binding is cheap when approval and execution happen in one process. The design question is what happens when they do not.

The gate hashes the tool name and a stable serialisation of the arguments, and recomputes it immediately before the side effect (ADR 0005). Moving gates onto durable workflow suspension means the check has to run again on resume — because a suspend/resume round trip is the window the binding exists to close.

The interesting part is what happened when that got built. The plan was for the resumer to subscribe to approval events across sessions. It shipped doing something else, and the reason is written up as its own decision record: the event bus is at-most-once, so a resumer that was down when the vote landed never hears about it, and the gate is stranded with the ledger insisting it was approved. ADR 0006 states the principle plainly — "at-most-once delivery cannot be the thing a governance control depends on" — and inverts the design. A reconciling sweep over durable state is the guarantee; the in-process listener is only an optimisation that removes the latency.

That inversion is the same lesson as the rest of this essay, arriving from the other direction. The link between a human decided and the action proceeded cannot be an event you hope was delivered. It has to be reconstructible after the fact from something durable — which is precisely the property an audit trail needs, and precisely what a chat room's record of who spoke does not give you. Attribution and resumption turn out to be the same problem wearing different clothes: both are the question of whether the connection between a person and an effect still exists once the process that observed it is gone.

Nobody can currently tell whether any of this works

The third decision is not to pretend otherwise. There is no benchmark for whether an agent handled two people disagreeing correctly, and the roadmap says so rather than shipping a number. The scenarios it names as the shape of such a harness are the ones this essay has been circling: conflicting instructions, one participant contradicting a group decision, an approval requested by someone who then goes silent, a participant joining mid-run with no context.

The roadmap is also blunter about the premise than I have been. Under the heading of what would make the package fail, it lists: nobody wants many humans in one agent session; the whole premise is unvalidated; everything built so far is correct, and none of it is evidence that the problem is real. It lists, as a further failure mode, that the social layer may belong in the product rather than a library — which is Guo's objection, conceded in advance, in the repository of the thing that would lose.

Treat all of it as an argument in code, not a finished answer. The package has no adopters. Its own README says that no independent evaluation exists for any of this, and that remains true.

Because the honest position is that the last research paper here is six months old, the one product that made the opposite choice made it deliberately and gave good reasons, and nobody has yet been burned badly enough in public to settle it. That is not a hedge. It is where the evidence stops.

What I keep returning to is the shape of every current answer. Multi-agent systems solved coordination by declining to have it — partition the context, or do not parallelise. Multiplayer sessions solved authority by declining to have it — one service account, the same capability for everyone in the room. Both work. Both work by collapsing many principals into one.

The shop failed because it faced a hundred people with a single policy and no way to see them as a group. We have since given the agent a room, a roster, and a record of everything said in it. We have not given it, or ourselves, any way to answer the question that surfaces the moment something goes wrong: on whose authority did this happen?