Human-in-the-loop for AI agents that isn't theatre

Human-in-the-loop (HITL) is used loosely, so it helps to separate three arrangements. In the loop: a person decides before the agent's action takes effect. On the loop: the agent acts, and a person monitors and can intervene or reverse. Out of the loop: the agent acts and nobody looks, except perhaps in a later sample.

All three have a place. Reading a document needs nobody. Drafting an invoice can run with a person on the loop. Posting a ₹40 lakh payment, closing a fraud alert or changing a customer's bank details should have a person in the loop. The design question is not whether to have human approval, but which actions get which arrangement, and why.

For agents, in-the-loop approval has a precise meaning in this guide: a named person decides before a consequential change is made, with enough context to say no, and that decision is recorded.

Approval steps fail in four recognisable ways.

• Everything is asked. When every action needs a click, approvers learn that clicking is the job. Volume turns review into ritual.
• The request is unreadable. The approver sees a paragraph of model output, not a before-and-after view of the record. A person cannot meaningfully refuse what they cannot read.
• The requester approves. If the person who asked the agent to act is also the one who approves, the approval adds no independent check.
• Automation bias. People tend to accept a system's suggestion, especially under time pressure. Research on human use of automation, such as Parasuraman and Manzey (2010), describes this complacency and bias in detail.

The EU AI Act names the last of these directly: Article 14 requires that people overseeing a high-risk system remain aware of the tendency to over-rely on its output. A design that ignores these failure modes produces records of approvals that prove very little.

Banking solved a version of this problem long ago with the maker-checker principle: one person prepares a transaction and a different person authorises it. For AI agents, the model is the maker. The checker must be a person who is independent of the request, competent to judge it and has the authority to refuse.

Three practical rules help. Name the approver by role and by person, so the record shows who decided, not just that someone did. Prevent self-approval in the system, not by policy alone. And give approvers the authority to say no without escalation, otherwise refusal is theoretical. Article 26 of the EU AI Act asks deployers of high-risk systems to assign oversight to people with the necessary competence, training and authority, which is the same idea in legal form.

For high-stakes cases, use two checkers. The AI Act itself does this for remote biometric identification: under Article 14(5), no action is taken on an identification unless at least two competent people have verified it separately. See how a named approver works for operations teams, and maker-checker for banks for decisions on alerts and disputes.

Decide the threshold per process, before the agent goes live, and write it down as a rule. Five factors set it.

An example: accounts payable

Take an agent that prepares supplier payments for a fictional manufacturer, Kolam Components*. A sensible first design might let it prepare any payment, pay invoices under ₹50,000 to known suppliers within agreed terms on its own, and hold everything else: payments above ₹50,000, any first payment to a new supplier, any change to a supplier's bank details, and any payment where the invoice and the purchase order disagree. The bank-detail rule matters most, because it is the classic route for payment fraud and the change is hard to reverse once money has left.

Review the thresholds after a month. If the controller approves 300 payments a week and refuses none, the threshold is probably too low; if refusals cluster on one rule, that rule or the agent's data needs attention. Illustrative specimen. Not customer data: the figures are examples, so set yours with the process owner and your auditors.

Many teams express the result as an autonomy level per process, from “propose only” to “act within limits and report”. Whatever scale you use, record the level that applied on every action, so a reader can see why a person was or was not asked.

An approval request should answer five questions on one screen, in this order:

1. What will change: the record, the field, the old value and the new value, as a diff.
2. Why it was held: the rule and its version that triggered the hold, in plain words.
3. What happens next: the consequence of approving, such as “₹4,20,000 leaves the current account on 14 October”.
4. Who asked and for whom: the agent, the person or process it acted for, and the reason it gave.
5. What refusing does: the change does not happen, and the requester is told why.

Anything else is optional context. Approvers who must scroll through a model's reasoning to find the amount will stop reading. For an example of the layout, see a write held for a named approver, an illustrative specimen.

Most incidents happen at the edges: the rule that does not cover a new case, the approver on leave, the confidence score that is missing because an upstream service timed out. The safe default is to stop the change and ask a person, never to proceed because nothing said no.

Write this as an explicit rule: if no rule matches, if no approver is reachable within the time limit, or if a required input is missing, the change waits. Record the stop as an outcome in its own right. A pause that is recorded is evidence that the control works. We explain the reasoning in fail toward a human.

Approvals arrive by console, email, chat app or phone. More channels mean faster decisions but also more ways to impersonate an approver. Two rules keep channels honest. First, every channel reaches the same approval, with the same checks and the same record; a channel adds reach, not power. Second, apply step-up authentication in proportion to the change: a high-value approval by phone should require a stronger check than a routine one in a logged-in console.

Plan for absence. Every approver role needs a named deputy, set up in advance rather than improvised when someone is on leave. Delegation should itself be recorded, with its start and end dates, so that a reader can see why a deputy approved a given change. Never let an absent approver turn into an approval by default.

Set time limits too. An approval request that waits indefinitely invites someone to find a workaround. When the limit passes, the change should expire or escalate to a named deputy, and the record should show which.

An approval that is not recorded is an opinion. The record should hold who approved or refused, when, through which channel, against which rule version, what they were shown and what happened next. Link each record to the one before it so later edits are detectable, and keep refused and expired requests as well as approved ones.

Before going live, check the design against a short list:

• Each process has a written threshold, agreed with its owner, and the rule that implements it is versioned.
• Approvers are named, with deputies, and the system prevents a requester from approving their own change.
• The approval screen shows the diff, the rule that held the change and its consequence on one view.
• Missing rules, unreachable approvers and missing inputs stop the change rather than letting it through.
• Every channel reaches the same approval with step-up for high-value changes.
• Approved, refused and expired requests are all recorded and linked.

Then measure the control itself. Track approval rates, time to decide and the share of approvals made in under a few seconds. A rate near 100% with very fast decisions suggests the threshold is too low or the request too hard to read.

Article 14 of Regulation (EU) 2024/1689 requires high-risk AI systems to be designed so that people can oversee them effectively. The people assigned must be able to understand the system's capacities and limits, stay aware of over-reliance, interpret its output, decide not to use or to override it, and interrupt it through a stop procedure. Deployers must assign that oversight to competent people under Article 26.

Following the amendments in Regulation (EU) 2026/1744, these duties apply to Annex III high-risk systems from 2 December 2027. Even where your agent is not high-risk, Article 14 is a useful checklist for designing approvals. Our page on EU AI Act Article 14 maps it to controls, and the NIST AI RMF asks for the same thing in voluntary form: defined roles for human-AI configurations and documented oversight processes.

In elan1 Govern, every process has a declaration that sets its rules and its autonomy level. A write the rules mark as consequential is held at the autonomy rung for a named approver, and your rules can require that the approver is someone other than the requester. The approver sees exactly what will change before saying yes. If a rule, an approver or a confident input is missing, the write stops and a person is asked.

Approvals can be given in the console or by phone through elan1 Work Voice, which lets a named approver approve by voice with the same checks and step-up as the console. Every outcome, allowed or refused, is written to a hash-chained proof record that is tamper-evident at L1 Guarded, and signed from L2 Attested.