TLDR

Human approval of every agent action does not scale; it turns into rubber-stamping and false confidence. Use human-on-the-loop governance instead: agents act within strict limits for low-risk, reversible work, while humans handle exceptions and high-blast-radius decisions.

The approval that wasn't.

A team I worked with had done everything the safety playbook told them to. Every action their agent fleet took — open a ticket, adjust a config, refund a charge, deprovision a node — landed in an approval queue. A human had to click "approve" before anything happened. Human-in-the-loop. Audited. Compliant. The slide said "full human oversight."

Then I watched the human work the queue.

It was 300 items deep by mid-morning and growing. He was clearing it the only way a human can clear a 300-item queue: in batches, by pattern, in seconds. Open ticket — approve. Adjust config — approve. Refund $14 — approve. He wasn't reading them. He couldn't read them and still have a job that involved anything else. His thumb had become a rubber stamp with a pulse.

Somewhere in that morning's batch was an action to deprovision a production database replica. It was sitting between two identical-looking "adjust config" rows. It got approved in the same half-second swipe as everything around it. Nobody read it. The gate was green. The replica was gone.

Here's the part that should bother you: the post-incident review said the process worked as designed. A human approved it. There was a name on the click. The audit trail was pristine. The system did exactly what it promised — it just promised the wrong thing.

A human approving 300 actions a day is not reviewing 300 actions. They're reviewing zero and signing 300. You didn't add oversight. You added a liability sink with a heartbeat.

Approving everything means reviewing nothing.

This is the trap, stated plainly: the more actions you route through a human, the less each one actually gets looked at. Attention is fixed. Throughput is not. Past a certain volume, "approve every action" doesn't mean careful review — it mathematically guarantees the opposite.

And it's worse than just being ineffective. A rubber-stamp gate is actively harmful in three ways:

1. It launders risk as oversight. The org believes there's a human check, so it tolerates riskier agent behavior than it would with no gate at all. The gate's existence raises the org's risk appetite while lowering the actual scrutiny. You've inverted the thing you wanted.
2. It assigns blame without granting agency. The human on the click owns the outcome but has no real capacity to evaluate it. That's not accountability. That's a designated scapegoat with a fast thumb.
3. It trains everyone to trust the green. Downstream systems and people see "human approved" and stop questioning. The stamp becomes a load-bearing lie that propagates confidence it never earned.

The instinct when an agent does something bad is to add more approval steps. That instinct is backwards. Adding gates to a system that already rubber-stamps just adds more rubber stamps. You don't fix a queue nobody reads by making the queue longer.

The safety was never in the click. Watch where it actually lives.

The safety is in the blast radius, not the signature.

Ask the real question about any agent action: if this goes wrong, how bad is it, and can I undo it?

That's two axes — blast radius and reversibility — and they tell you everything about who should be in the loop:

• Small blast radius, reversible. Open a draft ticket. Restart a stateless worker. Tag a resource. Post to a low-stakes channel. If this is wrong, the cost is near zero, and you can roll it back. A human clicking approve here adds latency and learns nothing. Auto-approve it.
• Large blast radius, irreversible. Delete a database. Refund $40,000. Email every customer. Rotate a root credential. If this is wrong, you can't take it back, and it hurts. This is where human judgment is worth its latency. Stop and escalate.

The mistake of human-in-the-loop is treating those two as the same event because they're both "an action." They are not the same event. One is a typo you'll forget by lunch. The other is an incident with a name.

So stop spending your scarcest resource — human attention — uniformly across actions that differ by six orders of magnitude in consequence. Spend it where the blast radius is real.

Build a policy envelope, not an approval queue.

Human-on-the-loop means the agent operates autonomously inside a boundary you defined in advance, and the boundary — not a person — does the routine gatekeeping. You move your judgment upstream: instead of judging 300 actions a day, you judge the rules once and revise them as you learn.

The envelope is just config. Here's the shape of one:

