Approval gates: the human checkpoint that earns its keep
A pause in the agent's run, placed exactly where the blast radius warrants a human. Scoped by risk, routed to the right approver, resumable hours later, and written to an immutable record.
- Gate by blast radius, not by step
- Durable suspend-and-resume
- Approve, reject, or edit-in-place
- Every decision logged to lineage
An approval gate is a deliberate latency tradeoff
You are choosing to spend human seconds to bound machine risk. The engineering question is never "should there be oversight" — it's where the pause goes, who it goes to, and what it costs.
The naive failure mode is gating by step: pause after every tool call so a person can rubber-stamp it. That destroys the economics of automation and trains your approvers to click "yes" without reading. The opposite failure — full autonomy on irreversible actions — is how an agent wires money to the wrong account or emails the entire customer list.
The right model treats a gate as a function of consequence. Reversible, cheap, internal actions run autonomously. Irreversible, expensive, or externally-visible actions stop and wait. The gate is the seam between those two regimes, and getting the seam in the right place is most of the work.
What a production gate is actually made of
A gate is not an if-statement. It's four cooperating pieces — and each one is a place a naive implementation breaks.
A risk classifier
Evaluates the structured action and its parameters against policy — amount, recipient, reversibility, audience — to decide gate-or-go before anything executes.
An approver router
Sends the right gate to the right person with enough context to decide in seconds, and escalates on timeout instead of stalling forever.
A durable suspend
Checkpoints the full run context so the agent survives a multi-day wait and resumes in-place — no memory held, no re-execution.
An enforcement point
Lives in the action layer, so a gated tool call physically cannot fire without a valid approval token. Policy, not prompt.
An immutable record
Captures the proposed action, the reasoning, the approver, the decision, and any edits — the spine of your audit trail.
A policy surface
Lets compliance and ops change thresholds and routing without redeploying the agent. Governance lives outside the model.
How one gated action moves through the system
From the agent proposing an action to the work completing — with a human in the seam.
Propose
The agent emits a structured action. The classifier scores it against risk policy and decides this one needs a human.
Suspend
The run checkpoints durably and the action is routed to the right approver with full context attached.
Decide
The approver approves, rejects with a reason, or edits the parameters and approves the corrected version.
Resume
The run wakes from the checkpoint, executes the approved action, and writes the whole exchange to lineage.
The hard part is what happens when nobody answers
A gate that only handles the happy path is a liability. The approver is on PTO. The Slack message scrolls off. The action is time-sensitive and the window closes. A real implementation treats the timeout as a designed state, not an accident.
We wire escalation chains, fallback approvers, and explicit expiry policies — so a pending gate resolves to a defined outcome (escalate, auto-reject, or hold) rather than leaving a run stuck and a workflow silently broken. That dead-letter behavior is where exception handling and approval gates meet.
- Escalation chains with fallback approvers
- Explicit expiry: escalate, auto-reject, or hold
- Pending gates surfaced, never silently stuck
- Timeouts treated as a designed state
A confirmation dialog vs. an approval gate
They look similar in a demo. They are not the same engineering decision.
| A confirm() dialog | An approval gate | |
|---|---|---|
| Scope | Fires on every flagged step | Fires by risk and blast radius |
| State | Blocks the running process | Suspends durably, resumes in-place |
| Routing | Whoever is at the screen | Routed and escalated to the right approver |
| Response | Yes / no | Approve, reject-with-reason, or edit |
| Enforcement | UI convention | Action-layer token, can't be bypassed |
| Record | Maybe a log line | Immutable lineage with reasoning |
Frequently asked questions
Won't approval gates make the agent so slow it's not worth automating?
Only if you gate the wrong things. The point of a gate is to spend a human's attention where the blast radius justifies it. A well-designed system gates maybe 5–15% of actions — the irreversible, expensive, or externally-visible ones — and runs the rest at machine speed. If you're approving everything, your risk thresholds are miscalibrated, not your architecture.
What happens to the agent's state while it waits for a human?
The run suspends, not the process. We checkpoint the full execution context — inputs, tool outputs, the proposed action, and the reasoning behind it — and persist it durably (Temporal, a queue, or a database, depending on the stack). When the approver responds hours or days later, the agent resumes from exactly where it paused. Nothing is held in memory or re-run from scratch.
Can an approver edit the proposed action, or is it just approve/reject?
Both, plus a third path. We model gates as approve, reject-with-reason, or edit-and-approve. Edits and rejection reasons are first-class signals: they flow back into the lineage record and become the cleanest training data you have for tightening prompts and raising the autonomy threshold over time.
How do you stop an agent from learning to phrase actions so they slip past the gate?
Gates are enforced in the action layer, not the prompt — the agent literally cannot execute a gated tool call without an approval token. The classifier that decides what's gated runs on the structured action and its parameters, not the model's narration, so there's no surface for the agent to talk its way around. Risk thresholds are policy, evaluated outside the model.
Related architecture decisions
Approval gates are one node in a governed agent. Here's the rest of the graph.
Bring the action you're afraid to automate.
We'll map where the gate goes, who it routes to, and what it costs you in latency — in one working session.