Human in the loop vs human on the loop: which AI agent actions need approval

Human in the loop means a person approves an AI agent's action before it runs. Human on the loop means the agent acts on its own and a person monitors and corrects afterwards. Approval belongs on actions that are hard to undo, move money, reach someone outside the conversation, or haven't been validated yet.

Everything else can run on the loop, with a person checking the results.

Most teams start the other way round. They switch on an AI agent (software that reads a request and can act in other systems, not only reply) and argue about whether to trust it. A better question is narrower: which action, at what risk, with what track record.

What is human in the loop AI?

Human in the loop AI is a setup where the agent proposes an action and a person approves or rejects it before it runs.

Wikipedia's entry on human-in-the-loop (an encyclopedia definition) describes it as "a model requiring human interaction" and notes the term is used in several contexts.

In machine learning it often means people labeling data to train a model. In this post it means something else: a person deciding on an agent's action. The short form is HITL.

Approval only works if everyone counts the same states. These are the five an approval queue needs.

Action states: what each one means

Human in the loop vs human on the loop: what's the difference?

The difference is timing. In the loop, a person decides before the action runs. On the loop, the agent acts and a person reviews afterwards.

Both terms are also used in simulation and defence, where they describe how much control a person keeps over an automated system. For an AI agent in a software-as-a-service (SaaS) company, the trade-off is simpler: speed against the cost of a wrong action.

Our position: the right setting depends on the impact on the business and on the user's experience. The higher the risk, the less sense out of the loop makes.

An internal tag on a conversation can run with nobody watching. A message to a user, a lead sent to sales or anything touching money affects revenue or how the user sees the company, so someone keeps looking at the results.

Approval has its own failure mode. The EU AI Act's Article 14 on human oversight (EU regulation text) asks that people overseeing high-risk AI systems are able:

to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)

The article is written for high-risk systems, but the warning applies to any approval queue.

A queue where every item is approved without being read adds delay and no control.

Which AI agent actions need human approval?

Actions that are hard to undo, move money, reach someone outside the conversation, or that the agent hasn't proven yet.

Five questions decide it:

1. Can it be undone? A message can be corrected. A refund or a deleted record can't.
2. Does it move money? Refunds, credits, discounts and plan changes have a cost the moment they run.
3. Who does it reach? An answer reaches the user who asked. A lead reaches an account executive's calendar. A report reaches a customer's finance team.
4. How often does it run? A daily action gives a reviewer something to learn from. A yearly one never builds a record.
5. Has it been validated? A new action has no error rate yet, so nobody knows how often it is wrong.

Decision matrix: in the loop or on the loop

The refund rows follow the rules in how an AI agent handles refunds, cancellations and plan changes: eligibility from billing data and an explicit yes before anything irreversible.

Our recommendation: every new action starts in the loop. Answers from documentation are the exception, because a wrong answer costs a correction and no money.

This changes when volume grows faster than review capacity. A reviewer with a long queue tends to approve without reading, the automation bias quoted above. A narrower action on the loop, with a strict automatic check, is safer than an approval nobody reads.

Human in the loop examples from AI agents in production

Two patterns repeat: validating a new action before it runs alone, and confirming operations that need a person's check before they happen.

Qualifying chat leads before they reach sales

A reviewer checks every lead the chat agent wants to pass to sales, so the team validates the agent before it hands leads over alone.

In one Zentesimal account, the support agent in the chat also spots users who want to talk to sales. About 240 leads a month reach the review step, and reviewers confirm 228 of them as qualified (95%, one account, review in place since October 2026).

Before a lead goes to the sales team, a reviewer checks two things. Is the lead really qualified? Which account executive should get it? The lead then goes to that person in Slack, on a card like this one.

Template: the lead approval card (example values)

