Human-in-the-loop AI: the approval that sits between a proposal and a live action

Search for human in the loop ai and you mostly get two pictures. In the first, a person labels training data so the model learns from corrected examples. In the second, a person reads what the model wrote and decides whether it ships. Both are real practices. Neither is the loop an agentic system actually needs.

The reason is that both loops sit around language. The human is the last editor before text reaches a reader, and the worst outcome of a missed review is a bad sentence. That calculus changes the moment an AI system is wired into a payment provider, an identity provider, or a ticketing system. Then the worst outcome is not a bad sentence — it is a refund that should never have been issued, or an access grant nobody requested. Text can be retracted. A transaction has already happened.

So the version of human-in-the-loop worth designing is narrower and harder than the familiar one: a person approves an action before it executes, not after a model has spoken. The loop belongs between the proposal and the execution — not between generation and publication. Almost everything else in this article follows from moving that one boundary.

Concretely, an execution-first system has a chain, and the human sits at a specific link in it. The AI proposes an action. A policy engine checks it. A human approves it when the rules say a human is required. An executor runs it through your own API. The result lands in an audit log.

• AI proposes. A plain-English request becomes a structured, concrete action — a specific refund, on a specific charge, for a specific customer — drafted from your knowledge and your data. Nothing has run yet.
• The policy engine checks. Role first (is this requester allowed to trigger refunds at all?), then the allowed action, then the approval threshold that governs it.
• A human approves — when the rule requires it. Approval is an outcome of the rule, not a reflex applied to every step.
• The executor runs it. Through your own API, against current system state, not against what the model believed the state to be.
• The audit log records it. What was proposed, what the rule decided, who approved, what actually happened.

The model never executes. A policy engine decides where a human is required.

This is a different design centre of gravity from output safety. The question is no longer “is this text acceptable?” but “is this action permitted, by this role, at this size, right now?” That is a question about permissions and boundaries, which is why human-in-the-loop and guardrails on what the agent is allowed to do are two halves of the same mechanism rather than competing ideas.

The naive reading of human-in-the-loop is “a person confirms everything.” It sounds safe. In practice it fails twice.

It fails first on economics. If every action queues behind a person, the agent has not automated the work — it has moved the work into an approval inbox and added a hop. The value of automating repetitive operational requests disappears the moment each one still costs a human decision.

It fails second, and worse, on attention. Approval queues that fill with trivial, low-stakes items train the approver to click through them. Then the one item that genuinely deserved five seconds of thought gets the same reflex as the ninety before it. A loop that produces rubber-stamping is not a safety mechanism; it is a safety mechanism’s paperwork.

Human attention is the scarce resource in the system. The job of the policy engine is to spend it well: let cheap, reversible, well-bounded actions run on their own, and route the expensive, irreversible, or unusual ones to a person who is still fresh enough to read them.

The rules are yours to write, but the criteria that decide them tend to be the same everywhere. Four questions do most of the work.

• What does it cost if it is wrong? Not just money — blast radius. A $12 refund and a $12,000 refund are the same action with different consequences, which is exactly why thresholds are usually expressed in amounts rather than action names.
• Can it be undone? A reversible action (a refund that can be re-charged, a subscription tier that can be moved back) tolerates a lower bar than one that cannot be walked back. Irreversibility is the single strongest argument for putting a person in front of an action.
• How sensitive is what it touches? Provisioning access to a system is not the same as updating a ticket status, even when both are one API call. Actions that widen who can see what deserve a human by default.
• How much do you trust the knowledge behind it? An action justified by a well-maintained, unambiguous policy document is on firmer ground than one inferred from a stale wiki page. If the knowledge source is uncertain, the action inherits that uncertainty.

Two engineering notes follow from this. An action must be validated against current system state at execution time, not at proposal time — the world can move between the two, and an approval that was correct ten minutes ago may not be correct now. And starting with actions that are idempotent or reversible is not timidity; it is how you buy the right to widen the thresholds later, once the log gives you something to widen them with.

This distinction is worth being pedantic about, because most AI systems ship the second one and call it the first.

A chat log records a conversation: what the user typed, what the model said back. It is a transcript of language. It can tell you the model promised a refund. It cannot tell you whether the refund happened, who let it happen, or which rule allowed it. When a finance lead asks why a customer was credited last Tuesday, a transcript is not an answer — it is an anecdote.

An audit log records a decision and its consequence. For each action it holds four things:

• What was proposed — the concrete action, its parameters, and the request that produced it.
• What the rules decided — which policy applied, whether it passed, whether it required approval.
• Who approved it — a named role and person, at a timestamp, or an explicit record that no approval was required.
• What actually executed — the call that ran against your system, and the result it returned, including failures.

The difference shows up when something goes wrong, but it pays off long before that. A log built this way is what makes a policy improvable: you can see which approvals were always granted (raise the threshold), which actions kept failing at the executor (fix the integration, not the prompt), and which requests never should have reached a human at all. It is also the artefact that makes the evidence for an audit easier to produce, because it was recorded as evidence in the first place rather than reconstructed from chat history afterwards. We build for EU-hosted, isolated infrastructure — more about how we think about that — and the log is a first-class part of the design, not a debugging afterthought.

A loop is not just a policy file; it is an operational commitment. Three things decide whether it survives contact with a real team.

Someone owns the rules. Action policies are not a one-time configuration. They are a living document about what the business is willing to let software do — and if no named owner maintains them, they rot into either permanent bottlenecks or permanent rubber stamps. In practice the owner is usually the person who already owns the process: the support lead for refunds, the ops lead for provisioning.

Approvals meet people where they already are. If signing off means opening yet another admin console, the loop adds friction and gets routed around. Requests come in through Slack, Teams, or an embedded chat, and the approval should live in the same place.

Start narrow, widen with evidence. Pick a few high-volume, rule-shaped actions — refunds, subscription changes, access provisioning are the usual first three because the rules already exist in writing — put a human in front of all of them at first, and let the audit log tell you which ones no longer need one. That progression from “approve everything” to “approve what matters” is the whole point of the mechanism, and it is the same progression that separates a genuinely autonomous agent from an ungoverned one.