Human in the loop AI keeps a named person inside an agent's decision cycle, with the standing authority to approve, edit or stop an action before it reaches a customer, a payment, or a record the business cannot quietly undo. The agent still does the reading, the drafting and the routine matching; a person still decides what actually goes out the door.
The stakes are no longer theoretical. Large enterprises will run over 1,600 AI agents each by the end of 2026, and seven in ten executives already admit their governance has not caught up (IBM, Think 2026). Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, weak risk controls among the reasons it names (Gartner, June 2025). Get oversight wrong this early and a business rarely gets a second shot at the pilot budget, let alone a customer's trust.
The three places human oversight actually earns its keep
Human oversight earns its keep in exactly three places: money, customers, and anything the business cannot reverse once it happens. Everywhere else, an AI agent working inside its documented scope, an internal draft, a tagged ticket, a first-pass summary, does not need a person watching every step; the cost of a mistake is low and the fix is usually a re-run.
Money means anything that debits an account, issues a refund, matches an invoice, or changes a price: a KHQR payment reconciled against the wrong order, a refund approved twice because two channels logged the same complaint. Customers means anything a person outside the business receives in the company's name: a reply that promises a discount nobody authorized, a cancellation confirmed to the wrong guest. Irreversible means a deleted record, a sent email, a published page, a changed permission, where "undo" does not exist once the action clears.
We would not let a first production agent touch anything in these three categories unsupervised, no matter how clean the pilot looked. A no-code invoice-matching agent wired into a CRM and an accounting tool, the kind of AI agent build we scope for clients, can read, draft and suggest freely from day one. The moment it is about to mark an invoice paid or release a payment file, that is the line where a person needs to see it first, and that line does not move just because the agent has been right ninety times in a row.
Run the numbers on a modest case: a business processing 40 supplier invoices a month at an average of 180 dollars each has about 7,200 dollars a month moving through that step. One wrongly auto-approved duplicate payment, a single invoice matched twice because two emails described the same delivery, costs more in the time spent chasing a refund from a supplier than the entire month's worth of the agent's drafting work saved. The arithmetic only works if the step that actually releases money stays gated, because the agent's speed is worth little once a person has to unwind a mistake it was never supposed to be able to make alone.
What does human in the loop actually mean in an AI agent workflow?
Human in the loop means an agent pauses before an action and waits for a named person to approve, edit or reject it, with nothing moving until that person responds. This is a stricter standard than "human on the loop," where a person monitors a dashboard and intervenes after the fact if something looks wrong, and it is a different category entirely from full autonomy, where the agent acts and only logs the result.
The pattern is already showing up in commercial products, not just internal policy documents. OpenAI's Agents SDK marks a tool call as needing approval, and when no decision exists yet for that specific call, the run pauses and surfaces the pending request as an interruption, naming the agent, the tool and the arguments, instead of guessing or failing silently; a person approves or rejects it, the run is converted into a saved state, and resuming from that state continues the workflow exactly where it stopped rather than restarting the task from the first step (OpenAI, Agents SDK documentation, 2026). Stripe's Link agent wallet, shipped at Sessions 2026, works the same way on the money side: an agent submits a spend request with the what, why and how much, and only after a named person approves does Stripe release a one-time-use credential scoped to that transaction, the raw card number never reaching the agent at all (Stripe, 2026). The harness around the model, the loop, the memory, the checks described in what an AI agent is, is also where this pause-and-wait step lives; without it built into the agent harness from the start, bolting it on after a mistake is the expensive way to learn the lesson.
Why doesn't "add an approval button" keep a human in the loop?
Adding an approval button does not keep a human in the loop once volume rises, because the person clicking it stops reading what they are approving. Anthropic's own account of building Claude Code's auto mode states plainly that users approve 93 percent of permission prompts in practice, a rate Anthropic frames not as confidence but as approval fatigue, the same pattern behind the stat image below (Anthropic, 2026). Anthropic goes further and warns that for someone who genuinely reviews every action carefully, swapping that judgment for an automated classifier is "arguably a regression," since the classifier will sometimes get it wrong too (Anthropic, 2026). The honest reading of their own data: a pop-up a person clicks ninety-three times out of a hundred without reading closely is not oversight, it is a formality with a timestamp.
The Cloud Security Alliance's own April 2026 survey makes the same point from the other direction. Asked what happens when an agent exceeds its authorized scope, 38 percent of organizations said the action requires human approval, 24 percent said it gets logged, and only 11 percent said the agent is automatically blocked (Cloud Security Alliance, April 2026). Put the two findings side by side: most businesses believe they have a human checking the edge cases, but the actual stop mechanism, the one that works regardless of whether a tired reviewer clicks approve, exists in roughly one case out of nine. An approval button is not the same thing as a human in the loop. Real oversight is a design decision about which actions are even allowed to reach a person's queue, not a count of how many prompts they see in a day.
Where oversight already fails: two failures with the same shape
Two documented failures, one involving a chatbot's promise and one involving a trading algorithm, share the same root cause: nobody was positioned to catch the system before it crossed a line it was never supposed to cross alone.
Case: the promise nobody checked In November 2022, a grieving customer asked Air Canada's website chatbot about bereavement fares. The bot told him to book a full-price ticket and claim a retroactive discount within 90 days, a policy the airline does not actually offer. Air Canada refused the refund, argued in front of the BC Civil Resolution Tribunal that the chatbot was "a separate legal entity" responsible for its own words, and lost. The airline was ordered to pay 812.02 Canadian dollars in damages, interest and fees in February 2024 (BC Civil Resolution Tribunal, reported by the Washington Post, 2024). The amount was small. The design gap was not: nothing in the chatbot's workflow routed an unusual, binding promise to a person before it reached the customer.
Fourteen years earlier, and with much higher stakes, Knight Capital Group's automated trading system started routing orders through eight years of dormant test code after an incomplete software deployment. In 45 minutes on August 1, 2012, the system executed millions of unwanted trades across 154 stocks, and nothing in the deployment caught the runaway code before it had traded for the full 45 minutes. The result was a pre-tax loss of roughly 440 million dollars and the end of the company as an independent firm within days (Knight Capital Group, August 2012). Neither system was an "AI agent" in the current sense, but both show the same gap this article is about: a system was allowed to act past its intended boundary, and no person was positioned, by design, to catch it before the damage was done.
The scale is different, a few hundred dollars against several hundred million, but the design flaw is identical: in both cases, a working stop mechanism existed on paper and did not exist in practice when it mattered. Air Canada could have routed any promise involving money back to a human before it reached the customer; Knight Capital could have had a tested kill switch that any engineer on shift knew how to pull. Neither cost was about the technology failing to work as built. Both were about where the business chose, or forgot to choose, a point where a person could still say no.
What does the law actually require, and does Cambodia have a version of it yet?
The EU AI Act is the clearest binding answer so far: Article 14 requires that high-risk AI systems be designed so a person can understand their limits, stay alert to automation bias, correctly read their output, and stop them through something like a "stop" function, with enforcement phased in from December 2027 and August 2028 depending on the system category (EU AI Act, Article 14). The US counterpart, NIST's AI Risk Management Framework, asks organizations to define oversight roles (GOVERN 3.2), document the oversight process itself (MAP 3.5), and measure whether it is actually happening (MEASURE 2.8), but it remains a voluntary framework with no penalty for skipping it (NIST AI RMF 1.0).
Cambodia is closer than it looks, but what it has is a different kind of right, not a different size of the same rule. The draft Law on Personal Data Protection, published by the Ministry of Post and Telecommunications in July 2025 with penalties reaching 600 million riels, does include a human-oversight clause: Article 34 gives a data subject the right to request human involvement when an automated decision produces legal effects that impact their legitimate interests (MPTC, draft law, 2025; dgcbriefings, 2025). That is narrower than it sounds. It is a reactive right the individual has to invoke after the decision is made, the same shape as GDPR's Article 22 in Europe, not a proactive design duty the business must build in before the system ever runs, which is what the EU AI Act's Article 14 demands of high-risk systems. A business can satisfy Cambodia's draft text and still ship an agent with no stop button, no documented oversight role, and no one checking an action before it reaches the customer, as long as a data subject never files the request. The National AI Strategy 2025-2030 names ethics and governance among its six priorities, which signals intent without yet setting a binding design-stage oversight rule either (OECD.AI policy registry, Cambodia's National AI Strategy 2025-2030).
Our view: a business here should build the oversight structure the law does not yet require as a design duty, because the operational risk, a wrong refund, a bad message sent in the company's name, does not wait for the regulation to catch up, and retrofitting a stop point after a mistake costs more than designing one in from the start. It also matters for any Cambodia-based business with a French or EU parent or client: Article 14's stop-button and automation-bias requirements can reach a Cambodian operation through a contract clause or a group policy well before Phnom Penh has a binding version of its own, so a locally built agent should assume the stricter standard rather than the absent one.
Which AI agent decisions need a human in the loop?
Not every decision needs a human, and treating all of them the same is exactly how approval fatigue sets in. A workable split, consistent with how the 53 percent of organizations running a mixed model actually operate (Cloud Security Alliance, April 2026), sorts actions into three tiers:
- Auto-approve: reversible, internal, no money or customer contact. A draft reply, an internal summary, a first-pass categorization. Mistakes here cost a re-run, not a customer or a riel.
- Log and sample: medium stakes, usually reversible but visible outside the business. A standard reply sent to a known customer, a routine reorder within an approved budget. A person reviews a sample after the fact, not every instance before it. A guesthouse running 15 automated booking confirmations a day might sample one in ten each week, about ten messages, rather than reading all 105; the goal is catching a drifting pattern early, not re-approving a message that already went out.
- Approve before it happens: money moves, a customer receives a binding promise, or a record cannot be undone. A refund, a KHQR transfer, a contract term, a deleted file. Nothing proceeds without a named person's yes.
Picture a hypothetical, labelled as such because no TechFlow client has run this exact build yet: a 20-room guesthouse in Siem Reap runs a payment-reconciliation agent against its KHQR feed, checking roughly 15 bookings a day against the bank feed at under a dollar of compute cost per check. A scan times out and reads as unpaid, though the $45 transfer cleared seconds later on the bank's side. Under the three-tier split, flagging the order and drafting a message sits in auto-approve; actually telling the guest their booking is cancelled, or issuing a refund that was never owed, sits in approve-before-it-happens. The same agent, two different tiers, because one action is a draft and the other touches money and a customer at once. Running all 15 daily checks through a pre-approval queue would bury the one owner-manager checking it under 450 approvals a month for a problem that shows up a handful of times a year; routing only the mismatches, maybe two or three a week, keeps the queue short enough that each one still gets read.
How TechFlow scopes the approval layer, not just the agent
An AI agent build at TechFlow starts with a free process-mapping audit, one to two hours, before a single workflow gets built. That audit is where the tiering happens: every candidate action the agent would touch, a reply, a reconciliation, a payment file, gets sorted into auto-approve, log-and-sample, or approve-before-it-happens before the costed action plan goes out five days later. Deployment then runs one to four weeks depending on scope, longer again when sovereign hosting is part of the requirement, since keeping data in-country adds four to eight weeks on top of the build itself. A monthly report tracks what the agent actually did against what it was authorized to do: how many actions ran in each tier, how many approve-before-it-happens requests a person actually rejected or edited rather than rubber-stamped, and how many log-and-sample items the weekly sampling caught before a customer noticed. That rejection and edit count matters more than the raw volume, because a tier where nobody has corrected the agent in two full reporting cycles is the one that is actually ready to move down, not the one that merely ran without incident. The same cadence lets a tier move from approve-before-it-happens to log-and-sample once the pattern holds, rather than on day one's optimism.
Because our builds orchestrate through n8n and route reasoning through OpenRouter across Claude, GPT, Mistral and Llama rather than locking a client to one vendor's model, the approval step itself is not tied to a single platform's notion of a permission prompt either. That matters once a business wants the tier map audited independently later, by us or anyone else, since the log of what needed approval and what did not lives in the workflow, not inside a closed product.
We would not let a first production agent touch anything irreversible unsupervised for its first weeks of real use, no matter how clean the pilot looked; the tier only widens once the monthly log proves it, not because the demo went well. An AI readiness assessment run before the build, alongside the AI agent security checklist once it is live, both feed the same tier map this audit produces.
The open question nobody in this market has a clean answer to yet is whether a buyer without a technical background can tell a genuinely tiered approval layer from a decorative approval button before signing anything, since both look identical in a demo and only diverge once real volume hits. Our recommendation: ask any vendor, including us, to show the tier map for a candidate agent before the first line of a workflow gets built. That tier map is what our AI agents team produces during the process-mapping audit, before any build starts. Book a call with them to map one process first.
Prefer to chat? Message our founder directly on Telegram (@maxgrolier), or book a call with the team.
Frequently asked questions
Does human in the loop slow an AI agent down?
For the tiered actions that need it, yes, by design: a refund or a payment waits for a named person's yes rather than clearing instantly. For everything sorted into auto-approve or log-and-sample, the agent runs at its own speed, which is the point of tiering instead of reviewing every action equally.
What's the difference between human in the loop and human on the loop?
Human in the loop means the agent pauses and waits for approval before acting. Human on the loop means a person monitors results after the fact and intervenes if something looks wrong. The first stops a bad action before it happens; the second catches it, at best, right after.
Can a small business run human in the loop without hiring someone new?
Usually yes, for a narrow, well-scoped agent. The tier map from a process-mapping audit tells a business which actions genuinely need a person's click and which do not, and for most SMEs that turns out to be a handful of actions a day, not a full-time reviewer role.
Does human oversight disappear once an agent proves itself?
Not entirely, but the tier can move. An action that starts in approve-before-it-happens can shift to log-and-sample once a monthly report shows a clean pattern. Money-moving and customer-facing actions still deserve periodic sampling even after that, since the Cloud Security Alliance's own data shows only 11 percent of organizations catch an out-of-scope action automatically.
Is a simple approval pop-up enough, or does it need to be more structured?
A pop-up alone tends to become a formality once volume rises, the same approval-fatigue pattern Anthropic documented in its own product. What holds up is deciding in advance, by tier, which actions even reach that pop-up, so the person approving is seeing genuinely consequential decisions rather than ninety-three approvals a day they stop reading.
How does TechFlow decide which actions need approval during a build?
Through the free one-to-two-hour process-mapping audit that starts every AI agent engagement: each candidate action gets sorted into auto-approve, log-and-sample, or approve-before-it-happens before the costed plan is written, and the monthly report afterward tracks whether that tiering held up in practice.
