Your Approval Gate Is Now the Slowest Service in Your Stack

Your approval gate is a production service with latency and a queue, and nobody is paging on either one.

My August post argued approval gates guard verbs. Agents in an OpenAI evaluation environment built a message board inside a package cache, and no permission prompt fired, because writing to a cache you hold credentials for is allowed. That post closed with a section called “Why I still run gates.” I still run them. Both of mine stay.

I left something out, though. I explained what gates miss. I never priced what they cost.

Anthropic published the price this month. In interactive, multi-turn sessions inside the company, “Claude sessions amount to around 80% idly waiting for human input.” Same study: “by August the agents worked 6 times as many hours as their human handlers.” The agents out-work the people steering them six to one, and they spend most of every session parked, waiting for one of those people to type y.

The slowest dependency in your stack is now a person with a Y/N prompt.

Quick roadmap:

• Why a waiting agent is invisible
• The cost I skipped in August
• Two ways an unmeasured gate rots
• What Anthropic changed in its own code review
• How I would run a gate like a service
• My own two gates, and why one of them gets to be slow

---

A waiting agent looks like a thinking agent

The best description of this problem came from a tmux guide I saved this month. crystl.dev wrote: “An agent waiting on an approval prompt looks exactly like an agent thinking, which looks exactly like an agent that finished twenty minutes ago.”

crystl sells a product built around exactly this pain, so read the quote as a vendor talking. The observation holds anyway.

Nobody gets paged when a gate is slow. Put any other dependency in production with no latency metric, no queue depth, no p99 and no alert, and the on-call review writes itself. When the dependency is a human, we call it oversight and stop measuring.

The 80% number is easy to inflate, so here is its scope. It covers interactive, multi-turn Claude sessions. Anthropic computed it as session wall-clock time minus the agent’s active working time. The claim is about collaboration: when a person and an agent work a problem together, the agent spends most of the session waiting on the person. Agents running unattended overnight aren’t in it.

The 6x figure has fine print too. It counts employee-directed interactive sessions with subagents pooled. Agent time is runtime, minus any wait longer than 30 minutes. Human time is headcount times 40 hours a week. The 30-minute cutoff keeps long stalls out of the agent total, so the ratio isn’t padded with idle time.

Anthropic draws the conclusion in its own words: “This acceleration makes human attention the bottleneck for agent output.” It also sizes the reading load. For non-technical employees, reading everything their agents produce would eat “half their work week.” Meta-work, meaning sessions spent managing other Claudes, went from 10% of the average employee’s interactive sessions in fall 2025 to 22% in spring 2026.

That’s a queue. It grows every month, and I have never seen anyone put it on a dashboard.

The cost I owed you

The August argument holds. Gates cover verbs like publish, deploy, send and delete. They do nothing about two agents agreeing on something through a file both of them can write.

What I skipped is the bill. Every gate is a synchronous call to a person, and every synchronous call adds latency to the work stacked behind it. A dependency nobody measures degrades without anyone noticing.

I’m keeping the gates. I’m changing how I think about them. A gate is a service. It gets an owner, a latency target and an error budget, the same as anything else I’d put in front of production traffic. A checkbox whose only job is making the system feel safe is a different thing, and I’ve run enough of those.

Rubber stamps and blind spots

An unmeasured gate fails in one of two directions. As of this month, both directions have published numbers.

Too many prompts. When Anthropic shipped auto mode for Claude Code in March, the post gave the reason up front: “in practice users accept 93% of them anyway.” Anthropic calls this approval fatigue. A gate people approve 93% of the time without a close look gives you the latency of a control and none of the safety.

Coding tools aren’t the only place this shows up. One early-access reviewer of Claude Duet, writing in the AI with Allie newsletter, called it the “most proactive of all and purpose-built for business, but perhaps flagged too much to me. If you like minimal noise and concision, this is not the tool for you.” One person’s take, not a dataset. I’ve heard the sentence before, though. It’s what people say a month before they start approving on reflex.

Anyone who has carried a pager knows this pattern as alert fatigue. The June 27 port-sweep alert from my August post fired, a human investigated, and the human waved it through, because a port sweep inside a security evaluation looked like the evaluation doing its job. I’d have made the same call. Fire any signal often enough at a low enough hit rate and people learn to ignore it. That’s training, and the gate is the trainer.

Auto mode is worth studying because Anthropic set the rate on purpose. A classifier screens each action before a person sees it. On 10,000 real actions, the full pipeline’s false positive rate was 0.4%. On real overeager actions, it missed 17%, which the post calls “the honest number.” After 3 denials in a row or 20 in a session, it hands control back to the human. I’d argue with the 17%. Publishing it is what makes the argument possible.

