Put a human in the loop for every action an agent takes, and you've built an expensive way to click "approve." Put a human in the loop for none of it, and the first time the agent does something wrong, nobody finds out until a customer, an auditor, or a bank statement does. Most AI agent deployments fail at one of these two extremes, not because the model is bad, but because nobody decided, action by action, which ones actually need a person to look first.
The right question isn't "should this agent have human oversight." It's "which specific actions in this workflow carry enough cost-if-wrong that a delay is worth it, and which ones are cheap enough, reversible enough, or well-defined enough to clear against policy without one."
The naive version breaks in one of two predictable ways
The over-gated version looks responsible on a slide. Every email, every ticket update, every record change routes to a human queue. Within two weeks, that queue is where automations go to die: approvers rubber-stamp without reading, or the backlog gets long enough that people route around the agent entirely and just do the task themselves. You've paid for the automation and kept the manual labor.
The under-gated version looks efficient until it isn't. An agent gets access to send external emails, update billing records, or modify permissions, and the only control is "we'll review the logs periodically." Nobody notices the agent looping on a bad instruction, acting on stale data, or doing something technically permitted but contextually wrong until it's already happened forty times. A shared service account with broad scope and no checkpoint isn't governance — it's a blind spot with a dashboard.
Both failure modes come from treating "human in the loop" as a single on/off setting applied to the whole agent, instead of a decision made per action.
The gate belongs on the action, not the agent
An agent doesn't need one approval policy. It needs a policy per action type, based on two questions: what does it cost if this is wrong, and can it be undone. Actions that are cheap and reversible — drafting a reply, tagging a record, pulling a report — can clear automatically against policy every time. Actions that are expensive or irreversible — sending money, changing access, communicating externally under the company's name, deleting anything — get a gate, always. The middle band is where judgment actually matters, and it's usually the largest one: a refund under $200 clears automatically, a refund over $2,000 doesn't; a vendor update to an existing account clears, a new vendor with new banking details doesn't. That's a policy threshold, not a vibe, and it should be written down as one.
This is the governance principle: policy-defined approval gates deciding what an agent can do without a human, set in advance rather than negotiated case by case after something's already happened. It only works if it's paired with identity — the agent needs a scoped credential that structurally can't take the gated action at all, not just a UI that asks nicely before it does. And it only works if every decision, gated or auto-cleared, gets written down: the action, the policy it was checked against, and the reason it passed or stopped. That's what makes the gate legible instead of a black box. When we deploy an agent, we write every action against a policy and a reason at the moment it happens, so the threshold isn't just a rule someone remembers setting — it's a record someone can pull up.
Getting the thresholds right takes an actual audit of the workflow, not a guess. That's usually the first conversation worth having — you can book a diagnostic call to walk through where your specific process needs a gate and where it doesn't.
Where this still takes real judgment
Thresholds drift. A refund cap set at $200 because that was reasonable for a small catalog stops being reasonable once average order value triples — and nobody revisits it unless someone's watching the pattern, not just the individual approvals. Gates need an owner and a review cadence, or they calcify into either rubber-stamping or over-caution as the business changes underneath them.
There's also a real cost to getting the gate itself wrong in either direction, and it's not always obvious which way you've erred until you've run it for a while. A gate that's technically correct but fires on 80% of actions is functionally the over-gated failure mode wearing a policy document. A threshold that never fires might mean your policy is well-tuned — or it might mean nobody's checked whether it's too loose to matter. The only way to know is to look at what's actually clearing automatically versus what's queuing, on a regular basis, not just at launch.
The question to sit with
Pull up the last automation your team tried to ship — the one that stalled in pilot or got quietly abandoned. Was it stuck because every action needed sign-off, or because nothing did and someone got nervous? That answer tells you which failure mode you're actually prone to, and it's worth knowing before you build the next one.