Most human-in-the-loop design is backwards. Teams put a person in front of the step that’s easiest to review, not the step that’s dangerous to get wrong, and call it governance. The result is a checkpoint that catches typos and waves through the mistake that actually costs money. Get the placement wrong in both directions — over-gating trivial work while leaving the expensive failure unattended — and you’ve built the worst possible version of both approaches.
Where a human has to stay
A human has to stay wherever the agent’s failure is expensive, hard to reverse, or hard to detect after the fact. That’s the whole test — not “is this a big decision” but “if this goes wrong, will we know before it costs us, and can we undo it.” Money leaving the business, anything sent externally under your name at scale, and anything that permanently changes a system of record all fail that test badly enough that removing the human is a bet you shouldn’t take, even with a good agent.
The tell that you’re in this category is asymmetry. A false positive — the agent was right and you reviewed it anyway — costs a few seconds. A false negative — the agent was wrong and it shipped — costs a client, a legal exposure, or a week of cleanup. When the downside is that lopsided, keep the gate even if the agent is correct ninety-nine times out of a hundred. The hundredth time is the one you’re paying for.
Where the checkpoint is theater
A checkpoint is theater when the human approving it has no real basis to say no. This happens constantly with review steps bolted onto agentic systems after the fact, usually because someone senior asked “who’s checking this” and the honest answer was nobody. If the reviewer sees a wall of output they can’t verify against anything and approves it because rejecting it means redoing the work themselves, you haven’t added oversight — you’ve added latency and a false sense of control. I’ve watched this run for months on a client system: approval rate near a hundred percent, cycle time roughly doubled, and the one bad output that got through was approved along with everything else because nobody had time to actually check.
The fix isn’t removing all review. It’s removing review where the human cannot do better than the agent, which is more often true than people want to admit. If a summarization step, a categorization step, or a first-draft step gets checked by someone skimming for vibes, that check isn’t catching errors — it’s laundering responsibility. Better to instrument the output, log it, and spot-check a sample weekly than to gate every single instance on a review nobody is actually doing carefully.
Designing the actual handoff
The handoff itself should carry enough context that the human’s decision takes seconds, not minutes, because a slow gate gets bypassed under deadline pressure regardless of what the policy says. The agent should surface its confidence, cite what it based the output on, and flag the specific part it’s unsure about — not hand over a finished artifact and ask “does this look right.” A reviewer staring at a full document with no pointer to the risky section will either rubber-stamp it or spend twenty minutes re-deriving work the agent already did. Neither outcome is the goal.
This is the part most teams skip when they build their first workflows: they design the automation carefully and treat the human checkpoint as an afterthought, a generic approve-or-reject button dropped at the end. It works in the demo because the demo has one example. It stops working at the tenth edge case, because the button gives the reviewer nothing to act on.
What to actually build
Start by listing every point in the workflow where the agent currently waits for a person, and for each one, write down the specific thing that could go wrong if it didn’t wait. If you can’t name a concrete failure mode, that gate is a candidate for removal or for replacement with periodic sampling instead of full review. If the failure mode is severe and hard to catch downstream, the gate stays — and it deserves real design work on the surface a human sees, not just a button.
Do this exercise honestly and you usually get the opposite of what teams expect going in: fewer total checkpoints, placed where they actually matter, with more context given to the human at each one that remains. That’s the tradeoff worth making — less friction on the common path, a harder and better-informed decision at the point that counts. If you’re rebuilding a process from scratch and want a second opinion on where the gates should actually sit, that placement review is most of what we do in services work, because getting it wrong is expensive precisely at the point you were trying to protect.