An AI agent should stop and ask a human in three situations: the action is hard to undo, a mistake would not be noticed quickly, or the agent is not confident in its own answer. Everything else it can do alone. The rest of this piece is how to apply that, action by action.
The question is usually asked as though autonomy were a dial with one setting per agent. It isn't. A well-built agent runs at different supervision levels for different steps of the same workflow, and getting that mapping right is most of what makes an agent safe enough to deploy and useful enough to be worth deploying.
Two questions decide the level for any given action: how reversible is it, and how detectable is a mistake. Everything else follows from those.
The four supervision patterns
| Pattern | The agent… | Right when |
|---|---|---|
| Full autonomy | Acts, nobody reviews | Reversible and low-value per case |
| Sampled review | Acts; a percentage is audited after | High volume, errors tolerable and detectable |
| Approve-before-act | Proposes; a human confirms | Irreversible or high-value |
| Escalation-only | Acts when confident, hands off when not | Most real production workflows |
Full autonomy suits work where a mistake is cheap and self-correcting — tagging, routing, drafting an internal summary. Nobody should review every ticket classification; the cost of review exceeds the cost of the error.
Sampled review is the workhorse for volume. The agent acts on everything, and 2–5% is audited by a human whose real job is watching for drift rather than catching individual errors. This is how you keep the throughput of autonomy and still have a human signal on quality.
Approve-before-act is mandatory wherever an action moves money, contacts a customer irreversibly, changes an entitlement, or writes to a system of record you can't easily undo. The agent prepares the action and a person clicks. Slower — and still far faster than a human doing the whole task from scratch.
Escalation-only is what most production workflows actually look like: the agent handles what it's confident about and routes the rest to a person with its reasoning attached. This is what produces the 60–70% autonomous resolution that a well-built support agent reaches — not 100%, and 100% was never the target.
The two questions, applied
Reversibility. Can you undo it in one step, at low cost? Re-routing a mis-routed ticket is trivial. Un-sending an email to a customer is impossible. Refunding a wrongly-charged card is possible but expensive in trust. Sort your actions by how hard the undo is, and the approval gates place themselves.
Detectability. If it goes wrong, will anyone find out — and how fast? This is the one teams under-weight. An error that surfaces immediately is far safer than a quiet one, even at the same severity, because a quiet error compounds. An agent silently mis-categorising 8% of records for three months does more damage than one that fails loudly on day one.
Where detectability is poor, add supervision even if the individual action seems low-stakes. That's the same reason a live system needs a quality threshold in its runbook — the failures that hurt are the ones nobody sees.
The escalation matrix
Put the two questions together and each kind of action lands in one row. Use it as a starting point and tighten or loosen a row as the evidence comes in.
| The action is… | Example | The agent should |
|---|---|---|
| Easy to undo, and a mistake shows up fast | Tagging, routing, drafting an internal summary | Act alone |
| Easy to undo, high volume, errors tolerable | Classifying every incoming ticket | Act alone, with 2–5% audited afterwards |
| Hard to undo or high-value | Issuing a refund above a threshold, a bespoke customer email, changing an entitlement, writing to a system of record | Prepare it, then wait for a person to approve |
| Any action where the agent isn't confident | A case that doesn't match what it has seen | Hand off, with its reasoning attached |
| Low-stakes, but a mistake would stay quiet | Categorising records nobody re-checks | Act, under added review until errors are visible |
| Wrong would be both unnoticed and unrecoverable | A decision with no way to verify or reverse it | Not act at all; this stays with a person |
Map it per step, not per agent
Take a refund agent. Reading the ticket, retrieving the order, checking the policy, and drafting a decision are all fully autonomous — reversible, cheap, no reason for a human. Issuing the refund is approve-before-act above a threshold and autonomous below it. Emailing the customer is autonomous for templated confirmations and approve-before-act for anything bespoke.
One agent, three supervision levels, chosen per action. Teams that set a single level per agent end up either approving everything — at which point the agent saves nothing and adoption collapses — or approving nothing, at which point the security review never clears and it stays a demo. Both failure modes come from treating autonomy as a property of the agent instead of the action.
What an agent genuinely can't do unsupervised
Independently of risk appetite, some things aren't delegable:
- Decisions where being wrong is undetectable and unrecoverable. No supervision pattern helps if you'll never know.
- Novel judgment with no precedent. Agents generalise from patterns. A genuinely unprecedented case is exactly where confidence estimates are least reliable.
- Anything requiring accountability a person must hold. Regulatory sign-off, clinical or legal decisions, employment actions. The constraint isn't capability — it's that responsibility can't be assigned to software.
- Work whose correct answer nobody can define. If a human expert can't say whether an output was right, you can't evaluate it, and an unevaluable system can't be trusted unattended. That's the first of the five gates.
Autonomy should increase with evidence
Start more supervised than you'll end. Run approve-before-act on a step for a few weeks, record how often the human changes the agent's proposal, and let that number decide. Under 2% overrides on a few hundred cases is a good argument for dropping to sampled review. A rising override rate is drift, and it's a signal you'd otherwise have missed.
That's the honest version of autonomy: not a setting chosen at design time, but a level earned per action against measured evidence — and lowered again when the evidence changes. The layers that make this measurable are the same ones that make an agent deployable at all, which is why our builds install them from day one rather than retrofitting them once someone asks for a number.
