Multiplayer AI: Definition, Distinctions, and Setup

Multiplayer AI is several people working with the same AI agents, in the same threads, against the same shared context and task history, with per-person identity, permissions, and review. It is the opposite of one person in a private chat session: the agents, the work, and the accountability belong to the team, not to whoever opened the window.

---

TL;DR:

• Multiplayer AI names the human axis: many people share one agent system. Multi-agent orchestration names the agent axis: many agents divide the work. They are different axes, and they combine.
• Multiplayer runs on shared context, one common store of memory, skills, and task history, while per-agent and per-person private state stays out of the shared space.
• Setup is six decisions: one shared deployment, the channels people already use, one identity per person, a written shared-versus-private boundary, human review on consequential actions, and per-person cost tracking.
• Day to day it needs identity, permissions, audit, budgets, approvals, conflict handling, and prompt-injection defenses.
• Agent Swarm covers these with documented capabilities, and this guide lists its current limits, including no UI to change a role after someone joins, just as plainly.

---

Table of Contents

• Multiplayer AI vs related concepts
• How to set up multiplayer AI
• Operating requirements
• How Agent Swarm supports multiplayer AI
• A real session
• Getting started
• Sources
• FAQ

Multiplayer AI vs related concepts

The term collides with several neighbors, and the cleanest way to keep them apart is to name the axis each one describes.

Concept	The axis it names	Relation to multiplayer AI
Multi-agent orchestration	Many agents dividing work	A different axis; multiplayer says how many humans share the system
Shared context	One common store agents read and write	The substrate multiplayer runs on
Private state	Per-agent or per-person scope	What must stay out of the shared space for multiplayer to be safe
Single-player assistants	One human, one private session	The default mode of most AI tools, and what multiplayer replaces for team work

Multi-agent orchestration answers the question of how many agents. Multiplayer AI answers the question of how many humans. A fleet of ten agents driven by one person in a private session is multi-agent but single-player. One agent shared by a whole team in a company channel is multiplayer but single-agent. Most working setups combine both: many people, many agents, one task system. The multi-agent orchestration guide covers the agent axis, and the orchestration patterns catalog lists the shapes it takes. When you evaluate tools, ask both questions separately; a product can be strong on one axis and weak on the other.

Shared context is the common store multiplayer depends on: team definitions, decisions, findings, and task history that every participant, human or agent, can read. Multiplayer does not work without it, because people who cannot see what the agents already did will re-ask, duplicate, or contradict. But shared context is the infrastructure, not the arrangement. Multiplayer adds people, identity, permissions, and review on top of it. The shared-context guide covers that layer, its risks, and its governance in depth, so this guide does not re-explain it.

Private state is the complement of shared context: each person's and each agent's own scope, which must stay out of the shared space. One person's draft, one agent's working notes, credentials, anything sensitive. Multiplayer fails quietly when private material leaks into the shared store, because nothing errors; the material is simply visible to everyone. Decide the boundary per fact type, not per tool.

Single-player assistants are the default shape of most AI tooling: one person, one private chat, one context that resets and that nobody else ever sees. That shape is fine for individual work and unusable for team work: no shared history, no attribution, no review, no cost accountability per person. Multiplayer AI is the upgrade path when the work is shared, and agentic workflow automation is what often runs underneath it.

Product marketing has started using the word as well. QM, for example, describes itself as a multiplayer agent harness. The term survives the marketing because it names a real axis: who shares the system.

How to set up multiplayer AI

Six decisions, in order.

1. Run one shared deployment. One instance of the agent system for the whole team, not one per person. The point is that every agent works from the same memory, skills, and task history, and that there is one place to audit. Per-person instances fragment both.

2. Meet people where requests arrive. People will not move to your tool. Let requests come in from Slack, Linear, GitHub, email, wherever work already lands, and let the agents come to the work. Each channel should create tasks in the same system, so a request made in a thread and a request made on a pull request end up in the same task graph.

3. Map each person to one identity. One registry entry per human, linking their handles across channels: the same person on Slack, Linear, GitHub, GitLab. Attribution, preferences, and budget then follow the person, not the channel. Without this, "who asked for this" and "who approved that" become unanswerable within a month.

