Pick a Mode and Record What the AI Workforce Holds
Multi-Player Mode
Companion to You Are Not the Warfighter · Updated 2026-09-29
Use this when a Warwright effort starts or grows. Record its mode, what its AI Workforce holds, what stays out of it, and who reviews its work. Worked in “Start With One Builder, and Add Builders Only When One Can’t Do the Job.”
First, pick the mode from the modes table below.
The three modes: what each can own, its characteristic failure, and its rule.
| Mode | Who, and what AI Workforce | Enough to own | Failure to watch | Rule |
|---|---|---|---|---|
| Single-player | One Warwright with one AI Workforce | A small, bounded piece: a plug-in, a staff section’s app, a configuration and its build record, a test card set, a parts log | Nobody reviews the builder’s judgment, and the knowledge rotates out with one person | Ships only inside a team or with a named reviewer; its build record passes Sustainment Tail Test question 2 first |
| Team | About 4 to 12 people, mostly warfighters, sharing one AI Workforce | A lane III or IV system class, end to end | The shared AI Workforce quietly becomes one member’s | The shared AI Workforce holds what each member knows, so a rotation doesn’t erase it |
| Multi-team | Several teams, each with its own AI Workforce, federated through shared specifications, interfaces, a registry, and a coordinating layer | A family of systems across a division or a fleet | The coordinating layer turns back into the old chain | Share interfaces and evidence. Never share one approval queue. |
Then fill in the one-page selector for the team.
The Multi-Player Mode selector for one team.
| Field | What to write | Entry |
|---|---|---|
| The team | Name, charter date, members, and how many of them fight with the system | |
| Its mode | Single-player, team, or multi-team, and what it owns in that mode | |
| Specification | The SpecKit: the written specification of what the team builds and why, and where it’s versioned | |
| Harness | The build and test environment, and the platform it deploys to (with that platform’s authorization) | |
| Agents | Which AI agents draft, build, or test, and what each one may touch | |
| Skills | The team’s methods written as skills (build steps, test cards, brief drafting), with version and owner | |
| MCP connections | Each Model Context Protocol connection, the data it reaches, and who approved it | |
| What stays out of it | Anything classified, controlled, or not publicly releasable; any tool the organization hasn’t approved; every decision that belongs to a person (authority, lanes, gates, rights clauses, requirements) | |
| Its reviewer | The named person or team who reviews the work before anyone relies on it (for multi-team mode, the other teams, with the coordinating layer reconciling and never deciding) | |
| Its failure to watch | The failure from the modes table for this mode, and the date someone last checked for it |
In every mode, the evidence comes from D0 or D1, and the build passes the same gates. The mode changes only what the team can own.