When should AI agents require approval?

Key takeaways

• An agent is a regular employee, not a manager. Any action that would need a sign-off if a human in that role did it needs the same sign-off when an agent does it.
• Four questions decide whether to gate an action: does money move, does a human feel it, is it reversible, is there a named policy owner.
• Approve high-impact low-frequency actions. Monitor high-frequency low-impact ones. Trying to approve everything burns reviewers out within a week.
• Requiring approval is not a statement about how much you trust the model. It is a statement about which decisions in your business deserve a named human owner.

The scenario

A fintech ops team runs an AI agent that reconciles invoices. Somewhere around week three, the agent silently writes off a $47,000 discrepancy because the ledger looked close enough. Nobody was "against" human approval before that incident. They just had not drawn the line. The rest of this guide is how we draw that line cleanly.

The four-question test

For every tool an agent can call, ask these four questions. If the answer to any of them is yes, the action should be gated.

• Does money move? Refunds, credits, compensation changes, vendor payments, discount overrides.
• Does a human feel it directly? A message sent to a customer, a support case closed, an employee record updated, a calendar event created on someone else's calendar.
• Is the change hard to reverse? A delete, a send, an external API write to a vendor that does not expose an undo, a production deployment.
• Would a named policy owner expect accountability? Anything that a compliance, finance, legal, or ops lead would want their name associated with before it happens.

Examples by domain

The framework above is abstract on purpose. Here is how it lands in three common domains.

• Customer support: approve refunds above a threshold, compensation changes, account closures. Do not approve read-only lookups or knowledge-base answers.
• Finance and ops: approve ledger write-backs, vendor payments, invoice adjustments above tolerance. Do not approve status queries or report generation.
• HR and internal ops: approve any employee record mutation, policy exception grants, access changes. Do not approve schedule reads or FAQ responses.

The anti-patterns

The two mistakes we see most often are polar opposites of each other, and both cause real damage.

• Approving everything. Reviewers triage in bulk, quality collapses, the approval step becomes rubber-stamp theater - and now you have a compliance artifact that claims human oversight but does not really have it.
• Approving nothing until an incident. You ship fast, the agent performs well on the happy path, and one bad input later you are writing a postmortem you did not need.
• Approving by "risk score" the model invents. The model does not know your business risk. You do.
• Approving without context. If the reviewer cannot see the customer, the transaction, and the reason the agent chose this action, they cannot approve well - and you have just built a slow rubber stamp.

12 guardrails every AI agent needs

How to route approvals well

Once you decide an action needs approval, the next question is who sees it. Routing is where most teams lose quality, because "anyone on the ops channel" becomes "whoever clicks first," which becomes "nobody who understands the case."

Think of the agent the same way you think of a new employee. A new employee does not send a payment to a vendor without their manager signing off. They do not grant a policy exception without the relevant lead approving it. They follow the org chart, because the org chart encodes accountability. An agent operating without that structure is not just a technical risk - it is an organizational one. Routing must map to real seniority and role, not to whoever happens to be online.

• Route by policy: amount, customer tier, region, action class.
• Route by role: refunds go to CS lead, compensation to HR lead, ledger writes to finance lead.
• Respect the hierarchy. A CFO-level decision should not land in a junior analyst's queue just because they are available.
• Add deadlines. A refund approval that sits for 40 minutes is effectively a rejection from the customer's point of view.
• Add escalation. If the owner misses the deadline, it goes up the chain to a named fallback, not back into the same queue.

What an approval payload should contain

If a reviewer cannot approve confidently in under two minutes, the request is missing context. A well-formed approval request carries everything they need to decide without opening another tab.

• The business object (order id, account id, invoice id) with a link to your internal tool.
• The action (refund $320 to order #4521) in human language, not JSON.
• The reason the agent picked this action - its summary, not the full transcript.
• Any policy the action triggers (over threshold, policy exception, first-time action on this account).
• Deadline and escalation target so the reviewer knows what happens if they wait.

Put the whole organization in the loop, not just one reviewer

Contro1 is human-in-the-loop done right, and then it goes further: it puts the whole organization in the loop. Instead of one reviewer clicking approve, it gives you the full suite to govern agents. Policy and risk thresholds decide when an action pauses, approval hierarchy and quorum decide who must sign off, shift coverage and role routing decide who is on duty, and SLA escalation makes sure nothing stalls. Every risky action runs as a managed event, routed to whoever would have owned the decision anyway.

That is the clean operating model for AI agents. The agent does the hard work: gathering context, preparing the action, drafting the response, and moving the workflow forward. The management, accountability, and final business decisions stay with the people who owned them before agents entered the process.

This is why the approval question should not be "do we trust the model?" The better question is: "would the organization let an employee in this role take this action without approval?" If the answer is no, the agent should not perform it on its own authority either.

• The risky action pauses for a real human decision before it executes.
• That decision is routed through the organization that owns it: shift coverage, role routing, deadlines, escalation, audit, and ownership.
• Let agents accelerate the work, but keep dangerous actions behind accountable human decisions.

Summary: the decision you are actually making

Requiring approval is not a statement about how much you trust the model. It is a statement about which decisions in your business deserve a named human owner. You were already making that decision before AI agents - you just made it implicitly, through org design and access control. Agents force you to make it explicit, tool by tool. That is the whole job.

Prompt guardrails vs runtime control · Approval infrastructure for AI agents · Quickstart: build your first approval

Frequently asked questions

Should every external tool call need approval?

No. Only tools whose actions have meaningful business risk. Read-only lookups, cache reads, and status queries should never involve a human.

What is the right threshold for a refund approval?

Teams commonly start at the median refund amount and tune from there. The goal is not to catch every refund - it is to catch the ones where the agent is likely to be wrong, or where a named owner wants accountability.

How do I keep latency acceptable when a human is in the loop?

Use deadlines, escalation, and async patterns where possible. A 2-minute P50 is very achievable with role-based routing and good payload context. A 40-minute P50 usually means reviewers are triaging across too many cases.

What if the agent can pick which action to take?

Gate the individual action, not the model. The gate sits on the tool call, and you evaluate "does this specific call cross a policy line" regardless of how the agent reached it.

Can I approve in batch?

Sometimes - end-of-day reconciliation is a common case. But batch approval is not a substitute for real-time gating on irreversible actions. Use batch for review, not for allowing execution.