What the control plane is
The workbench is everything you look at. The control plane is the part that decides what you look at. It is off by default, per Project, and nothing in it can type, approve, or spawn.
The argument, in one paragraph
Every other account of what an agent did is the transcript, which is the agent's own report of itself. swe-mux owns the pseudoterminal, so it can record what actually happened at the boundary where it happened: content hashes computed when a tool writes rather than by reading the file back afterwards, parsed test outcomes, git tree hashes, write-then-read lineage. Everything above reads that substrate.
The layers, cheapest first
- Deterministic factsCaptured at the tool boundary. No model, no cost per session, and no way for it to be wrong about whether a file was written.
- Model-free detectorsLoops and stalls, claims declared but not verified, documentation debt, and provenance gaps. They read the facts and produce findings. No model runs, so they cost nothing per session and cannot hallucinate a finding.
- Attention rankingRanked items with a hard daily interrupt budget, four a day by default. Incidents merge rather than repeat, demotion rules are mined from what you have dismissed and expire on their own, and the count of what was suppressed is always shown rather than hidden.
- Model-backed observersThe only layer that spends money. Each one watches a run and reports, each is gated by a per-Project opt-in and an install-wide ceiling, and each carries its own budget.
The refusal that makes the rest safe
An observer can never type, approve, spawn, execute a script, or change a Project. That is structural rather than a policy setting - there is no code path from an observer to an action, so there is no configuration that would grant one.
The consequence is that the control plane cannot rescue a stuck agent, and is not trying to. It tells you which one to go and look at.
The inverse arrow: what agents read back
A per-session MCP server lets an agent pull from the control plane rather than an orchestrator pushing commands down to it: sibling session status, prior resolutions, dead ends already hit, commit provenance, Project notes, the scan timeline.
Its writes are bounded to four things, and each one ends at a human by default: staging a message into another session's queue, drafting a spawn request for someone to approve, arming a watch on a session it is waiting for, and interrupting or ending a session behind a per-Project grant. It starts nothing.
Turning it on
- Open the Automation dashboard and its Policy tab. That is the one editor that can turn an automation off in either scope, which is what keeps every other gate additive-only.
- Enable the install-wide ceiling for the automations you want available at all.
- Enable them per Project, on the same matrix. A Project with no opt-in runs nothing regardless of the ceiling.
- Set budgets under the Policy tab's Limits and budgets disclosure. Settings, Automation shows status and links here rather than holding a second copy of the controls.
The deterministic half - facts, detectors, provenance - has no model cost and is worth having on well before the model-backed half. Automation and alerts covers the observers, and Git covers provenance.
What it deliberately does not do
- It never actuates. No typing, no approving, no spawning, no killing.
- It never kills a process on suspicion. Hung processes are surfaced, not terminated.
- It sends nothing to a service this project operates, because there is no such service. Model-backed observers call the endpoint you configured, with your key.
- It fails closed. An observer that cannot run produces no finding rather than a guess.