Human in the loop is not a guardrail if the human always says yes

Ask a team how they keep an agentic workflow safe and the answer is usually "there's a human approval step." It's a good answer. It's also the control most likely to be quietly worthless six weeks after launch, for reasons that have nothing to do with the software.

An approval step only works if the approver has the information, the time, and the incentive to say no. Most implementations provide none of the three.

How a gate decays

The pattern is consistent across organisations.

Week one, every approval gets read carefully. The workflow is new, people are curious, and the volume is low.

By week three, the approvals are mostly correct — because the workflow is mostly correct — and reviewing them feels like ceremony. The approver develops a heuristic: it's usually fine. Which is true, and that's the problem.

By week six, approvals arrive faster than they can be read. They're batched. Someone approves eleven at once from a phone, in a meeting. The gate is still in the diagram. It stopped being a control somewhere around week four.

This is not a failure of diligence. It's the predictable result of asking a person to sustain attention on a stream of events that are almost always fine. Alarm fatigue is a well-documented phenomenon in aviation and medicine, and nothing about putting it in a Slack message changes the psychology.

What the approver is usually shown

Here is a representative approval request:

Workflow customer-offboarding wants to run step 4: delete_records. Approve / Deny

There is no basis on which to answer this. The approver doesn't know which customer, how many records, whether this is routine, or what happens if they deny. The only available strategy is to trust that the system wouldn't have asked if it weren't right — which inverts the entire purpose of asking.

Compare:

customer-offboarding · Acme Corp (acct_8812)
Will permanently delete 1,204 records across contacts, events, attachments.
Triggered by: contract end date reached (2026-09-21)
⚠️ This account's plan is Enterprise — offboarding usually runs on Starter accounts. 14× the median record count for this workflow.
Not reversible. Backup snapshot: snap_20260921_acme.
[Approve] [Deny] [Deny and pause workflow]

Same decision, entirely different quality of decision. The second version does three things the first doesn't: it names the specific blast radius in units a human understands, it flags what is unusual about this instance relative to the baseline, and it tells the approver what their options actually accomplish.

That middle one carries most of the weight. A human cannot evaluate a thousand routine approvals, but they are excellent at noticing that this one is weird. Anomaly flagging is how you convert an impossible attention task into a tractable one.

Designing a gate that survives

Gate on irreversibility, not on importance. Every irreversible action gets a gate; nothing reversible does. Importance is subjective and drifts; reversibility is a property of the operation. If your gate list was assembled by intuition, re-derive it from this rule and you'll usually find both unnecessary gates and missing ones.

Keep the volume low enough to read. A gate firing more than a handful of times a day will not be read. If a category of approval is always approved, that's evidence it shouldn't be gated — let it run, and monitor instead. Spend the attention budget where the answer isn't predetermined.

Make denial cheap and safe. If denying strands the workflow in a broken half-state, or means a customer waits two days, approvers learn that "no" is expensive and stop choosing it. Denial should have a clean, well-defined outcome — the run stops, nothing partial persists, someone is told.

Default to the safe action on timeout. Every gate needs an answer for "nobody responded." Proceeding after an hour of silence means your gate is a delay, not a decision. The default should be to not act, and to escalate.

Attribute the decision. Record who approved, when, and what they were shown. Not for blame — so that when something goes wrong you can tell whether the gate failed or the information did. Those need different fixes, and without the record you can't distinguish them.

Audit the approval rate. This is the single most useful metric and almost nobody tracks it. If a gate has a 100% approval rate over hundreds of decisions, it is not functioning as a control. Either it's gating the wrong thing, or the approvers have stopped reading. Both are findings.

The uncomfortable implication

Taken seriously, this means most workflows should have fewer approval gates than teams initially put in — and those few should be genuinely hard to get through.

The instinct after an incident is to add a gate. It feels responsible and it's easy to ship. But each gate added dilutes the attention available for all the others, and a system with fifteen approval steps is a system where all fifteen get rubber-stamped. Dilution is the failure mode, and it looks exactly like diligence.

The real control isn't the presence of a human in the loop. It's whether that human could plausibly have said no.