What to gate — and what to leave alone

Lesson 2 of 5 in Human-in-the-Loop: Designing the Human Back In.

Three flags mark an action as gate-worthy, and they compound:

Irreversible. If a wrong action can be cheaply undone, monitoring can catch it after the fact; if it can’t, the gate is your only chance. Sent emails, wire transfers, dropped tables, published posts — there is no undo, so judgment has to arrive before the act.

External-facing. Anything that leaves your boundary — messages to customers, API writes to other companies’ systems, public posts — lands where you can’t patch it and carries your name. Externality also feeds the lethal trifecta: an agent that can communicate outward is an agent that can exfiltrate, which is a security reason to gate quite apart from the embarrassment reason.

High-value. Money above a threshold, production data, credentials, legal commitments. Value is your organization’s call — the point is to make the threshold explicit (gate transfers over $1,000, ungate below) so the gate is a policy, not a vibe.

The harder discipline is what not to gate. Every gate you add spends a scarce resource: the reviewer’s attention. Gate the read-only queries, the branch commits, the retries, and something predictable happens — approval requests arrive faster than judgment can, the reviewer’s deny rate collapses toward zero, and the click becomes a reflex. Human-factors research has a name for this: automation complacency — sustained exposure to a mostly-correct automated system erodes the monitoring it depends on. You met its sibling, automation bias, in foundations; complacency is what a badly designed gate manufactures.

The perverse result: a system with fifty gates is often less safe than a system with five, because the five get real reviews and the fifty get rubber stamps. The gate that protects the wire transfer is only as good as the reviewer’s habit — and the forty-five pointless gates trained that habit to be “approve”.

Gate this action?

Interactive decision tree — outcomes:

  • Don’t gate it — remove the capability

    A gate is a decision point, not a prohibition. If the answer is always no, scope the tool so the action is impossible — that is least privilege, and it never gets tired or rushed the way a reviewer does.

  • Approve-before gate

    Irreversible or high-stakes, and reviewable: pause the run, show the literal tool call, and wait. Budget this gate carefully — every approve-before gate you add dilutes the attention available for the others.

  • Co-draft — hand the action itself to the human

    When the risk lives in tone, framing, or judgment rather than parameters, an approve/deny click is the wrong interface. Let the agent draft; the human edits and performs the action as their own.

  • Notify-after

    Reversible and contained: let it run, log it, surface it in a digest a named person actually reads. Pair with monitoring — notify-after without a reader is just autonomy with paperwork.

  • No gate — monitor in aggregate

    Reversible, internal, high-volume: gating this manufactures automation complacency. Watch rates and anomalies in your traces instead, and keep a kill switch for the whole class of actions.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.