The human-in-the-loop pattern: where to put the person

There is a strong instinct that a workflow with a person in it is only half-automated, and that the real version removes them. It is worth resisting. The purpose of automating is not to eliminate human involvement — it is to eliminate human involvement in the parts that do not need judgement, so that attention goes where it actually matters. Designed well, a human checkpoint costs seconds and prevents the failures that would otherwise make you switch the whole thing off.

What the human is actually for

Be specific about the job, because "a person checks it" is not a design. There are only really four things a checkpoint does, and confusing them produces gates that add delay without adding safety.

The approval gate

The automation has prepared an action with a consequence and needs permission before taking it. Issuing a refund, applying a discount beyond a threshold, sending a quote above a certain value, deleting anything. The person is authorising, not checking the work.

The review gate

The automation has produced content and a person confirms it is right before it goes out. Drafted emails, generated summaries, extracted invoice data. The person is checking quality, and this is where a language model step almost always belongs.

The exception gate

The automation could not confidently handle this case and has routed it out. Something did not match, a confidence score was low, a field was missing. The person is deciding what should happen, and this is the gate that lets you ship an 85% automation instead of waiting for a 100% one.

The sampling gate

The automation handled it and a person periodically checks a sample to confirm it is still behaving. Not on every run — on one in fifty, or a weekly batch. The person is monitoring drift, and this is the gate almost nobody builds and most systems need.

Where the checkpoint goes

Place it immediately before the first irreversible or outward-facing step. Not earlier, because you are asking someone to check work that has not been done yet. Not later, because by then the thing you were protecting against has happened.

Concretely, in a workflow that reads an enquiry, classifies it, drafts a reply and sends it: everything up to and including the draft is reversible and internal. Sending is neither. The gate goes between drafting and sending, and the reviewer sees a finished draft with one decision to make.

A useful test: ask what it would cost to undo each step. Steps that cost nothing to undo do not need a gate. The first one that does is where the person goes.

The rubber-stamp problem

Here is the failure mode that undermines most approval steps, and it is a human factors problem rather than a technical one.

A gate that approves 99% of the time trains the reviewer to approve. After two weeks of everything being fine, nobody is reading — they are clicking. The gate now provides the appearance of oversight while providing none, which is worse than having no gate at all, because everyone downstream believes something was checked.

Four things genuinely help.

• Gate less. A gate on every outbound message becomes noise. A gate on messages the system is uncertain about, or that exceed a value threshold, stays meaningful. Fewer, more consequential decisions get more attention than many trivial ones.
• Show the reason. "Flagged because the extracted amount does not match the invoice total" produces a different quality of attention than a bare Approve button. Tell the person what to look at.
• Make rejection easy and useful. If rejecting means writing an explanation into a form, people approve to avoid the friction. One click to reject, with an optional note, and the rejection routed somewhere it improves the system.
• Watch the approval rate. If a gate approves everything for two months, that is data: either the automation is reliable enough to remove the gate, or the gate has stopped working. Both conclusions are actionable and neither is "leave it".

Making the checkpoint fast

A gate that requires opening a laptop will not be used by someone who is on a roof. The gate has to live where the person already is, which for most small businesses means their phone.

Slack supports interactive buttons that post back to your workflow, so an approval can be a message with Approve and Reject that resolves in seconds. For field teams who are not in Slack, an SMS reply or a WhatsApp message does the same job on the channel they already have open.

Whatever the surface, the same three rules apply. All the context in the message — if approving requires opening another system to understand what you are approving, it will be delayed. A default on timeout, chosen deliberately: some workflows should proceed if nobody responds within an hour, others should escalate, and a few should stop. Decide which, rather than letting the workflow hang forever. And a record of who decided what, written somewhere durable rather than left in a chat history that expires.

Where full automation is fine

Not everything needs a person, and gating indiscriminately produces the rubber-stamping problem above. Full automation is appropriate when all four of these hold:

• The action is reversible — or its consequences are internal only.
• The rules are complete — every case maps to a defined outcome, with no residual judgement.
• Errors are detectable — something downstream would surface a mistake before it compounded.
• The cost of being wrong is low — nobody outside the business is affected.

Moving data between internal systems, generating internal reports, updating a record's status, logging, notifying colleagues, scheduling internal tasks: automate these fully. They meet all four tests, and putting a gate on them is how you teach people that gates are noise.

Removing the human later

The pattern is not permanent. It is often the sensible way to start, with the gate removed once you have evidence.

Run the workflow with a review gate for a defined period. Record every decision — approved, rejected, and why. After a few hundred instances you have a genuine measurement rather than an impression: the automation was right 96% of the time, and the 4% clustered in one identifiable category.

That tells you exactly what to do. Fix the category the errors clustered in, then narrow the gate so it only catches that category rather than everything. Repeat. Over time the gate gets narrower and the automation gets broader, and each step is justified by data rather than by confidence.

This is a considerably better path than either extreme — building full automation and hoping, or keeping a person on everything forever because nobody ever measured whether they needed to be there.

If you are still deciding which process to put through this, start with how to decide what to automate first; the high-error-cost candidates are exactly the ones this pattern is for. And the seven failure modes covers what to build around once it is live.