Agent Approval Gates: How to Let AI Act Without Losing the Room

Every AI policy document contains the phrase "human in the loop". Ask where the loop is and you are shown a Slack channel the agent posts into. Nobody has to read it, nothing waits for a response, and the agent acts either way.

That is not a loop, it is a notification with good intentions. The interesting design work in agentic go-to-market is not the agent but the gate it passes through, and almost nobody builds one.

A gate is a mechanism, not an intention

A gate has four properties or it is not a gate. The action is blocked until the gate resolves. A named person or an automated check resolves it. The resolution is recorded. And something defined happens if nobody resolves it. Most arrangements fail on the first and the last: nothing is actually blocked, and the undefined default is "proceed".

Three gates, chosen by how expensive the action is to undo

Stop sorting agent actions by how clever they are. Sort by undo cost: how long a reversal takes, and who sees the mistake in the meantime.

Pull request review, for anything versioned. Copy, ad variants, sequence definitions, audience rules, scoring weights, routing tables, context files. The agent opens a branch, automated checks run before a person looks (every factual claim matched to the proof file, every link resolving, the tracking parameter present), and a human merges or closes. The reviewer sees a diff, the highest-signal review artifact, and the merge history is the audit log for free. It is the strongest gate available and the cheapest to run, which is why marketing from a repository makes agents safer rather than riskier.

A queue with a timer, for reversible actions. Pausing an ad set, adjusting a lead score, tagging a CRM record, shifting budget inside a stated band. The agent proposes, the item appears with its reasoning attached, and if nobody objects within a defined window it executes. The window is a policy decision, but it must exist and be visible on the item. The timer stops the queue silting up into a backlog everyone ignores. Two conditions make this honest: the action is reversible in under a minute, and the notification lands where a named person is accountable for reading it.

A hard block, for anything irreversible or externally visible. Sending a message to a real person, publishing a page, spending above a threshold, deleting or merging records. No timer, no default-proceed, no "the agent waited an hour". A named person acts, or it does not happen. The one exception is a pre-approved template sent inside a rate limit with a live stop switch: the template passed a gate, and the send only executes it. Novel text to a real recipient never qualifies.

The audit log is what makes a gate evidence

A gate you cannot reconstruct afterwards is a story you tell yourself. Every gated action writes one record: a correlation id, the agent identity and trigger, the inputs read by record id, the prompt version as a commit reference, the model identifier, the raw output, the payload actually applied, the value before the change, the approver by name, the decision with a reason code, and the result. Prompt and model version are the ones teams skip: last month's output came from a prompt that no longer exists, and a silent provider upgrade looks exactly like drift.

Run this check in ten minutes. Pick one action your agent took last week and reconstruct it from the log alone: which records it read, which prompt version produced the text, which model, who approved it, why, and what changed. Answer fewer than six and you have logging, not an audit trail.

Blast radius and budget caps

Gates control individual actions. Caps control what happens when a gate is wrong, which it will be.

Set limits per run and per day: maximum records modified, spend delta, messages per hour, and percentage change to any single value. An agent that can move a budget by 20% a day is a tool; one that can move it by 100% is an incident waiting for a trigger. Write the cap as a number and enforce it in code.

Put the money cap in two places: the agent refuses to exceed its own budget rule, and the platform carries a hard account-level ceiling underneath it. The agent's arithmetic is what you are guarding against, so it cannot be the only guard. And the stop switch is a flag read before every action, not a support request. One person halts every agent in under a minute, and someone has done it once in a drill.

Rollback has to be designed, not hoped for

For every action type, write the inverse before the agent may perform it. Reverting a merge restores the previous copy and redeploys. Restoring a budget needs the prior value, which is why the log records it. Unmerging two wrongly deduplicated records usually cannot be done at all. An action with no inverse belongs in the hard-block tier by definition, and that rule classifies most edge cases without argument.

Then test it. Once a quarter, reverse a real agent action end to end and time it. The rollback everyone assumes works is the one nobody has run, and it fails on a detail: a missing previous value, or an API that will not accept a backdated change.

Gates decay, and the decay is called approving

This failure happens quietly. The agent is good, the queue is long, the approver is busy, and approving becomes a reflex. Six weeks later everything is approved and nothing is read. You have the latency of a gate with none of the protection.

The signs are measurable: approval latency falling toward seconds, edit rate approaching zero, batches of forty items cleared in one click, rejections that have stopped appearing.

Three countermeasures, all cheap. Sample-audit one in twenty approved items with someone other than the original approver, and record the disagreement rate. Treat a 0% edit rate as a red flag, not a green one: no agent is that good, and a human who never edits is not reading. And make the approver the person who bears the consequence, the rep whose prospect gets the email, not a coordinator with no stake in it.

Then attach a threshold: if sampled disagreement crosses a stated number, the agent drops a tier and returns to drafting until it earns its way back. The Agent Handbook carries the version we use.

What gates cannot do

They do not make the agent correct. A gate catches actions that look wrong to a reviewer and does nothing about an agent that is confidently, plausibly and consistently wrong in a way that reads fine on the page. Only sampled outcome review catches that, and it catches it late. Nor do gates substitute for scope: an agent pointed at the wrong job produces well-approved waste.

And they cost attention. A queue nobody reads is worse than no queue, because it manufactures the appearance of control while removing the vigilance of knowing there is none. If you cannot staff the reading, reduce what the agent may propose rather than widening the gate. That is a scope decision with a named owner, the same ownership question the rest of the system turns on.

Frequently asked questions

What is an approval gate for an AI agent?

An approval gate blocks an agent's action until a named person or an automated check resolves it, records that resolution, and defines what happens if nobody responds. All four parts are required. A notification posted to a channel while the agent proceeds anyway is not a gate: nothing is blocked and the default on silence is to act.

How do I decide which agent actions need human approval?

Sort actions by how expensive they are to undo, not by how sophisticated they are. Anything versioned, such as copy, audiences, sequences and scoring rules, goes through pull request review with automated checks first. Reversible internal changes go into a queue with a timer that executes on silence. Anything irreversible or customer-visible requires a named person to act.

What should an AI agent audit log record?

A correlation id, the agent identity and trigger, the inputs read by record id, the prompt version, the model identifier, the raw output, the payload actually applied, the previous value where something changed, the approver by name, the decision with a reason code, and the result. The test is whether you can reconstruct one of last week's actions from the log alone.

Why do human-in-the-loop processes stop working?

Because approvers rubber-stamp. When the agent is mostly right and the queue is long, approval becomes a reflex, and the gate keeps its latency while losing its protection. Watch approval latency, edit rate and rejection frequency, sample-audit one in twenty approved items with a different reviewer, and make the approver someone who bears the consequence.