Human in the loop for AI agents means a person approves, reviews, or is notified about specific actions the agent takes, instead of trusting it end to end. Done well, it is a decision made per action, not per agent: which actions the agent runs on its own, which it reports, which wait for approval, and which it never takes.
Most vendor conversations treat it as a checkbox. Yes, there is a human in the loop. That answer hides the two ways oversight actually fails. Put a person on everything and the agent becomes a suggestion engine feeding a queue nobody clears. Put a person on nothing and you find out what the agent misunderstood on a bad Tuesday. This article gives you a method for placing each action, and then the part that usually gets skipped: designing the review so the person stays a real check instead of a reflex.
Human in the loop is a per action decision, not a switch
An AI agent in a business workflow takes a series of distinct actions: read a message, classify it, update a record, draft a reply, send it, close a ticket, move money. Those actions do not carry the same risk, so they should not carry the same oversight. There are four modes an action can sit in.
| Mode | What the agent does | What the person does | Fits when |
|---|---|---|---|
| Act and log | Completes the action and records what it did and why | Reviews a sample of the log on a schedule | The action is easy to reverse, stays internal, and happens often |
| Act and notify | Completes the action and tells a named person | Reads the notice and can reverse it inside a short window | The action is reversible but someone should know it happened |
| Approve before | Prepares the action with its evidence and stops | Approves, edits, or rejects, usually with one click | The action is hard to undo or reaches customers, money, access, or people |
| Never | Cannot perform the action, because the permission was not granted | Does the action themselves, with the agent's preparation | The action is irreversible and consequential, or outside the agent's job |
The first two modes are where the value lives. The third is where the trust is built. The fourth is what keeps the worst week survivable.
OpenAI's practical guide to building agents names two triggers that warrant human intervention: exceeding a failure threshold, such as too many retries, and high-risk actions that are "sensitive, irreversible, or have high stakes," which it says should trigger human oversight "until confidence in the agent's reliability grows." That last clause matters. Approve before is a starting position for an action, not a permanent one.
You can see the same structure in the tools engineers use to let agents work on code. Anthropic's Claude Code permission system is tiered: reads inside the working directory need no approval, while shell commands, file edits, and most web fetches ask first, and an approval can be saved as a standing rule. Its documentation reserves the mode that skips prompts for "isolated environments" where the agent cannot cause damage. That is a per action oversight design, shipped as a product default.
How to decide which mode an action gets
You do not need to understand the model to place an action. You need two answers a business can give in a meeting.
Reversibility. Can the action be undone, by whom, at what cost, and inside what window? Relabeling an email is undone in a second. A sent email is not undone at all.
Blast radius. Who and what does the action reach? A note on an internal record touches one row. A message to a customer touches your reputation. A changed payment detail touches money. A change to someone's access touches security. A decision about a person's employment touches their life.
OpenAI's guide suggests rating each tool an agent can use as low, medium, or high risk on exactly these kinds of factors, including "read-only vs. write access, reversibility, required account permissions, and financial impact," and using the rating to pause or escalate. Here is the same idea as a placement matrix for the person who owns the workflow.
| Reversibility | Small radius: internal, one record | Medium radius: a team's work, a vendor, an internal message | Large radius: customers, money, access, employment, legal |
|---|---|---|---|
| Undone in seconds by anyone | Act and log | Act and notify | Approve before |
| Undone with effort, or only inside a window | Act and notify | Approve before | Approve before |
| Cannot be undone | Approve before | Approve before, or never | Never at launch |
Some examples of where common actions land. Classifying an inbound message: act and log. Assigning an owner in the CRM: act and log. Posting a daily status summary to an internal channel: act and notify. Drafting a reply to a customer: this one is free, because drafting changes nothing. Sending that reply: approve before, since the send is the action. Issuing a refund or changing a vendor's bank details: never at launch. The agent prepares the case and a person does it.
Which systems the agent can reach at all is a separate decision, covered in what access an AI agent should have to your business systems. This article assumes access is settled and asks what happens inside it.
The actions that stay behind a person, whatever the matrix says
Anything that commits money, changes access or permissions, deletes records, sends something a customer or vendor will treat as a promise, or affects someone's employment or legal position belongs on the human side of the line at launch. That is the default in our discovery sessions, and it is consistent with the rollout guide's approval line.
Approve before does not mean the agent cannot help with these. It means the agent gathers the evidence, drafts the action, and a person commits it. In most workflows the preparation is where the hours were going anyway.
Design the review so it stays real
This is the half of human in the loop that vendor pages skip, and it is where the design either works or quietly rots.
A named approver, not a role
"Operations approves" is not an approver. A person is. Name them, name a backup, and record both. If nobody can be named, the action is not ready for approve before. It is ready for never.
The channel they already work in
Approval requests go to the tool the approver already lives in, whether that is a chat channel or an inbox, and they arrive complete: the proposed action, the evidence the agent used, its reasoning in one or two lines, and the options. Approve, edit, reject. An approval that requires opening four systems to check will be approved without checking.
A deadline and a default
Every approve before action needs a response window and a stated outcome if the window closes with no response. The safe default is almost always "do nothing and escalate to the backup." "Proceed if nobody objects" turns an approval gate into a timer, and a timer is not oversight. The mechanics of who approves, in what tool, and by when are one of the seven inputs the implementation guide asks you to bring to a first working session.
A review load a person can actually carry
This is the constraint most designs ignore. Human factors research on people supervising automation is blunt about it. In their review of the empirical studies, Parasuraman and Manzey found that automation complacency occurs when the supervised task competes with other work for attention, that it shows up in novices and experts alike, and that it "cannot be overcome with simple practice." Automation bias, acting on the machine's suggestion when it is wrong, "cannot be prevented by training or instructions." (Human Factors, 2010)
The practical consequence: if you route hundreds of low-stakes approvals a day to one busy person, you will not get hundreds of reviews. You will get hundreds of clicks. The fix is not a more diligent person. It is a shorter approve before list. Put the reversible, internal, high-volume actions in act and log, keep approve before for the actions that earn it, and treat the daily approval count as a design number you look at every week.
Sample the autonomous tier
Act and log is not "nobody looks." It means a person looks at a sample on a schedule instead of at every instance in real time. Pull a fixed number of logged actions each week, check them against what a person would have done, and record the miss rate. That number is what tells you whether the action belongs in the mode it is in.
Enforce it in the system, not the prompt
An instruction like "never send an email without approval" in the agent's prompt is a request. OWASP's guidance on excessive agency names excessive autonomy as one of three root causes of damaging agent actions, and its mitigation is explicit: require human approval for high-impact actions, implemented either in the downstream system or in the tool that performs the action, and apply complete mediation so authorization is enforced by the systems the agent calls rather than by the model deciding whether it is allowed. In plain terms, the send button waits for a person because the integration is built that way, not because the agent was asked nicely.
Log everything and cap the rate
OWASP lists two measures that do not prevent a bad action but limit the damage: log and monitor what the agent's tools do, and rate limit them so an undesirable pattern is caught by monitoring before significant damage occurs. Anthropic's guidance on building effective agents makes the same point from the other side, noting that autonomy brings "the potential for compounding errors." Every action, in every mode, gets a record: the input, the decision, the evidence, and the approver if there was one. And every action type gets a ceiling per hour. An agent that has decided to do the wrong thing two hundred times should hit a wall at ten.
Move actions between modes on evidence, in both directions
Approve before is meant to be temporary for most actions. The question is what earns the move.
Use evidence from the review design above. For an action in approve before, track how often the approver changed or rejected what the agent proposed. For an action in act and log, track the sampled miss rate. When both the edit rate and the miss rate have been low across enough consecutive cycles to mean something for that workflow, move the action one step: approve before to act and notify, act and notify to act and log. As an example of the kind of rule to write down, not a benchmark: an internal action graduates after a full month of cycles with no approver edits and no sampled misses. Set your own numbers and put them in writing before launch.
Moves go the other way too. If the workflow's rules change, an integration changes, the underlying model changes, or the edit rate climbs, the action goes back a step until the evidence recovers. Customer-facing sends and anything touching money do not graduate on schedule alone. They graduate when a named person signs off on the evidence, and some of them never do.
Anthropic's guidance describes agents that "pause for human feedback at checkpoints or when encountering blockers." Graduation is how you decide, deliberately and with a record, where those checkpoints sit this quarter.
A worked example: an inbox triage AI employee
Take a common role family: an AI employee that monitors a shared inbound inbox, keeps it organized, and prepares replies. Here is one reasonable launch configuration. Your numbers and owners will differ.
| Action | Mode at launch | Why |
|---|---|---|
| Read new messages and classify them by type | Act and log | Internal, reversible in seconds, high volume |
| Assign an owner in the helpdesk or CRM | Act and log | Internal, reversible, the owner sees it immediately |
| Post a morning summary of open items to the team channel | Act and notify | Internal message, useful for everyone to see, easy to correct |
| Draft a reply to a customer | No gate needed | Drafting changes nothing until someone sends it |
| Send a reply to a customer | Approve before | Reaches a customer, cannot be unsent |
| Close a ticket as resolved | Act and notify | Reversible, and the owner should know |
| Issue a refund or credit | Never at launch | Money, and the case is prepared for a person |
The review design that goes with it: the support lead approves customer sends, with the operations manager as backup. Requests arrive in the team's chat tool with the customer's message, the draft, and the reason for the proposed reply. The window is the same business day; if it closes, the item escalates to the backup and nothing is sent. Each week the lead reviews a fixed sample of classifications and assignments and records the miss rate. After a month of cycles with no approver edits on a narrow class of replies, say order status confirmations that quote the record exactly, that class becomes a candidate to move to act and notify, and the lead decides.
The review design worksheet
Fill one row per action before launch. If a row cannot be completed, the action is not ready for any mode except never.
| Action | Mode at launch | Approver and backup | Channel | Deadline and default | What is logged | Evidence to move it | Next review date |
|---|---|---|---|---|---|---|---|
| Send customer reply | Approve before | Support lead, ops manager | Team chat | Same business day, then escalate and hold | Message, draft, evidence, decision, approver | No edits across a full month of cycles, lead signs off | First of next month |
This worksheet is the human side of the scorecard in the AI agent use cases guide, and it is the document a provider should be asking you for, not writing for you.
What this looks like in a managed AI employee
In VantaSoft's Agent Service, every AI employee gets a defined job, approved systems, scoped permissions, explicit human approval points, and escalation rules. Those decisions are made in discovery, where we define the business objective, roles, workflows, integrations, capacity, and human-oversight requirements together, and they are recorded in the Order Form rather than left to whoever configures the prompt. Approval gates are explicit for communications, finance, HR, legal, and access. We configure the agents, integrations, and workflows around those rules, and monitoring, routine updates, and issue investigation continue after launch.
Whether you buy a managed service or build your own, the approval rules are yours to own. Nobody outside your business can decide what your customers should hear from a machine, or who signs off on a refund. The BankrBot incident is what it looks like when that decision was never made.
Frequently asked questions
Does human in the loop make an AI agent slower than doing the work ourselves?
Only if you gate the wrong actions. Approve before on a customer send costs one click on a draft that is already written and already checked against the record. Approve before on every classification costs a person their afternoon and produces reflex approvals. Gate by reversibility and blast radius, and most of the workflow runs without waiting.
Can the agent decide for itself when to ask a person?
An agent can be instructed to escalate when it is unsure, and it should be. But that is a request inside a prompt, not a control. The actions that must wait for a person should wait because the system enforces it, following the complete mediation principle OWASP describes. Use the agent's own judgement as a second net, never as the only one.
What is the difference between human in the loop and human on the loop?
People use the terms loosely. Broadly, in the loop means a person approves an action before it happens, and on the loop means the action happens and a person supervises the results and can intervene. In the four mode model, that is approve before versus act and notify or act and log with sampling. Most real workflows use both, for different actions.
When can we remove an approval step?
When the evidence says so: a low edit rate on the approvals and a low miss rate on the samples, sustained across enough cycles for that workflow, with a named person signing off. Write the rule down before launch, move one step at a time, and keep the ability to move back.
Is approve before enough on its own?
No. It is one of three layers. The agent's access has to be scoped so it cannot reach what it should not, every action has to be logged and rate limited, and then the approval gates sit on top. An approval gate over an agent with unrestricted access is a gate in an open field.
Decide the gates before the tools
The question is never whether to have a human in the loop. It is which loop, for which action, checked by whom, and on what evidence that changes. Answer it per action, write down the review design, and revisit it monthly. Your agent will do more on its own over time, and every expansion will have a record behind it.
If you want to work through it on a specific workflow, that is what our discovery session does. It starts with 30 minutes on your workflows, and the human-oversight rules are one of the things we define together before anything is built.
