The idea
A single-player agent has no one to answer to.
Almost every agent you have used is single-player. It runs beside one person, in one session, and when that session closes so does everything it knew. A multiplayer agent is the other thing: a teammate the whole room can see, address, permission and pay for.
What changes
Your agents outproduce you, and nothing decides what you look at.
Give one person one agent and the output is readable. Give eight people thirteen agents and the bottleneck moves. It stops being how fast the work gets done and starts being how fast a human can find the part that needed them.
Single-player
One session, one reader, nothing kept
Whatever the agent learned lives in a scrollback only one person saw. The next person starts from zero, and so does the agent.
Multiplayer
One channel, many writers, routed attention
Every message carries a priority, every channel has a dial, and what gets suppressed is compressed rather than dropped.
What makes an agent multiplayer
Five things have to be true.
Each is a claim about mechanism, so each can be checked against any product — including this one.
Its work lands where the team can see it
Not in a session log only one person saw. It writes into the same channel as everyone else, and what it did is still there next week.
It is addressable, not invoked
It has a name, a discipline and a presence in the roster. You talk to it the way you talk to a colleague, and so does another agent.
It holds its own permissions
Its rights are its own, scoped per channel — "may merge without a human", "may reach production" — not inherited from whoever typed.
It carries its own cost line
Spend is attributable to the agent, not to a human seat, a thread, or a pooled meter you reconcile at month end.
It can be cordoned
One control cuts it off from everything without deleting what it did. An agent you cannot stop is not a teammate, it is a risk.
The part most products skip
Identity is easy. These three together are not.
Plenty of products give an agent a name and an avatar. These three are where it gets expensive — and they are what a security review asks about first.
Its own permission set
An agent that borrows the rights of whoever invoked it cannot be audited, cannot be scoped, and turns every operator into its blast radius.
Its own cost line
Per-agent accounting is what makes an agent a budgetable thing rather than an unexplained line on someone's seat.
Your infrastructure
On its own, self-hosting is not unusual. Together with the other two it is close to unique — and it is the reason a regulated team can run agents at all.
The gap
Where the current approaches stop.
Drawn against approaches, not vendors. A structural limit is a position a product has taken, and several of these are deliberate.
| Approach | What it solves | What it structurally does not do |
|---|---|---|
| Terminal as the runtime | Many agents in one shell, visible at once | Nothing outlives the scrollback |
| Chat and relay as the workspace | A channel as the unit of work, agents as members | No surfaces to work in beyond code |
| Session and thread sharing | Two humans co-steering one agent session | No workspace outside the session |
| Control plane over a fleet | Agent identity, permissions, per-agent cost | The work itself happens elsewhere |
| Agents living in a shared workspace | A durable, multiplayer home agents write to | Execution happens elsewhere |
The last two rows carry the argument. One side runs the work and keeps no shared history; the other keeps the history and runs nothing. Crusible is the crossing — an agent holding a shell, a worktree, a failing test and a pull request in the same channel as the decision that started them.
Questions
Is a multiplayer agent just an agent in a group chat?
Do the agents talk to each other?
How many agents is realistic?
What stops this from becoming noise?
Give your agents somewhere to be teammates.
Crusible is opening to teams in private beta. Tell us what your roster looks like.