There is a version of human-in-the-loop that is apologetic: a hedge, a liability clause, a way of saying we do not fully trust what we built. That version shows up as a review step that no one has time for, staffed by someone who was not told what to look for, with no record of what they approved or why. That version is not a feature. It is theatre.
The version that actually works starts from a different premise: that most decisions in any operation are routine, and a small number are consequential. Routine decisions (categorising a transaction, routing a support ticket, flagging a document for review) can and should auto-execute. Consequential decisions (approving a contract, declining a loan, publishing a customer-facing communication) need a named person, with context, and a record. The design question is not whether to have humans in the loop. It is where to put them.
The design question is not whether to have humans in the loop. It is where to put them.
When you get this right, the AI does not slow the organisation down. It frees the organisation to think clearly about the decisions that matter. The reviewer is not reading a wall of raw output; they are reading a structured briefing that the system prepared, with the relevant evidence surfaced and the recommendation stated plainly. Their job is to confirm or override, and either action is logged. Six months later, when something goes wrong, you know exactly who saw what and what they decided. That is not bureaucracy. That is how consequential decisions should work.
The operational benefit compounds. The review log becomes training data. Patterns in overrides reveal where the model is consistently wrong or where the policy is unclear. Teams that build this way learn faster than teams that ship a black box and wait for complaints. They also build trust with the people who use the system, because those people can see the mechanism and know there is a hand on the wheel.
Our own systems are built this way from the start. The approval surface is not an afterthought. It is a first-class piece of the design, alongside the model, the eval set, and the data pipeline. When we propose a system, we specify which decisions auto-execute, which decisions route to a named reviewer, what context the reviewer gets, and how the audit trail is structured. That specification is as important as the model choice. In some engagements it is more important.