PTN—31
Approval gates
Pause before consequential actions and present a reviewable proposal the person must explicitly approve or reject.
An approval gate is the moment an agent stops acting and starts asking. Before the AI sends the email, merges the branch, spends the money, or deletes the file, it presents exactly what it intends to do and waits. This is not a confirmation dialog bolted onto automation — it is the contract that makes automation acceptable in the first place. People delegate more readily when they know the system will surface the irreversible moments instead of blowing through them.
The gate earns its keep through legibility. A good approval card shows the full diff, the complete recipient list, the actual command — not a summary of it. The person is signing off on a specific change, and the interface must let them audit it in seconds. If reviewing the proposal takes longer than doing the task by hand, the gate has failed and people will either rubber-stamp it or abandon the agent.
Gates should be proportional to stakes. Reading a file needs no gate; running a destructive shell command always does. The best systems let people widen the aperture over time — “allow this command for the rest of the session” — so approval friction decays exactly where trust has been earned and nowhere else.
Gates became load-bearing the moment AI crossed from generating text to taking actions — the pattern is inherited from deploy approvals and code review, but agents forced it to operate at conversational tempo, dozens of times an hour. That tempo is the tradeoff: every gate spends a slice of the person’s attention, and attention spent on trivial approvals is stolen from the one that matters. Mature systems treat their approval logs as a design instrument — Claude Code’s per-command standing permissions exist because watching people approve “npm test” forty times is a finding, not a workflow. The gate that never fires on earned trust is the gate people keep respecting.
Anatomy
Assistant · proposed action
An approval card: the agent proposes a specific action, exposes the full payload, and blocks until the person decides.
- 1Action summary. One plain-language line stating what will happen and to what — verb first, no euphemism.
- 2Full payload. The exact diff, command, or message body. Expandable, never truncated into unaccountability.
- 3Stakes indicator. A visual cue for severity — destructive actions look different from routine ones.
- 4Approve / reject controls. Explicit, non-default buttons. Rejection routes back into the conversation so the person can redirect, not just cancel.
- 5Scope expander. An optional “always allow this” affordance that converts a one-time approval into standing permission.
When to use
- Before any action that is irreversible or expensive: sending, deleting, publishing, paying.
- When the AI acts on external systems or other people, not just its own scratch space.
- When the person delegated a goal, not a step, and the plan needs a checkpoint.
- Early in a relationship with an agent, before autonomy has been earned.
Design considerations
- 01Show the exact artifact being approved — the real diff, the real recipients — never a paraphrase.
- 02Make rejection a steering input: route “no” back to the agent with an optional reason field.
- 03Differentiate destructive gates visually and never make the destructive option the default focus.
- 04Offer scoped standing approvals (“allow npm test this session”) so friction decays with trust.
- 05Keep the agent’s work queue visible behind the gate so people know what approving unblocks.
- 06Batch related low-stakes approvals into one review; never fire five modal gates in a row.
- 07Time out gracefully — an unanswered gate should pause the agent, not silently proceed.
Pitfalls
- ✕Gate fatigue: prompting for every trivial step trains people to click approve without reading — the gate becomes theater.
- ✕Summarized payloads: approving “update the config” when the actual diff touches twelve files destroys the contract the first time it bites.
- ✕Approve-only design: when rejection just kills the task instead of redirecting it, people approve bad plans because stopping costs too much.
- ✕Gates after the fact: asking permission for something the system already partially did is a confession, not a control.
In the wild
- Claude Code
- Requests permission before running shell commands or editing files, shows the exact command or diff, and lets people grant standing permission per tool or command pattern.
- GitHub Copilot
- Copilot coding agent opens its work as a pull request rather than pushing to the default branch — the PR review itself is the approval gate.
- ChatGPT
- Agent mode pauses and asks for confirmation before consequential steps like logging into sites or submitting forms during autonomous browsing.
- Cursor
- Agent mode surfaces terminal commands for approval before execution, with settings to auto-approve allowlisted commands.