Approval gate

How it works

An approval gate sits between the agent's decision to act and the tool call that carries it out. It is a control point, not a suggestion the model can talk itself past. When the agent proposes a call that matches a gated condition, the harness intercepts it before execution and does five things:

1. Match the pending tool call against a policy — by tool name, argument shape, cost, scope, or estimated blast radius.
2. Freeze the run and persist its state: the transcript, the pending call, its arguments, and enough context to resume without re-deriving anything.
3. Surface the request to a human with the specific action, its inputs, and why it was gated.
4. Wait for an explicit decision — approve, reject, or edit-then-approve — with no default-allow on timeout unless policy says so.
5. Resume from the saved state, executing the approved call (or feeding the rejection back to the loop) as if the pause never happened.

The gate is defined at the harness level, so it holds regardless of what the model reasons or how a prompt is phrased. Approval is a state transition the runtime enforces, not a behavior the model is asked to perform.

Why it matters in an agent harness

Agents are non-deterministic actors wired to real tools. Most calls are safe and should run unattended; a small set are consequential — sending an email, deploying, deleting rows, moving money, changing permissions. An approval gate lets you keep broad autonomy while reserving a human decision for exactly the calls where a wrong move is expensive or hard to undo.

Because the gate persists state and resumes cleanly, it doesn't cost you the run. The agent's context survives the pause, so you get oversight without restarting work or losing the trajectory that led there. That coupling — pause plus durable resume — is what separates a real gate from a blocking input() that discards everything on the way out.

Gates also produce an audit trail as a side effect. Every gated action carries who approved it, when, and against what arguments. That record is the difference between "the agent did something" and "this specific action was reviewed and authorized," which is what you actually need when something goes wrong.

Approval gate vs guardrail

Both constrain what an agent can do, but they resolve differently, and the difference drives your design.

Use a guardrail when the rule is knowable in advance and cheap to check on every call. Use an approval gate when the decision needs human judgment or accountability that you cannot fully encode. A mature harness runs both: guardrails handle the volume, gates catch the few actions worth a person's attention.

The Rifty take

We treat approval gates as a way to spend human attention precisely, not liberally. A gate on every action is theater — reviewers stop reading and rubber-stamp, and the control becomes noise. We optimize for a small, deliberate set of gates placed where an action is irreversible or its blast radius is large, and we accept slower throughput on those specific calls as the price of keeping them reviewable. A gate you can't resume from is worse than no gate at all, so durable state is non-negotiable.

Implementation checks

• Gate at the harness, not the prompt. If a well-phrased instruction can skip the gate, it isn't a gate.
• Persist enough to resume. Save the pending call, its arguments, and the surrounding context so approval doesn't cost you the run.
• Show the reviewer the real thing. Surface the exact action and arguments, not a paraphrase the model wrote about itself.
• Decide the timeout policy explicitly. Choose fail-closed (default-reject) or fail-open per gate; never let an unattended pause silently expire into an action.
• Guard against re-execution on resume. Pair the gate with idempotent tool calls so a retried or double-approved action doesn't fire twice.
• Keep the gated set small and consequence-weighted. Reserve gates for irreversible or high-blast-radius calls; let guardrails handle the routine volume so reviewers stay attentive.
• Log the decision, not just the action. Record who approved, when, and against which arguments — that record is the point when you need it later.

Frequently asked questions

How is an approval gate different from human-in-the-loop?

Human-in-the-loop is the broad posture of keeping a person in the control path. An approval gate is one concrete mechanism that implements it: a specific, wired-in checkpoint that pauses a run before a designated tool call and resumes from saved state once a human approves or rejects it.

When should I add an approval gate instead of a guardrail?

Add a gate when the decision needs human judgment or accountability you cannot fully encode, and the action is rare, expensive, or hard to undo. Use a guardrail when the rule is knowable in advance and cheap to check on every call. Mature harnesses run both together.

Does pausing for approval mean I lose the agent's progress?

Not if the gate is built correctly. A real approval gate persists the run's state — transcript, pending call, and context — before it pauses, then resumes deterministically from that saved point. If your implementation discards context on pause, it is a blocking prompt, not a durable gate.

What happens if no one responds to an approval request?

That depends on the timeout policy you set per gate. Fail-closed rejects the pending action after a deadline; fail-open eventually allows it. Choose deliberately: never let an unattended pause silently expire into either an executed action or a stalled run by default.

Can a clever prompt make an agent skip an approval gate?

It should not, if the gate lives in the harness rather than the prompt. A gate enforced by the runtime intercepts the tool call regardless of what the model reasons or how instructions are phrased. If wording can bypass it, you have a suggestion, not a gate.