policy_envelope:auto_approve:                  # reversible, low blast radius — agent just acts- action: ticket.create- action: worker.restartwhere: { stateless: true }
    - action: refund.issuewhere: { amount_usd: { max: 50 } }   # typed allowlist, not a vibelimits:spend_per_hour_usd: 500              # hard cap across the whole fleetactions_per_minute: 20               # rate limit catches runaway loopsreversible_by_default: true            # prefer soft-delete, drain, quarantinedry_run_required:                      # destructive verbs never run blind- db.*- node.deprovisionescalate_to_human:                     # the ONLY things that page a person- when: irreversible           # can't be undone- when: blast_radius >= high   # prod data, customer-facing, money- when: out_of_policy          # action or arg not on an allowlist- when: confidence < 0.7       # agent itself is unsure

Read what that config actually does. The refund line doesn't say "refunds need approval." It says refunds up to $50 are auto-approved, and anything above escalates — the allowlist is typed, scoped to a reversible-enough amount. The db.* rule means destructive database verbs can't execute without a dry-run first. The escalation block is short on purpose: a human is paged on irreversible, high-blast-radius, out-of-policy, or low-confidence actions. Nothing else.

That deprovisioned replica? Under this envelope, it never reaches a queue to be rubber-stamped. node.deprovision is irreversible and high blast radius, so it escalates as a single, isolated, loud event — not buried in a batch of 300. The human sees one thing that matters with full context, instead of 300 things that mostly don't.

This is the move I keep coming back to in governed-automation work for B2B and enterprise systems: the control plane isn't a person watching a stream. It's a typed policy boundary that makes the safe path the default path and turns the dangerous path into an explicit, reviewable exception. The human is on the loop, not in it.

Make escalation a real signal, not a fallback.

The envelope only works if escalation is rare and meaningful. If half your actions escalate, you've reinvented the approval queue with extra steps, and you're back to rubber-stamping. Tune for the opposite: the human should see so few escalations that each one genuinely earns a careful look.

Four rules I'd hold the line on:

• Reversible by default. Design actions so the agent prefers soft-delete over delete, drain over kill, quarantine over purge. Reversibility is what lets you auto-approve aggressively. The more you can undo, the more the agent can run free.
• Dry-run anything destructive. Irreversible verbs produce a plan first. A human (or a stricter policy check) approves the plan, not a mystery. You review intent, not aftermath.
• Cap the blast radius globally, not per-action. Spend caps and rate limits bound the whole fleet. Even if every individual action looks fine, the system can't burn $50k or fire 10,000 actions a minute while you're at lunch. This is the guard a per-action human review never gives you — it's continuous, not sampled.
• Treat low confidence as an exception. The agent's own uncertainty is a first-class escalation trigger. "I'm not sure" should route to a human as reliably as "this is irreversible," because an unsure agent inside a wide envelope is exactly how you get a confident mistake.

Get this right and the human's job inverts. They stop being a bottleneck that everything waits on and become an exception handler who sees the five things a day that actually need a brain — with the context to make a real call, not a reflex swipe.

Takeaways

• A human approving everything is reviewing nothing. Attention is fixed; throughput isn't. Past a volume threshold, "approve every action" guarantees rubber-stamping. It's not oversight — it's a signature.
• Rubber-stamping is worse than no gate. It launders risk as oversight, raises the org's risk appetite, and trains everyone to trust a green check that was never earned.
• The safety is in the blast radius, not the click. Tie autonomy to consequence: small and reversible runs free, large and irreversible stops for a human. Those aren't the same event.
• Design the envelope, not the queue. Typed allowlists, spend caps, rate limits, reversible-by-default, dry-run for destructive verbs. Move your judgment upstream to the rules and revise them as you learn.
• Make escalation rare and loud. A human should see the five exceptions a day that matter — irreversible, high blast radius, out-of-policy, low-confidence — with full context, not 300 batched rows.

Stop measuring your agent governance by how many actions a human approves. That number going up is the problem, not the proof. The question that matters: when the action that could actually hurt you fires, does it land in a batch of 300 to be swiped past — or does it stop, alone and loud, in front of someone with the context to say no?