Human-in-the-Loop AI: Which Steps Wait for a Person

Ask a vendor whether their AI keeps a human in the loop and the answer is yes, followed by a screenshot of a review dashboard. Ask an operator the same question about a system in production and you get a list of steps, and against each one, whether it runs on its own or waits.

In a deployed automation every step is one of two things. A routine step runs, then reports what it did. A consequential step waits for a named person to approve it before it happens at all. Human-in-the-loop AI is the decision about which steps are which.

The Unit of the Decision Is the Step

The argument usually gets held at the level of the system. Supervised or autonomous is not a question one piece of work can answer, because carrying it from trigger to done runs through eight or twelve steps and they are not alike. Reading an inbound email, extracting the account number, looking up the order, choosing a category, drafting a reply, sending the reply, and issuing the refund are seven different risks wearing one name.

Reading is routine. Sending is not. The same model, in the same run, is trusted with one and gated on the other, for the same reason a company lets anyone open the mail and lets four people sign a check. Autonomy is a dial set per step; so is the gate.

Which steps sit on which side is the company's call, not the software's default. The consequences decide it, and the company is the one holding them.

What "In the Loop" Has to Mean to Count

The phrase gets used for arrangements that do not qualify. Four things have to be true at once.

The person sees what was proposed and why. Not a row in a table. The specific action stated in the terms of the business (this refund, this amount, this customer), plus what the model read to get there. An approver who cannot reconstruct the reasoning is approving a coin flip.

The approval is recorded. Who approved, what exactly they approved, when, and against which proposal. A decision that leaves no artifact is indistinguishable six months later from no decision, which is a problem the first time anyone asks why the money went out.

The approver has the authority to say no. A person who can only comment, or whose refusal gets routed to someone more agreeable, is a reviewer. Reviewers are useful, but they are not a gate.

Nothing consequential proceeds without that recorded decision. The block lives in the code path, not in the policy document. If the step can run while the approval is pending, the approval was advisory.

The arrangement most often described as oversight fails the last one: the automation runs end to end, and a person could read the logs afterward. That catches a pattern across a month. It does not stop the wire transfer that went out on Tuesday.

In the vocabulary we use for gated work, the intent to act is a Record, the account of what was done is a Completion, and a gated step holds until a person renders a Verdict. Notify is what reaches the approver while the work waits. They are named separately because they have separate authors. When AGLedger, whose deployment Tributary supports, tested whether agents could keep their own account of their work, between 0% and 47% of failed writes were reported as successes by the agent itself, depending on the model. An approval that the acting system records about itself is not evidence the approval happened.

A gate also changes what gets finished, not only what gets recorded. Four models were wiped mid-task and asked to pick up work they had already started. All four recovered 0 of 3 items when finishing depended on their own reading of the situation, and two of the four finished 3 of 3 once a deterministic gate carried that decision. A step whose criteria are written down gets picked up again; one that leaves them implicit gets dropped.

Where the Gate Usually Lands

Across the four kinds of work we automate, the line falls in much the same places.

Intake. Almost entirely routine. Reading a message, extracting fields, and filing a document change nothing outside the building. The exception is intake that commits on arrival: an inbound request that opens an order, books a slot, or reserves stock. That is not intake, and it gets gated as what it is.

Triage. Classifying and prioritizing is routine, and so is escalating to a person. When the automation decides a case is out of its depth and routes it to a human queue, nothing was approved and nothing was risked; gating it puts a person in front of the decision to involve a person. The gate belongs further along, where triage assigns money or risk: a refund above a threshold, a claim marked payable, an account marked for suspension.

Drafting. Routine to draft, consequential to send. The approval commonly gets put on the drafting step, so a person waits for permission to produce text no one outside will ever see, and then the send goes out on a rule. The risk is in the outbound message, not the blank page.

Reporting. Routine, except where a report triggers something: a reconciliation that closes a period, a dunning run that emails customers, an invoice batch. The report is routine up to the point where reading it causes an action, and the action is the gated step.

Getting It Wrong Costs in Both Directions

Gate everything and you have built a slower inbox. The work still queues, the approvals pile up, and the approver clicks through them at a rate that makes the gate decorative. A gate that is always approved has stopped reading.

Gate nothing and the arithmetic changes. Most automated actions are cheap to undo: a miscategorized ticket gets recategorized. Some are not. Money that has left, a message a customer has read, a record a downstream system consumed. One unrecoverable action can cost more than the labor the automation saved.

The test that sorts them is reversibility, in three questions per step. Is the effect visible outside the company? Does it move money or commit the company to something? If it is wrong, can the person who would have approved it undo it within an hour, alone? Two noes and a yes is routine. Anything else gets a name attached and waits.

Thresholds do most of the work in practice, and the share that reaches a person is small when they are set well. In one measured run of a gated system, 90% of rule-gated steps cleared with no human involved and 1.66% of all records waited on a person; of the escalations that reached someone, 3,700 were accepted and 146 rejected. Refunds under a limit run; refunds over it wait. New customers wait; existing accounts in good standing run. The threshold is a business decision with a number in it, which makes it reviewable, and reviewing it quarterly against what the automation did is more useful than debating autonomy in the abstract.

A gate is only as good as its rule, and rule slips are silent. In one of our own test exercises on synthetic sanctions-screening data, a tolerance setting placed beside the clear threshold widened the band the rule accepted, and a name that should have stopped for mandatory review cleared automatically. Removing the setting made the gate reject it. Nothing failed loudly; the record simply cleared. Review the rule against what actually cleared, not against what it was meant to do.

This is the same argument as building deterministic scaffolding around a probabilistic core, applied to the one step where the scaffolding is a person. For anyone in scope it is also an obligation: Article 14 of the EU AI Act asks that high-risk systems be designed so a person can understand, intervene, and override, and the compliance timeline sets out when that has to be true and what evidence it takes.

AI automation is software carrying a piece of work from trigger to done with a model handling the judgment steps. The gate is where the company keeps one of those judgments for itself.

If you want to walk your own steps and sort them, tell us what is running.