Watch the gates

A complete brief does not make supervision optional; it makes it precise. The run proceeds in stages, and each stage carries a gate — a runnable check that either passes or fails. The supervisor does not read the agent's intermediate work line by line. The supervisor reads the gate. A stage whose gate passed proceeds to the next; a stage whose gate failed is where the human steps in.

That distinction is the whole move. Watching the keystrokes scales with the size of the change and tells the human little; watching the gates is constant work and tells the human exactly what holds and what does not. The brief named the gates in advance, so supervision is reading a result the brief already specified, not forming a fresh opinion mid-run. A passing gate is permission to continue; a failing gate is the signal to intervene.

An intervention is not always the human writing the fix. When a gate fails, the agent can address the finding itself and re-run the gate. The risk is a run that loops on the same failure indefinitely. So the retries are bounded. The agent remediates a finding up to a fixed maximum — three attempts — and if the gate still fails past three, the run escalates to the human. Supervision is bounded, not infinite: the agent owns the work within the bound; the human owns the escalation.

The bound is what keeps a stuck run from masquerading as progress. Without it, an agent can keep producing near-misses that each look like forward motion and never close the gate. With it, the third failure is the signal that this is no longer the agent's problem to solve. Move the attempt slider below from within the bound to past it, and watch ownership pass from the agent to the human at the boundary.

The Portal's F6.6 (LiveView) and F6.7 (real-time updates) rungs each ship through the same staged team: reconcile and brief, then build, then harden, then verify — with a gate between every stage. The F6.6 ship prompt names the mode and the reason supervision is gate-watching rather than parallel automation, verbatim: “Real Agent spawns + SendMessage coordination, Director-in-loop between stages — not a deterministic Workflow fan-out … so the value is in the gates, not in parallelism.” The run is sequential, with two human-grade decision points — the reconcile result and the final commit.

# f6.6.prompt.md / f6.7.prompt.md — the staged run, one gate per stage
#
  build   →  gate: mix compile --warnings-as-errors clean; the stories pass
  harden  →  gate: added test coverage green across the determinism loop
  verify  →  gate: the master-invariant grep is empty; the liveness check holds
#
# on a finding: remediate and re-run the gate, MAX 3 attempts; past three, escalate to the human.

When the verify stage returns a finding, the run neither stops at the human immediately nor loops forever. The agent runs a bounded remediate loop — address the finding, re-run the gate, up to a maximum of three attempts — and past three it escalates to the human. The escalation is the human's decision point; the remediation within the bound is the agent's work. That is supervision made concrete on the Portal: the human stands at each gate, and owns the run the moment the bound is crossed.

Supervision is staying in the loop at each gate of a multi-stage run: a passing stage proceeds, a failing stage is intervened on, and the agent's own retries are bounded so a stuck run escalates to the human. The supervisor reads the gate, not the keystrokes — and knows the one point, the crossed bound, at which the run becomes the human's to own. The next dive turns to the move that closes a run: reviewing the output against the spec's Definition of Done, not the agent's self-report.

Primary sources for supervising a coding agent against gates, and where the staged run this dive grounds on and the practice around it are defined in the course.