An approval gate is a pause built into an AI agent's execution path: before the agent performs certain actions, it stops, shows a person exactly what it is about to do, and waits for a yes. Done well, gates are almost invisible — the agent runs freely on routine work and only interrupts a human when an action is expensive, irreversible, or aimed outside the system. Done badly, they are either a rubber stamp that approves everything or a bottleneck that teaches people to switch the agent off. This tutorial builds a gate that lands in the middle: sorted by consequence, specific about what is being approved, and closed by default when nobody answers.
Step 1: List every action the agent can take¶
You cannot gate an action you have not named. Start with the agent's tool list and write down every distinct thing it can do in the world: read a record, write a record, send a message, move money, change a permission, delete something, call an external API, publish content. For each action, note the target it acts on and whether the effect can be undone. This inventory is the raw material for the whole design, and it usually surprises the team that wrote the agent — tools accumulate, and yesterday's harmless helper can become today's write path.
Step 2: Sort actions by consequence¶
Gate by what an action can cost, not by how the agent happens to call it. Three questions sort almost any action:
- Can it be reversed? Editing a draft can. Sending an email, deleting a record, or paying an invoice cannot — or only with apologies and manual work.
- Does it leave the system? Anything a customer, a regulator, or another company can see carries more weight than an internal note.
- What is the worst plausible cost? A wrong summary costs minutes. A wrong payment, a wrong permission grant, or a wrong deletion can cost money, data, or trust.
Actions that are reversible, internal, and cheap belong in the lowest tier. Actions that are irreversible, external, or expensive belong behind a gate. Actions your team would never accept — an agent changing its own permissions, for example — belong on a deny list, not behind a gate at all. A gate is for judgement calls, not for things that should never happen.
Step 3: Assign each action a tier¶
A workable scheme has four tiers:
- Run freely. Reads, lookups, drafts, and other reversible internal work. The agent proceeds; the action is logged like everything else.
- Run, then notify. Low-risk writes the team wants visibility on — a summary filed, a ticket created. The agent proceeds and posts a notice a human can review after the fact.
- Approve first. The gated tier. The agent prepares the action, presents it, and does nothing until a named person approves the exact request.
- Never. Hard-denied regardless of who asks. No approval can unlock these; changing the list is a policy change, not an in-the-moment decision.
Thresholds can sharpen a tier: an action might run freely under a stated value and require approval above it. Write the threshold into the policy, not into the agent's prompt, so it cannot be talked around.
Step 4: Make the approval request decidable¶
An approver can only judge what they can see. A request that says "the agent wants to send an email" forces the approver to either blind-trust or go digging — both end in rubber stamps. Every gated request should carry, in one place:
- The exact action and its target: the recipient, the record, the amount.
- The exact payload: the full message text, the precise change, the file to be sent.
- Why the agent wants to do it: the task or plan it serves, in one or two sentences.
- The cost and the blast radius: spend, records touched, people affected.
- An expiry: how long the request stays valid before it must be re-issued.
A request in that shape looks like this:
{
"request_id": "appr-2026-10-25-014",
"agent": "agent:ops/summarizer",
"action": "email.send",
"target": "customer-success-list@example.com",
"payload_summary": "Weekly digest, 3 items, draft attached in full",
"reason": "Scheduled digest run for plan plan-2291",
"cost": "0 external spend; 1 outbound message",
"expires_at": "2026-10-25T18:00:00Z",
"status": "pending"
}The approval must bind to this exact payload. If the agent changes the message after approval, that is a new request. Approving a summary and executing something else is the failure mode the gate exists to prevent.
Step 5: Fail closed when nobody answers¶
Decide, in advance and in writing, what a timeout means. For gated actions the safe default is: silence means no. The request expires, the action does not run, and the expiry is logged like any other outcome. The tempting alternatives — auto-approve after an hour, or let the agent retry until someone clicks — quietly convert the gate into a delay. If some class of action genuinely must proceed unattended, move it to the notify tier deliberately; do not let a timeout move it for you.
Step 6: Record every decision¶
Approvals and denials are both evidence. Log the request, who decided, when, the decision, and any reason given. Denials matter as much as approvals: a pattern of denials is how you learn a tier is mis-set or an agent is mis-scoped. Store the record outside the agent's own write access — an agent that can edit its approval history has no approval history, only a story. This record is the seed of the audit trail covered in our companion guide to building an agent audit trail.
Step 7: Keep gates few enough to stay real¶
A gate that fires forty times a day will be approved forty times a day, thoughtfully zero times. Protect the approver's attention like the control it is:
- Batch the routine. Recurring, identical, low-variation actions can be covered by a standing approval with a narrow scope and a short expiry — reviewed on a schedule, not clicked per run.
- Route by ownership. Send each request to the person who owns the target system or budget, not to a shared queue everyone assumes someone else is watching.
- Review the tiers monthly. Actions that are always approved unchanged are candidates for the notify tier; actions that are often denied belong in a narrower scope or on the deny list.
The mistakes that kill gates¶
Three patterns undo approval workflows in practice. First, the gate sits outside the execution path — the agent asks for approval in one tool and executes in another, so a "no" is advisory. The check must live in the dispatch path itself, where the action cannot proceed without an approved request on file. Second, the request hides the payload, so the human approves a description and the agent executes a document. Third, the gate approves a category ("sending email is fine") instead of an instance, which is just the notify tier with extra clicks. If your gate has any of the three, fix the plumbing before adding more tiers.
Start small: inventory the actions, gate only the irreversible ones, make each request fully visible, expire on silence, and log everything. That is a gate a team can actually run — and one that still means something the hundredth time it fires.