When should AI agents require approval?

Key takeaways

• The right question is not "can the model do this" but "who is accountable if it does this and is wrong."
• Four questions decide approval: does money move, does a human feel it, is it reversible, is there a policy owner.
• Approve high-impact low-frequency actions. Monitor high-frequency low-impact ones.
• Blanket "approve everything" burns reviewers out in a week. Blanket "approve nothing" ships your first incident in a month.
• Gate by policy, route by role, set deadlines. That is the whole framework.

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."

• 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.
• 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 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.

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 · 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.