4. Decide what is shared versus private, in writing. Before the first incident, not after. Team definitions, decisions, and findings belong in the shared scope. Personal drafts, agent working notes, and credentials do not. Write the boundary down and check new tooling against it.

5. Put human review on consequential actions. List the actions that cannot be undone: production deploys, customer-facing messages, deletions, payments. Route those through approval before they execute. Everything else can run, but the consequential list needs a human name on it.

6. Track cost per person. When several people share one system, the bill aggregates and becomes invisible. Set daily budgets per user, per agent, and for the whole deployment, and keep per-person cost visible on a dashboard, so the heaviest users can see their own footprint.

Operating requirements

Once it runs, multiplayer AI needs seven things to stay safe. Most single-player setups have none of them, which is why bolting a team onto a personal assistant fails.

Identity. Every request must carry who made it. Identity anchors permissions, personalization, and every audit question that starts with "who."

Permissions. Not everyone should be able to do everything. At minimum, separate privileged operations such as user management, posting to shared channels, and credential changes from ordinary requests, and hold the privileged ones to a smaller group.

Audit. Every allow and every deny of a privileged action gets logged with a timestamp and the identity behind it. Thirty days is a common floor; compliance teams will want more.

Budgets. Daily spend caps per user, per agent, and per deployment, enforced by the system rather than discovered when the invoice arrives.

Approvals. A mechanism that pauses work and asks a specific human, in the channel where they already work, with a timeout. Approval prompts that require people to open a separate tool do not get answered.

Conflict handling. Two people will steer the same running task in different directions. The system needs a defined behavior: steer in place, queue the second instruction, or surface the conflict to a human. It must never silently pick one.

Prompt-injection defenses on shared inputs. Anything that arrives from outside, a ticket body, a pull request, an email, can carry hostile instructions, and in a multiplayer setup one poisoned input reaches every participant. Treat inbound content as data, keep credentials out of any context agents can read, and require approval before agents act on instructions that originate from retrieved content.

How Agent Swarm supports multiplayer AI

Agent Swarm is an open-source system for multi-agent work, and its team collaboration docs describe its multiplayer model directly. The mapping below sticks to documented behavior.

• One shared deployment. One swarm is shared by the whole team. People reach it from Slack, Linear, GitHub, and other tools, and every agent works from the same memory, skills, and task history. Work a person starts, an agent delegates, or a schedule fires lands in one task graph anyone can inspect. The integrations catalog lists the channels.

• Identity. A user registry maps one person to many identities across Slack, Linear, GitHub, and GitLab. A requester profile, with role, notes, and communication preferences, is injected into the agent's prompt, so agents adapt to who is asking; the personalization guide describes the mechanism. On Slack, with thread steering on, a reply in the thread steers the running task instead of opening a new one (Slack integration docs).

• Shared versus private. Memory has two scopes: agent scope, readable by its owner and searchable by the lead agent, and swarm scope, readable by all agents. The /workspace/shared volume is mounted into every agent, /workspace/personal is per agent, and agent-fs is a shared drive that human members can be invited to.

• Permissions and audit. One lead agent holds the privileged verbs: user management, Slack posting, credential bindings. REST API calls made with user tokens are gated by role-based access control, with three primary roles: admin, requester and viewer. An audit log records every allow and deny decision, with thirty-day default retention. The security page covers the surrounding posture.

• Budgets. Daily USD budgets per swarm, per agent, and per user, with per-user cost visible on the dashboard as Cost by User.

• Approvals. Human oversight runs through request-human-input and through workflow human-in-the-loop nodes, which pause work and present a Slack button (workflows docs).

• Inbound filters. Slack traffic can be gated by an email-domain or user-ID allowlist, so the shared swarm is not open to whoever finds the bot.

• Secrets. Credentials are encrypted at rest with AES-256-GCM, injected at egress, and never shown to scripts, which keeps sensitive material out of the context every agent reads.

• Self-hosting. Agent Swarm is MIT-licensed and self-hosted via Docker Compose, so the shared deployment, its task graph, and its audit log stay on infrastructure you own. For anything beyond documented behavior, the documentation is the source of truth, and cloud-specific questions go to the contact listed there.

