human gates

Syntax

a human approves the plan first
a human reviews before stopping
a human approves before <X>

What it does

Human gates are where a person enters an otherwise self-driving loop. There are five of them, each at a different moment: approve the plan before any acting (a human approves the plan first); review the result before the loop may stop (a human reviews before stopping); a hard blocking gate before a specific action or stage such as a deploy or a card charge (a human approves before <X>); the escape hatch when the loop gets stuck (when blocked: ask a human); and the per-run confirm that comes from the action policy (allow edits automatically, but ask me before …).

Reach for a gate wherever a mistake is expensive or irreversible — payments, migrations, deploys, provisioning, anything you cannot cheaply undo. A loop is fast precisely because it does not stop to ask; a gate deliberately trades that speed for a checkpoint, so spend gates where the blast radius justifies the pause and nowhere else. The plan gate catches a wrong approach before any tokens are spent acting on it; the review gate catches a green-but-wrong result before it ships; the blocking gate is the one that stops a genuinely dangerous single step. Gates compose with the automatic verification, not instead of it — done when still decides correctness, and the human judges the parts a predicate can't.

Example

a human approves the plan first        # before any work
a human reviews before stopping        # judge the result
a human approves before provisioning   # blocking stage gate
when blocked: ask a human              # unblock when stuck

A gate on a risky stage

stage "story: checkout submit":
  goal: order submits and payment is captured
  a human approves before charging the card   # blocks until approved
  done when "pnpm test checkout" passes

Common mistakes

• Gating everything. A gate on every cycle turns the loop back into manual work and defeats the point. Reserve gates for irreversible or high-cost actions; let the fast, checkable work run unattended.
• Confusing the gate with the check. a human reviews before stopping judges the result, but it does not replace done when — the loop still needs a machine check to know it is even a candidate to stop. Keep both.
• A blocking gate with no async posture. a human approves before <X> halts the run until someone answers. On an unattended or headless run that means it hangs — pair irreversible gates with mode: orchestrator (opens a PR) so the wait happens out of band.
• Relying on the goal instead of a gate. Prose in the goal like "be careful with payments" is not enforced. Only an explicit gate or ask me before … actually blocks the agent.

Related