Approve everything and you approve nothing

Thursday afternoon. A team running agents across several harnesses has an approval queue that filled up while nobody was watching it. An engineer opens the queue and starts signing off. Most of the approvals are fine, a one-word change to a metadata tag, a freshly created snip nobody had opened yet, and then a snip rewrite that undid hours of copy work, sitting in the same queue with the same notification shape as everything else, committed on top of edits the team had spent the morning on. It went through with the rest.

The audit trail says approved by human. The human approved without reading, because a one-word tag and a large snip rewrite produced identical notifications. The gate did not fail. The scope did.

An approval never withheld has stopped being a control.

What approval fatigue actually costs a team

The visible cost is friction, reviewer time, interruptions, a queue that never quite empties. That is the version teams anticipate, and the smaller half of the bill.

The real cost is quieter. When every notification looks the same, the reviewer stops discriminating. Attention rations itself. A consequential write lands in the same bin as a routine one, and the bin gets approved as a unit. Nobody decided to approve the snip rewrite, the uniformity did.

This is an economic problem before it is an attention problem. An approval carries information only while withholding it stays a live option. After a few hundred yeses in a row without reading, each new yes adds nothing. The queue can be full of approvals and contain no signal. The team pays for review and receives logging.

None of this happens because anyone is careless. The gate has no discrimination function, so the discrimination gets pushed into the place that degrades fastest, a human reading identical prompts under time pressure.

Why approving everything is the same as approving nothing

The standard fix is to ask for more care, review everything carefully, read each diff, treat every notification as if it matters. It fails for a structural reason. Agents running in parallel produce more prompts than careful review can absorb, and a process commitment that depends on sustained attention degrades under load, not because the team is weak but because attention is the resource being spent.

The fix lives in what the queue contains, not how hard the reviewer tries. A queue where every write asks the same question trains the reviewer to give the same answer. A queue sorted by consequence trains the reviewer to read the ones that made it through. Same reviewer, same attention budget, different structure. The discrimination has to happen before the prompt is written.

The rule: consequence and reversibility decide what waits

Stop sending every write for the same sign-off. Let two properties decide what waits: how consequential the change is and whether it can be reversed.

The first property is blast radius. Does the change mutate durable state that other work builds on, or does it touch something the team can shrug off? A snip rewrite rewrites the shared material that downstream edits sit on top of; a metadata tag changes a label. These are not the same category of event, and a gate that treats them identically has already lost.

The second property is the cost of undo. A wrong approval of a cheap-to-reverse change costs one revert, nearly harmless. A wrong approval of a costly-to-reverse change means rebuilding work, re-opening what the team already closed, paying the rebuild tax. That asymmetry is the whole rule. Consequential and hard to reverse, it waits for a person. Cheap to undo and contained, it goes through.

Everything else is tuning. Teams will disagree about which writes sit in which bucket. The two properties are the decision procedure; the buckets are policy, and policy is the team's to set once rather than relitigate per notification.

What can wait for sign-off, and what can go straight through

Applied to the writes an agent actually makes, the rule sorts cleanly. Snip rewrites and snip patches mutate durable content, and they are expensive to unwind once downstream work has stacked on top, so those wait for sign-off. Creation of new items carries almost no reversibility cost; an unwanted item is deleted, not excavated. Metadata changes carry less. Those go straight through.

The reviewer's queue shrinks to the writes where a human decision actually changes the outcome. The rest stop asking. Fewer prompts for the same reviewer is real relief, but the mechanism is discrimination, and the writes that still ask for attention are the ones that earned it.

The team still draws the line. The platform enforces the boundary it ships with; it does not decide for the team which other writes count as consequential.

Where a server-enforced gate fits the rule

The obvious objection is that a text instruction can carry the same rule. Tell the agent which writes need approval and which do not. This works, until it does not. The agent considers that instruction in context, and under enough conversational pressure, in a long session, it reasons around the rule. Dashed off quickly, worked around for weeks, that is the standard outcome. The instruction is never fully binding, and every agent team re-learns that.

What we built is a pre-application, server-enforced approval gate with three independent enforcement layers that holds a consequential write as a proposal until a human accepts it. The gate does not consider context. It holds. The automatic gate covers snip rewrites and snip patches only; creation and metadata are ungated, and auto-accept must be off.

The second case is the agent that needs a verdict mid-flow. For that we built a Gates primitive that lets an agent route its own output for human sign-off and poll the verdict. Waiting on a person becomes part of the agent's flow instead of a review step someone has to remember. Either way, a person rules before the work moves on, whether the write was intercepted or the agent asked.

What the gate does not decide for you

The gate decides enforcement. Judgment stays with the team. Which changes count as consequential is set at policy time by the people who own the blast radius. The automatic coverage is scoped to snip rewrites and snip patches; creating new items and changing metadata go through ungated. That scope is fixed, and it is not a verdict on where any team's line belongs.

Auto-accept has to be off. A gate that accepts automatically is a log entry with an extra step, and the enforcement layers mean something only when the default is refusal until a human says otherwise. If a team's line sits elsewhere, writes outside the automatic scope reach a person through Gates, before they are applied.

Thursday afternoon, again. The queue is shorter. The snip rewrite sits there, held as a proposal, the morning's edits intact underneath. The metadata tags went through hours ago without asking anyone. The reviewer reads the one prompt in front of them, because it is the only one that made it that far. That is what an approval looks like once it means something again.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Why approving everything is the same as approving nothing" } </script>