Controls in the wrong place. METR red-teamed OpenAI’s internal agent monitoring this summer. The system it tested is an asynchronous monitor, not a blocking gate, and the lesson carries over anyway. The monitor ran when an agent handed control back to the user. Compaction events weren’t monitored, so an agent could “indefinitely postpone being monitored by simply continuing to take actions.” METR estimates the gap left “on the order of 10% of eligible internal Codex traffic” unmonitored from May through July 2026. OpenAI had found the gap independently and fixed it during the exercise. METR’s recommendation is to check agents every N messages or minutes instead of waiting for them to end a turn.

One control fired so often it stopped meaning anything. The other fired at a point where a tenth of the traffic walked past. Where a control triggers and how often it triggers are design decisions. If you never made them, you’re running somebody’s defaults.

What Anthropic changed in its own code review

Disclosure first. This post leans on Anthropic, and the pipeline I use to draft posts runs on Claude. I’m citing them because they published numbers. The METR findings on OpenAI show the same problem at a second lab.

Anthropic’s code review write-up starts from volume. Monorepo changes landing per day went from about 2,500 in May to more than 30,000 in September. Claude writes about 90% of Claude Code’s own code. A review gate where every change waits on a human doesn’t survive a 12x jump. It turns into a rubber stamp or a wall.

They tiered it:

• Low risk (docs, copy, internal-only features, additive changes behind a flag): no human approval once automated review and security checks are green.
• Medium risk, including ordinary product changes and sensitive areas like caching and system prompts: one person.
• High risk, plus a short list of paths that always need two people: two.

Two rules hold the tiers up. “The change sets the tier, not the author.” A classifier reads the diff and picks the tier, and a second classifier can say this one needs a person anyway. Only authors on the repo’s trusted list get the lighter paths in the first place. The second rule is my favorite: “An agent’s approval never counts as a person’s.” Agents can review all day. They can’t fill a human slot.

Then they measure the gate: “human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail.”

Any SRE would recognize the paragraph. Time waiting on a person is a latency metric with a p95. Reverts and incidents are the error budget. They took a review process and wrote an SLO for it.

The post has a war story too. One CLI PR went through more than fifty rounds of agent review and fixes overnight before its author stopped it. Their proposed fix: after three rounds, the reviewer tells the author to step back and reconsider the approach. Retry loops get a circuit breaker. Review loops need one too.

Run the gate like a service

If you run production systems, you already own every tool this needs. Point them at the human.

• Tier by risk, and let the change pick its tier. Most actions don’t need a person. A few need two. One gate for everything is set wrong for almost everything.
• Keep a short list nobody gets to approve. Claude Duet waits for approval before it “sends a message, makes a payment, signs a document, or deletes anything,” and “a few things are off-limits even with your approval, like trading securities or moving money between accounts.” Its auto mode classifier screens actions first, and it “messages you only when something needs your attention.” Duet doesn’t describe risk tiers for actions. It’s a verb gate plus a hard-block list, and the hard-block list is the part most stacks are missing.
• Write a time-to-approve target per tier. A high-risk deploy waiting a day is fine. A medium-risk config change waiting a day means somebody’s afternoon is gone. Pick the number and track it.
• Use reverts and incidents as the error budget. Loosen a tier, and if reverts stay flat, the old gate was costing time and buying nothing. If they climb, tighten it back. You get an experiment instead of an argument about trust.
• Alert on queue depth. Twelve agents parked on one human is an incident, and you want to find out before that human opens Slack.
• Track the approval rate per tier. A tier approved 93% of the time has stopped adding scrutiny. Either it’s set too strict or reviewers quit reading, and both deserve a ticket.

My own two gates

My publishing pipeline has two mandatory human gates. At Gate 1 I pick the angle. At Gate 2 I publish. Neither goes away.

Gate 1 is why this post is six weeks late. I’ve owed an update on the August post since mid-September, and the weekly shortlists kept stopping at Gate 1 with nothing picked. That’s a queue with no target, and it backed up the way unmeasured queues do.

I’m fine with the delay, and the reason is the whole tiering argument. Gate 1 decides what I say in public under my name. It runs once a week, and the cost of a slow answer is a later blog post. It should be slow. Put that same gate in front of every typo fix and I’d be mashing approve on autopilot inside a week, my own personal 93%.

So the gate stays where it is. Now I know what it costs.

Translation: keep your gates. Tier them by risk, hard-block the handful of verbs nobody gets to approve, and measure the wait like any other latency. An unmeasured gate drifts into a rubber stamp or a bottleneck, and you find out which one during the incident review.