What are multiplayer agents?

Published August 15, 2026 · by the AQ team

Multiplayer agents are AI agents that multiple people work with in one shared, live session: everyone present sees the same agent, the same context, and the same output at the same moment, and more than one person can direct the work. The term contrasts with the single-player default, where each person prompts an agent in a private chat, terminal, or editor that nobody else can see or steer. It is not a synonym for multi-agent systems: a multi-agent system means many agents coordinating with each other, while multiplayer means many humans sharing agents. One scales the machine side of the work; the other scales the human side.

The definition, unpacked

Calling an agent setup multiplayer implies three properties at once, and dropping any of them collapses the claim:

• Shared presence. Two or more people are in the same session at the same time, seeing the same live state. A transcript someone pastes into Slack afterward is documentation, not presence.
• Shared context. The agent's working context (the conversation, the files, the running processes) is one thing everyone references, rather than a private thread per person that each human summarizes for the others.
• Shared control. More than one person can prompt, interrupt, or redirect the agent. Products differ on the mechanics (free-for-all input, explicit handoff, request-and-approve), but if exactly one person can ever steer, the session is single-player with spectators.

A fourth property follows in practice: the session has to live somewhere neutral. If the agent runs on one participant's laptop, presence and control end when that laptop sleeps. Most working implementations therefore put the session on a server or VM and treat every participant, including the person who started it, as a client.

Multiplayer agents vs multi-agent systems

The two terms get conflated constantly because both involve "more than one." The axis of multiplication is the whole difference:

The two compose rather than compete: a team can share a session in which an orchestrator fans work out to sub-agents. See agent orchestration for the machine-side vocabulary. In research contexts the collision is even older: game AI literature has long used "multiplayer" for agents that play multiplayer games, which is a third meaning entirely and rarely what a software team searching the term wants.

Where the word came from

The vocabulary is borrowed from collaborative software, which borrowed it from games. Google Docs and later Figma made "multiplayer" the standard shorthand for many people editing one artifact live, with visible cursors and no merge step. Applying it to agents extends the same idea from a document to a working AI session.

By 2026 the term had hardened into investor vocabulary. Y Combinator's Requests for Startups asks for multiplayer AI, arguing that the defining work tools of the last two decades won by going multiplayer while working with AI is still largely single-player. Andreessen Horowitz's Big Ideas 2026 makes the same call from the agent side: that 2026 "unlocks multiplayer mode" because real work is inherently multi-party. Both are, as of August 2026, statements of demand rather than descriptions of shipped products, which is exactly what makes the term worth defining precisely.

What exists today (August 2026)

Working examples cluster by how much of the session is actually shared:

• Shared assistant conversations. OpenAI rolled out group chats in ChatGPT in November 2025: one conversation joined by up to 20 people, with the assistant deciding when to respond. This is multiplayer in the chat sense: shared presence and context, with control limited to taking turns at the prompt.
• Shared editing surfaces. Zed's real-time collaboration lets humans and agents work in the same live buffers, making the editor itself the shared session.
• Shared agent workspaces. In the coding-agent space, Superconductor describes itself on its own site as "the multiplayer workspace for your team and coding agents," running shared sessions in its cloud, and AQ runs joinable live agent workspaces on infrastructure the team controls (as of August 2026; see AQ vs Superconductor for the differences).
• Demand outrunning supply. The most widely used coding agents remain single-player: Claude Code's session sharing produces read-only views, and real-time multi-user sessions sit in open feature requests on its tracker as of August 2026.

The single-player status quo is measurable. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Agent output is exploding while the humans around each agent stay siloed, which is the gap multiplayer agents exist to close (see the self-review problem).

What multiplayer agents are not

• Not a multi-agent system. Ten coordinating agents with one human watching is sophisticated single-player.
• Not screen sharing. Streaming your session over a video call gives teammates presence without context or control; they cannot scroll, inspect, or type, and everything ends with the call.
• Not a shared account. Logging several people into one agent account destroys the properties that make collaboration governable: attribution of who did what, per-person permissions, and per-person billing. Multiplayer implementations keep individual identity inside the shared session.
• Not a view link. Read-only links and session replays are useful artifacts, but observation without the ability to act is an audience, not a player.

Multiplayer coding agents: the most developed case

Software teams are where the multiplayer pattern has gone furthest, because the ingredients already exist there: agents that do real work for hours (see background vs cloud agents), teams that already review each other's output, and a painful status quo of unreviewed diffs. Multiplayer coding agents are the coding-specific instance of this page's definition: agents whose working sessions are shared live places a team can enter together, watching the same terminal, steering the same run, and reviewing the same preview, instead of receiving the work as a finished diff. That page maps which tools meet the bar and which share only views of runs.

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. Against this page's three tests: presence means teammates open the same workspace and watch the same live session, streamed from persistent tmux sessions on the team's VM, so it survives a closed laptop and resumes from any device. Context means the shared workspace holds the agent CLI (Claude Code, Codex, Cursor Agent, Kimi, Grok, or a plain shell), an isolated git worktree per workspace, and a live preview of the running app with shareable links that work without an account for viewing. Control means typing into someone else's terminal is delegated, not free-for-all: the owner approves a control request in one click and keeps their own input, and visibility stays owner-managed (team-visible, or private and shared with specific people). Identity stays individual: each engineer signs into the CLIs with their own accounts, and AQ never marks up model usage. The Free plan is a personal sandbox for one person on a private machine AQ creates, with nothing to install and no time limit; the Team plan is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, with the rate locked for your first 12 months.