What are multiplayer coding agents?

Updated September 20, 2026 · first published July 10, 2026 · by the AQ team

Multiplayer coding agents are AI coding agents whose working sessions are shared, live places that a whole team can enter: everyone sees the same running agent, the same terminal, the same code, and the same app preview, and anyone can steer. The contrast is the single-player model that dominates today, where an agent runs in one person's editor or cloud sandbox and everyone else receives the output as a diff or a pull request.

Put differently: in the single-player model, the work arrives as a package. In the multiplayer model, the work is a place.

Watch: a product team collaborating live with coding agents

Why single-player agents became the bottleneck

By 2026, running one good coding agent stopped being the hard part. The CLIs (Claude Code, Codex, and their peers) got strong enough that individual engineers routinely run several in parallel, and the tooling followed: parallel runners, worktree managers, cloud agents, agent fleets. Output multiplied.

Coordination didn't. Every additional agent produces more diffs to review, more context to transfer, and more "what is it doing?" questions from teammates who can see the PR but not the process that produced it. Teams feel this as PR review fatigue and as a new kind of silo: the agent session itself, visible to exactly one person. The isolation is now measured: a July 2026 LeadDev analysis of 25,264 agent-generated PRs found that in 79 percent the same developer both reviewed and modified the agent's contribution (the self-review problem). The demand for a way out is easy to observe: developers ask for real-time multi-user agent sessions in open feature requests on Claude Code (share links today are read-only views), and orchestration threads keep surfacing on Hacker News. Meanwhile coding agents are already installed in 75 percent of Linear's enterprise workspaces, per The Register: the agents are here, the team layer isn't.

What qualifies as multiplayer

A tool is multiplayer in the meaningful sense when the running session, not just its output, is shared:

• Same live session. Two people open the same workspace and see the same terminal output at the same moment, not a replay and not a read-only transcript.
• Anyone can steer. A teammate can prompt, interrupt, or redirect the agent mid-run, the way anyone can grab a marker at a whiteboard.
• Handoff without re-setup. Sending someone the work means sending a link to the place, with the environment, history, and running processes intact. No re-cloning, no "works on my machine".
• Roles beyond engineers. A PM or designer can watch the preview, comment on the running app, and push feedback into the agent's context without touching a terminal.
• Outsiders can look. Guest access lets a stakeholder see the live result without a seat and without the work going public.

Screen sharing fails the first test (one person still owns the session). Shared tmux over SSH passes the first two and fails the rest (no auth story, no preview, terminal-only, expert-only).

How this differs from "cloud agents" and "agent fleets"

Through mid-2026 the vendor landscape largely upgraded single-player, not multiplayer. Cloud agents (Cursor's renamed background agents, and their equivalents) moved execution off the laptop onto a VM, which fixes lifetime and parallelism but still returns work as a diff. Fleet platforms and command-center surfaces (Warp Oz, GitHub Agent HQ) added team-level launching, run lists, and audit trails: management of many runs, with run links that are views of the work rather than doors into it. All of that is progress, and none of it makes the session itself a shared place.

Then the word itself started migrating into vendor copy. In July 2026 Amp shipped "multiplayer orbs": teammates in a workspace can join a thread, message the agent, and share the orb's terminal while a time-boxed multiplayer mode lasts. The same month Conductor began early-access multiplayer for Conductor Cloud (changelog 0.77.0, July 2026), and its documentation now has a page titled simply "Multiplayer": presence dots show who is active, teammates follow a workspace, shared chats update live for everyone, and a workspace link opens for any member of the organization. Superconductor rebranded its homepage around "the multiplayer workspace for your team and coding agents", and HumanLayer now calls itself a "multiplayer control plane". In August 2026 Salesforce launched Slack Code with the stated goal of making AI software development multiplayer, and Mosaic (YC Summer 2026) describes its mission as "defining the frontier of multiplayer AI" (all as of September 2026, from each vendor's own site or press release). The category this page defines is becoming the market's direction; the differences that matter now are how much of the session is shared (a thread, a workspace, an editor buffer, a chat channel around the run, a synced session history), for how long, and on whose infrastructure it runs.

The multiplayer map: who does what (September 2026)

The category label gets used loosely, so here is the field measured against the definition above: is the live session a shared place the team enters? Statuses and models below are as of September 2026, from each product's public site.

The reading of that table is short: plenty of tools run many agents, a few share views of runs, and a growing handful now share some slice of the work (a thread on an expiring timer, a cloud workspace, an editor buffer, a chat channel around the run, a synced session history). The number built so that the whole working session (terminal, editor, and the running app) is the team's shared place, on infrastructure you control, is still very small. That is the model this page defines, and it is the model AQ ships today. For the workflow side, start with sharing a live agent session, running agents in parallel, team workflows for coding agents, and rolling out coding agents to your team; for the vocabulary, see agent orchestration, background vs cloud agents, and harness of harnesses, the architecture this page's model implies.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. Every task gets an isolated git worktree, agents run as real CLIs in persistent sessions, teammates enter the same workspace live, previews carry pinned comments that become prompts, and work flows in from Linear and out through pull requests, with agent execution on VMs you bring if you want full custody. The pattern described on this page is the product's thesis: we named the category because we built the thing. If your team wants agents to be a team sport instead of a pile of unreviewed diffs, this is the place to start.