• Action: Send Slack notification to sales
• Task and conversation: links to both
• Lead: Marketing team at a 200-person ecommerce company, wants to add 15 seats and connect two more stores
• Contact: Emma Clarke (Head of Marketing), emma@example-store.com
• Website: example-store.com
• Current account: Paying user for 8 months, 5 seats, usage up in the last 30 days
• What they asked for: A call with sales about volume pricing
• Qualification answers: Budget approved for this quarter; Emma decides together with the CFO
• Potential plan: Business, annual
• Reason: Notify sales of a qualified lead
• Assign to: [account executive, chosen by the reviewer]
• Approved by: [reviewer]

The purpose is validation. The team wants to see what the agent decides before letting it pass leads on its own.

With 12 rejections a month, the action sits at the limit for low-impact actions described below. The review now changes few decisions, and the action is close to moving on the loop.

What the rejections showed. The usual reason is a user who believed they qualified and asked for a meeting. When the reasons came out, they didn't fit.

Each rejected lead goes back to the agent with the information it had skipped. The next conversation asks for it before the user and the sales team spend time on a meeting.

Confirming financial and internal operations

For financial operations, the agent collects everything the decision needs and hands it to a person in finance. That person decides whether the operation goes ahead.

The reviewer works as a reviewer, and the agent does the operator's work: finding the account, reading its history, checking the request against policy and preparing the action.

Who approves depends on the operation.

How do you move an action from approval to autonomy?

Track how often reviewers reject or correct the agent's proposals, and move the action on the loop once that error rate stays under the limit.

Error rate here means the proposals a reviewer rejected or corrected because the agent was wrong, divided by all proposals reviewed in the period. A rejection for a business reason the agent couldn't know doesn't count.

The limit depends on impact. For low-impact actions, such as passing a lead, the action moves on the loop under 5%. In the financial operations Zentesimal runs, the limit is 2%, held consistently over more than 1,000 reviews.

Financial operations aren't all alike. The riskier ones inside finance get a lower limit still, set by the team that owns them.

The rate also needs enough reviews behind it. A standard statistics rule, the rule of three, helps here: if a reviewer finds no errors in n proposals, the true error rate is very likely below 3 divided by n.

Sixty clean reviews in a row support "under 5%". At the lead volume above, that is about a week of leads.

Checklist: before an action runs without approval

1. The error rate over the review period is under the limit for the action's impact.
2. The sample is large enough for that limit: the rule-of-three count for low-impact actions, the full review history for financial ones.
3. Every rejection has a labeled reason.
4. The reasons that repeat are fixed in the agent's instructions or in the questions it asks.
5. An automatic rule checks each result before it goes out (amount caps, allowed lists, one execution per request).
6. A person reviews a sample afterwards, and the action goes back in the loop if errors rise.
7. The team that owns the outcome (finance, sales or support) agrees.

Some actions never leave the loop. A refund outside policy is a business decision every time, so a person keeps making it.

The NIST AI Risk Management Framework (a voluntary standard from the US National Institute of Standards and Technology) covers the design, development, use and evaluation of AI systems. Risk management continues while the system is in use, which is the job of human on the loop.

Key takeaways

How Zentesimal handles approvals

In Zentesimal, any action an AI agent can take can require human approval: a Slack message, an update in the helpdesk, a change made through a connected tool. The flag sits on the action, so the same agent runs some actions alone and waits on others.

When an action needs approval, the agent creates a task with the proposed action, its arguments and a link to the conversation. It tells the user the change is pending review and keeps the conversation going while the action waits.

The reviewer approves or rejects from Tasks in Zentesimal or from a card in a Slack channel. The card shows the action, links to the task and the conversation, and the exact arguments the action will run with. Once decided, it records who approved it.

From Tasks, the reviewer can also add instructions, such as telling the user what happens next.

Actions that run on their own pass through guards, the rules that check every final result and the actions taken before anything reaches the user. The AI Guards page shows the checks for policy, scope, tone and language. Escalations can also be reviewed after the fact, which is how on the loop works in practice.

The same setup works across the support and conversion use cases. Finance, support and sales each approve the actions they own.

Book a demo