Shared AI sessions arrived before anyone agreed on how to run them. This playbook is for platform, data, and engineering leaders who already run agents in production, or who are about to. It argues that multiplayer AI is a control problem rather than a model problem, and it sets out the six layers between a shared chat session and a system you can put in front of a business.

## What multiplayer AI means here

Multiplayer AI is the point at which an AI session stops being one person and one model. Two people share a session. Their agents read the same context. A third agent acts on what the first two produced. The moment that happens, the interesting question stops being which model you use and becomes who is allowed to do what, to whose data, with whose approval, and what record survives afterwards.

We wrote this playbook because that question arrived in October and almost nobody had an answer ready. The launches were real and the capability is real. What was missing was the control layer.

## The six layers

The layers below are the ones we would build in order. Each one assumes the previous one exists, and skipping a layer is the most common reason a deployment stalls three months in.

![Six layers between a shared chat and a runnable system](/images/blog/multiplayer-ai-playbook-figure-1.png)

1. **Shared sessions.** More than one person, and their agents, working in one place.
2. **Visibility.** Being able to see what the agent did, in what order, and on whose behalf.
3. **Shared context.** Company knowledge the agent reads, and is allowed to read.
4. **Agent identity.** An agent that acts for a person needs its own credentials rather than a copy of theirs.
5. **Approval and provenance.** A decision recorded before an action, with the reason attached.
6. **Change control.** The same treatment for rules and memory that you already give production code.

## Why shared context is a write problem

Most teams approach shared context as a retrieval problem. They ask how the agent will find the right document. That is the easy half and it is largely solved.

The hard half is the write. Once two people and their agents share one memory store, the store becomes a contested surface. One agent learns something true and another learns something that contradicts it. Both are plausible. Both persist. The next reader cannot tell which is current.

![Shared memory is a write-governance problem](/images/blog/multiplayer-ai-playbook-figure-3.png)

We think the write is where governance belongs, for three reasons:

- A read is cheap and reversible. A bad read produces a bad answer you can catch.
- A write is expensive and sticky. A bad write persists and gets read by everything downstream.
- A shared store is where one person's mistake becomes everyone's default.

So the question to ask a vendor is not how well the system retrieves. It is who may write, who confirms the write, and how a wrong write is removed.

## Where approval belongs

The second argument in this playbook is about placement. Most teams put approval after the action, on the grounds that you cannot review everything and you should only gate the dangerous things.

We think that ordering protects the wrong asset. By the time an action is proposed, the agent has already read the context it will act on. If the context contained something it should not have seen, the damage is done before the approval lands.

![Where approval sits changes what you are protecting](/images/blog/multiplayer-ai-playbook-figure-2.png)

We would put approval before the read. That is a harder position to implement and it is the one we would defend, because it is the only ordering where the control acts before the exposure rather than after it.

## What we would install first

If a team asked us to sequence this work, we would start with three controls and leave the rest until the first three are routine.

1. **An approval record for every write to shared context.** Not a dashboard. A record with a person attached.
2. **A separate identity for every agent.** Scoped, short-lived, and revocable without touching the person it acts for.
3. **A provenance field on every stored item.** Where it came from, when, and who confirmed it.

## How the market moved

October produced a run of launches from collaboration and platform vendors, each adding some form of shared context. We treat those as signals rather than as products to evaluate, and the signal is consistent: the category formed faster than the controls around it.

| Layer | What shipped in October | What was still missing |
|---|---|---|
| Shared sessions | Widely available | Per-session access records |
| Shared context | Several launches | Write governance |
| Agent identity | Partial | Scoped, revocable credentials |
| Approval | Rare | Approval before the read |
| Provenance | Rare | A field on the stored item |
| Change control | Almost absent | Diffs and review for memory |

## Eighteen questions for the vendor meeting

A demo shows a shared session working. A deployment needs answers to questions the demo does not provoke. We keep eighteen and ask the first five in every meeting:

- When two agents write a conflicting fact, what decides which one wins?
- Can an agent act under a credential that is narrower than the person's?
- Is the approval recorded before the read or after the action?
- Can you show me the record of who approved a specific change, and when?
- If a person leaves, what happens to the context their agent contributed?

## Who this is for

This playbook is written for the person who will answer for the system, not the person who will demo it. That is usually a platform lead, a data lead, or an engineering lead who has already been asked "can we turn this on for the team" and wants a defensible answer rather than a fast one.

## Where this fits

The companion document to this playbook is a working assessment that scores an existing estate across four stages of context readiness. Where this playbook argues for a control model, the assessment tells you which stage you are actually at. We would read the playbook first and fill in the assessment second.

## Sources and further reading

The specifications below are the ones we treat as settled, and the ones we would hand a platform team starting this work.

- The [Model Context Protocol specification](https://modelcontextprotocol.io/specification) is the closest thing to a standard for how an agent reaches a data source.
- [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/) describe the shape of a trace, which is what makes an agent action auditable.
- [OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693) is how one identity is exchanged for another with narrower rights.
- [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) is the zero trust model we borrow for treating every agent action as untrusted.
- [Decentralized Identifiers](https://www.w3.org/TR/did-core/) and the [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) matter if agent identity must outlive a vendor.
- The [OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) lists the failure modes we see most in review.
- [SLSA build levels](https://slsa.dev/spec/v1.0/levels) and [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final) cover provenance for the artifacts an agent runs.
- The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is the vocabulary we use when a risk register needs a citation.

Download the full playbook below for the complete layer model, the enterprise context checklist, and the order we would sequence the work in.