What is multiplayer agentic coding?

Multiplayer agentic coding is when a team steers an AI coding agent together, in one shared session: everyone sees the same prompts, the same diffs and the same decisions as they happen, and anyone in the room can approve, question or stop the agent. It is the difference between watching a colleague drive over a screen-share and having your own hands on the wheel.

The term is young. Coding agents — Claude Code, Codex and their peers — were built for one person in one terminal, and that is still how nearly everyone uses them. "Multiplayer" names the thing teams keep improvising around: getting more than one human into the loop with the agent, live.

Why single-player agents break on teams

An agent session holds a lot of state: what was asked, what the agent decided, what it changed, and why. When one person owns that session, the rest of the team gets it second-hand.

• The screen-share. Someone drives, everyone else watches a terminal over video and shouts suggestions. Nobody but the driver can approve an edit or answer the agent's question.
• The pasted transcript. After the fact, a log goes into Slack. Useful for the record; useless for steering, because the decisions are already made.
• The "who told it that?" problem. When several people take turns in one shared login, nothing is attributed. A bad instruction has no author. Neither does a good one.
• The one card. Agent usage bills to whoever's API key is in the terminal, however many people were really working.

None of these are model problems. The model is fine. Coordination is the bottleneck.

What "multiplayer" actually requires

Calling something multiplayer is easy; a few properties separate a shared session from a shared login.

1. One timeline everyone reads live. Prompts, agent replies, tool calls and diffs stream to every member as they happen — not after.
2. Attribution on everything. Every prompt has an author. Every approval names who gave it. Every turn's cost is charged to the person who ran it.
3. Decisions from any seat. When the agent asks a question or wants to edit a file, any member can answer or approve from their own screen — the person who typed the prompt is not a bottleneck.
4. Reversibility. Every turn is its own commit, so any member can revert any turn without asking the driver to do it.
5. Somewhere safe to run. If several people can steer an agent, it cannot run on one of their laptops with their credentials. Each turn needs an isolated sandbox with a network allowlist.
6. A channel the agent does not see. Teams need to argue about the plan without the argument becoming the prompt.

Multiplayer is not multi-agent

The two get conflated because both involve "more than one." They are different axes.

Multi-agent means more agents. Claude Code's Agent Teams, for example, lets one session spawn several coordinated Claude sessions that split work and message each other — still one human at the keyboard. Orchestration frameworks do the same at larger scale.

Multiplayer means more humans. One agent (or one per person), many people steering it together.

They combine well: a room where each member drives their own agent on their own branch, merged when ready, is multiplayer and multi-agent. But adding agents never solves the coordination problem between people, and that is the problem multiplayer exists for.

Multiplayer is not shared context either

A second thing that gets called "multiplayer AI coding" is shared context: a committed CLAUDE.md, a shared prompt library, runbooks so every agent on a team starts from the same specifications. This matters — it is how a team's agents stop re-deriving what a teammate already knows — but it is about consistency between separate sessions, not collaboration within one. Two engineers with the same runbook are still two people in two terminals.

What it looks like in practice

In Poly, a project is a room with a git workspace behind it. A teammate types a prompt; the agent replies in a timeline everyone in the room is watching. In manual mode the agent asks before it edits a file, and the approval card appears on every member's screen — whoever gets to it first decides, and the timeline records who. If the agent asks a question ("polished product or quick prototype?"), members' picks show up live so the room converges before anyone submits. When the turn finishes, a receipt names who ran it, which model, how long it took and what it cost in credits. Any turn can be reverted from its receipt. Group chat, threads and polls sit beside the timeline where the agent cannot read them.

That is the whole idea: the agent session itself becomes the shared space, instead of an artifact of it. If you are coming from Claude Code specifically, the collaboration guide walks through what it offers natively and where a shared room fits. Poly is free to start.

Who it is for

Teams where AI agent work should be visible, reviewable and attributable rather than hidden in one person's terminal: cofounder pairs (including a non-technical cofounder who approves edits from the browser), hackathon teams, agencies building in front of a client, and engineering teams that want the agent's work in a shared record.