The current limits, stated plainly. The docs are honest about what is not built yet, and so is this guide. No UI changes roles after someone joins; PUT /api/users/{id}/roles does, from the operator key or a grant-all user. People who join without an assigned role start as admin. An invite carries the role sent with it: the dashboard form opens on admin, and a POST /api/invites call with no role defaults to requester. Named approvers are enforced, and among user tokens only the admin role answers, so a user below admin cannot respond even when listed. The shared operator key can always respond. SSO via oauth2-proxy in gate mode carries no per-user identity into the swarm. One swarm does not split into multi-tenant workspaces; run separate swarms per team instead. And there is no read privacy for personal asset keys, so do not treat a personal namespace as a secrecy boundary. If any of these is a hard requirement for you today, plan around it rather than assuming it away.

A real session

The engineering pull request example on our examples site is a redacted record of one real multiplayer session in our own swarm. A maintainer asked the swarm for a memory feature. The lead agent made the design call up front, that there would be no new memory source, and assigned the implementation to a coding worker. The worker implemented the feature and opened the pull request. A security-scanning bot flagged a finding on the diff, and the worker triaged it and pushed the fix. Then a human maintainer requested changes, the worker answered them, and the same human approved and merged the pull request. The swarm never merged its own work: every gate that could not be undone, the change request, the approval, and the merge, stayed in human hands. More redacted sessions, including a recurring research brief and a security-alert triage, are on the examples index.

Getting started

Self-host a swarm with Docker Compose, connect the channels your team already uses, and register each person once. Start with a small team, one shared project, and human review on anything irreversible, then widen from there. The Agent Swarm documentation walks through the setup.

Sources

• Team collaboration, Agent Swarm docs: one shared deployment, channels, identity, permissions, budgets, approvals, inbound filters.
• Personalization guide, Agent Swarm docs: the user registry and requester profiles, how agents adapt to who is asking.
• Workflows docs, Agent Swarm docs: human-in-the-loop nodes.
• Slack integration docs, Agent Swarm docs: thread steering and inbound allowlists.
• Engineering pull request example: the redacted real session excerpted above.

FAQ

What is multiplayer AI?

Multiplayer AI is several people working with the same AI agents, in the same threads, against the same shared context and task history, with per-person identity, permissions, and review. It contrasts with one person working in a private chat session. The defining properties are shared work and shared accountability, not the number of agents.

Is multiplayer AI the same as multi-agent orchestration?

No. Multi-agent orchestration describes many agents dividing work among themselves; multiplayer AI describes many humans sharing one agent system. They are different axes that combine well, and a mature setup is often multiplayer and multi-agent at once. A fleet of agents driven by one person alone is still single-player.

How is multiplayer AI different from shared context?

Shared context is the common store of memory, skills, and task history that participants read and write. Multiplayer AI is the whole working arrangement built on top of it: people, identities, permissions, approvals, budgets, and review. You can have shared context without multiplayer, but you cannot have multiplayer without shared context.

How do you keep one person's work private?

By deciding the shared-versus-private boundary per fact type and enforcing it with scopes. In Agent Swarm, memory is either agent-scoped, readable by its owner and searchable by the lead agent, or swarm-scoped, readable by all agents; /workspace/personal is per agent while /workspace/shared is mounted into every agent. Credentials should never live in any context an agent can read: they stay in the encrypted config store and are injected at egress.

Who can approve agent actions?

Among user tokens only the admin role holds approval.respond, so a user below admin cannot respond. The shared operator key can always respond and is not bound by the approvers list. When a request lists approvers, only a listed person can respond, an admin included. With no approvers listed, any person who holds that permission can respond. Slack sends a notification card whose button opens the dashboard, not an answer in Slack. The lead agent holds the privileged operations, such as user management and credential bindings, separately from ordinary requests.

Can multiplayer AI be self-hosted?

Yes, when the platform allows it. Agent Swarm is MIT-licensed and self-hosted via Docker Compose, so the shared deployment, its task graph, its audit log, and its budget settings run on infrastructure you own. Self-hosting also keeps the shared context under your own retention policy instead of a vendor's.