An approval gate is only useful where a human can add information the agent does not have, and useless everywhere else. Gate every action and reviewers rubber-stamp out of fatigue. Gate nothing and a rare, consequential mistake ships unreviewed. The right placement depends on reversibility, blast radius, and the agent’s actual confidence — not on how important the workflow feels.
Teams building their first agent workflow usually start from one of two instincts. Either gate everything, because it feels safer, or gate nothing, because the whole point was to remove manual work. Both instincts produce the same failure a few weeks later: gate everything and reviewers stop reading what they are approving; gate nothing and the first genuinely bad action goes out before anyone notices the pattern.
At a glance
- A gate only helps if a human can add information the agent lacks
- Reviewer attention is a finite resource that gating strategy must budget for
- Reversibility and blast radius should decide placement, not workflow importance
- Confidence-based gating catches more real errors than blanket approval
- A gate nobody reads is worse than no gate — it creates false assurance
- Gates should shrink over time as a boundary proves itself, not stay fixed forever
Why does gating everything fail?
Because approval fatigue is real and measurable. A reviewer asked to approve fifty routine actions a day and one genuinely risky one will, after the first week, apply the same three seconds of attention to all fifty-one. The gate still exists in the workflow diagram. It has stopped existing as an actual check.
| Gating strategy | What happens to reviewer attention | What gets caught |
|---|---|---|
| Approve every action | Collapses to rubber-stamping within days | Almost nothing; the rare bad action looks identical to the routine ones |
| Approve nothing | Not consumed at all | Nothing, until a bad outcome surfaces downstream |
| Approve by fixed category | Stays meaningful longer, degrades as categories get gamed | Whatever the category was designed to catch, and little else |
| Approve by confidence and blast radius | Concentrated on the cases that need it | The actual high-risk tail, because that is what routes to the gate |
The fourth row is the only strategy where reviewer attention and actual risk are aligned. Every other row either wastes attention on routine cases or spends none at all, and both failure modes produce the same outcome — a real mistake reaching production unreviewed.
What should decide whether an action gets gated?
- Reversibility. An action that can be cheaply undone needs a gate far less than one that cannot. This is usually the single biggest factor and the one teams weigh least.
- Blast radius. How many people or how much value a wrong action touches. A mistake affecting one internal record is not the same risk as one affecting every customer simultaneously.
- Agent confidence. If the agent itself has a genuine, calibrated signal that it is uncertain, that is exactly the population of actions worth routing to a human — routing everything else wastes the gate on cases the agent already handles reliably.
- Novelty. A situation unlike anything in the agent’s training or examples is more likely to produce a bad decision than a routine one, even if the agent reports high confidence.
- Regulatory or contractual requirement. Independent of technical risk, some actions require documented human sign-off regardless of how reliable the agent has proven to be.
Notice that “how important this workflow feels” is not on the list. Importance is a reasonable proxy for blast radius, but it is a proxy — a high-profile workflow with fully reversible, low-blast-radius individual actions may need fewer gates than a low-profile one making irreversible commitments.
Where exactly should a gate sit in the flow?
Figure 1 — Same workflow, gate placed at two different points
Gate at the end
The agent completes its full reasoning and prepares the action, then a human reviews the finished output.
The reviewer sees a polished result that looks complete and confident, which is exactly the presentation most likely to produce a rubber-stamp. Whatever uncertainty existed during reasoning is invisible by this point.
Reviews the answer, not the reasoning
Gate at the decision point
The agent surfaces the specific moment it was uncertain, escalating scope, or about to take an irreversible step, with the relevant context attached at that point.
The reviewer sees exactly what triggered the gate and why, rather than a finished narrative that has already smoothed over the uncertainty.
Reviews the actual decision
Where the gate sits changes what the reviewer is actually able to evaluate. A gate at the end reviews a story the agent has already told itself. A gate at the specific decision point reviews the decision, which is the thing that was actually uncertain.
The four placements worth building deliberately: before any action that cannot be reversed, at any point the agent concludes the task’s scope is larger than what was originally authorised, when consumption crosses a defined budget threshold, and after a defined number of consecutive failures rather than allowing indefinite silent retrying.
Watch for this
A gate that always shows the same boilerplate justification regardless of the actual decision trains reviewers to stop reading before they consciously decide to. If every escalation reads “flagged for review” with no specific reason, the fix is not reviewer discipline — it is that the gate is not surfacing the information a human would need to actually evaluate it.
How do you keep a gate from becoming a rubber stamp?
| Design choice | Effect on reviewer engagement |
|---|---|
| Show the specific reason for escalation, not a generic flag | Reviewer evaluates the actual concern instead of pattern-matching to “normal” |
| Vary the volume routed to each reviewer over time | Prevents the numbing effect of a constant, predictable stream |
| Track approval rate per reviewer | A reviewer approving 100% is a signal the gate has stopped functioning for them |
| Periodically inject a known-bad case | Directly measures whether the gate is still catching anything at all |
| Route only the genuinely uncertain population | Keeps volume low enough that attention per case stays high |
The injected known-bad case is the most honest test available. Everything else is inference about reviewer behaviour. A gate that fails to catch a case you know is bad has demonstrably stopped working, regardless of how the dashboard looks.
Should gates shrink over time?
Yes, deliberately, and this is the part most implementations skip entirely.
A gate placed because an agent’s behaviour in a given situation was unproven should narrow as evidence accumulates that the boundary is reliable — not stay fixed forever out of caution that was appropriate at launch and is no longer informed by anything current. An agent’s gated action, approved without modification a hundred times running, is a candidate for a wider boundary, not permanent human review.
The reverse also has to be true. A gate loosened based on a clean track record should tighten immediately the moment the underlying context changes — new action types, new user population, new failure mode observed elsewhere. Gate placement is a living control, reviewed on a cadence, not a one-time design decision.
Where do teams go wrong?
Treating the gate as a compliance checkbox
A gate added because “there should probably be human oversight here” without a specific theory of what the human is catching produces exactly the boilerplate-justification problem described above. Every gate should have an answer to “what information does the human have that the agent doesn’t,” or it should not exist.
Measuring gate health by approval rate alone
A 98% approval rate could mean the agent is excellent, or it could mean the gate has become a formality. Without the injected known-bad-case test, these two situations are indistinguishable from the dashboard alone.
Never revisiting placement after launch
Gates calibrated for launch-week uncertainty are frequently left unchanged for years, either wasting reviewer attention on now-routine cases or, worse, staying loose on a category that has since started producing new failure modes.
What do experienced teams do differently?
They design each gate around a specific question the human is answering, not around a general sense that oversight is good practice.
“Is this refund amount consistent with the customer’s history” is a gate with a specific question and a specific piece of context the agent may lack. “Should we approve this” with no further detail is not a gate — it’s a signature requirement wearing a gate’s clothing, and it degrades to rubber-stamping fast because there is nothing concrete to evaluate.
They also treat reviewer capacity as a hard constraint on how many gates can exist, not an assumption that more reviewers can always be hired. Given a fixed capacity, the design question becomes which population of actions most deserves that attention — which forces the reversibility, blast-radius, and confidence-based routing described above, rather than a gate on everything that feels important.
A short glossary
- Approval fatigue
- The decline in reviewer attention and scrutiny that occurs when approval volume exceeds what can be meaningfully evaluated.
- Blast radius
- The scope of harm a wrong action can cause, in value, reach, or number of people affected.
- Confidence-based routing
- Sending only the subset of actions where an agent’s genuine uncertainty signal is high to human review.
- Rubber-stamping
- Approving actions without meaningful evaluation, typically a symptom of excessive gate volume or vague justification.
- Known-bad-case injection
- Deliberately routing a case known to be incorrect through a gate to test whether review is still functioning.
Key takeaways
- A gate is only useful where a human adds information the agent lacks; place it nowhere else.
- Gating everything and gating nothing both fail the same way — a real mistake ships unreviewed.
- Reversibility, blast radius, agent confidence, and novelty should decide placement, not perceived importance.
- Gate at the specific decision point, not at the end, or the reviewer only sees a polished, already-decided story.
- Track per-reviewer approval rate and periodically inject known-bad cases to test whether a gate still works.
- Gates should shrink as a boundary proves reliable and tighten immediately when context changes.
- Every gate needs a specific question it is answering, or it degrades into a compliance formality.
Frequently asked questions
Where should human approval gates go in an agent workflow?
At points where a human can add information the agent does not have: before irreversible actions, when scope escalates beyond what was authorised, at defined budget thresholds, and after repeated consecutive failures. Placement should follow reversibility and blast radius, not how important the workflow feels.
Why does approving every action fail?
Reviewer attention is finite. Faced with a high volume of routine approvals, reviewers apply the same shallow attention to all of them within days, including the rare genuinely risky case, which then looks identical to everything else and gets approved without real scrutiny.
How do I know if a gate has become a rubber stamp?
Periodically inject a case you know is incorrect and see whether it gets caught. A consistently high approval rate alone does not tell you whether the gate is working or has simply stopped being read; the injected test is the only direct measurement.
Should gates be placed at the end of a workflow or earlier?
Earlier, at the specific decision point that triggered uncertainty, escalation, or an irreversible step. A gate at the end shows a reviewer a polished, already-completed result, which is the presentation most likely to be approved without genuine evaluation.
Should approval gates change over time?
Yes. A gate proven reliable through many approved, unmodified actions is a candidate for a wider boundary rather than permanent review, and a gate should tighten immediately if the underlying context changes — new action types, new user population, or a newly observed failure mode.
What is confidence-based gating?
Routing only the actions where the agent has a genuine, calibrated signal of uncertainty to human review, rather than gating by category or gating everything. It concentrates limited reviewer attention on the population most likely to actually need it.
Can regulatory requirements override risk-based gate placement?
Yes, some actions require documented human sign-off regardless of how reliable the agent has proven technically. Regulatory or contractual gates should be layered on top of the risk-based design, not treated as the entire gating strategy.
What makes a gate’s justification effective rather than boilerplate?
Showing the specific reason an action was escalated — the exact uncertainty, the exact scope change, the exact threshold crossed — rather than a generic “flagged for review” label. Vague justifications train reviewers to stop reading before they consciously decide to.
References
- Anthropic. Model Context Protocol documentation, covering the permission and tool-scoping layer where gates are technically enforced.
- NIST. AI Risk Management Framework, covering human oversight requirements for consequential automated decisions.
- OWASP. OWASP Top 10 for Large Language Model Applications, relevant to excessive agency and the case for scoped human checkpoints.
