---
type: "post"
id: "human-approval-has-a-speed-limit-7ea753"
slug: "human-approval-has-a-speed-limit-7ea753"
title: "Human Approval Has a Speed Limit"
description: "Ted Tschopp’s essay turns human review into a capacity-planning problem for teams scaling AI workflows."
retrieval_nugget: "Ted Tschopp’s essay turns human review into a capacity-planning problem for teams scaling AI workflows. Its worked examples show how to estimate incoming review demand, compare it with protected reviewer time, and account for rework before an overloaded queue quietly weakens the control it was meant to provide."
published_at: "2026-11-07"
updated_at: "2026-11-07"
record_date: "2026-11-07"
date_kind: "published_at"
topics: ["workflows","org-design","engineering-management"]
entities: ["Ted Tschopp","Review Capacity Lab","Microsoft","AWS","U Mobile","Copilot Cowork"]
related_patterns: ["ai-native-orgs-move-to-review-and-orchestration"]
novelty_label: "new_fact"
what_changed: "The essay quantifies how review capacity can fall behind AI-generated work, showing that 24 five-minute reviews per hour require two full-time reviewers and can create a growing backlog."
prior_refs: ["https://newruntime.com/posts/when-ai-moves-faster-than-the-organization-analysis-61d4a8/"]
source_url: "https://tedt.org/Human-Approval-Has-a-Speed-Limit"
source_urls: ["https://tedt.org/Human-Approval-Has-a-Speed-Limit"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:human-approval-has-a-speed-limit-7ea753"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/human-approval-has-a-speed-limit-7ea753/","markdown":"https://newruntime.com/posts/human-approval-has-a-speed-limit-7ea753.md","json":"https://newruntime.com/posts/human-approval-has-a-speed-limit-7ea753.json"}
markdown_url: "https://newruntime.com/posts/human-approval-has-a-speed-limit-7ea753.md"
---

# Human Approval Has a Speed Limit

## Retrieval answer

Ted Tschopp’s essay turns human review into a capacity-planning problem for teams scaling AI workflows. Its worked examples show how to estimate incoming review demand, compare it with protected reviewer time, and account for rework before an overloaded queue quietly weakens the control it was meant to provide.

## Summary

Ted Tschopp’s essay turns human review into a capacity-planning problem for teams scaling AI workflows. Its worked examples show how to estimate incoming review demand, compare it with protected reviewer time, and account for rework before an overloaded queue quietly weakens the control it was meant to provide.

## What happened

In “Human Approval Has a Speed Limit,” published November 5, 2026, Ted Tschopp asks how much work can reach a review queue before review stops being credible. His opening example starts with 120 requests an hour. If an AI system sends 20% to a person and each review takes five minutes, the queue receives 24 reviews per hour, requiring 120 minutes of human attention. Two qualified reviewers would have to spend the entire hour checking work simply to keep up, leaving no time for other responsibilities.

The article extends the example across an eight-hour day: 960 requests generate 192 cases for review, or 16 hours of reviewer effort. If two reviewers can each protect only four hours for that queue, the team has eight hours of capacity and eight hours of new work remain unfinished each day. In Tschopp’s averaged model, the backlog grows to 80 hours over ten workdays. He contrasts that arrangement with two reviewers protecting eight hours each, which exactly meets the 16-hour demand but leaves no spare capacity, and three reviewers at eight protected hours each, which creates eight hours for existing work or variation. These are illustrative calculations, not staffing recommendations.

Tschopp gives a basic formula: daily review demand equals requests multiplied by the fraction requiring review and average review minutes. Daily capacity equals qualified reviewers multiplied by protected review hours and 60. Comparing the two helps teams see whether new work exceeds available time. He suggests that organizations can choose to admit work below full capacity—for example, an 80% planning threshold—and calculate an intake limit from that assumption. In his example, eight available review hours become a 6.4-hour new-work budget, equivalent to 384 requests per workday when each request creates one expected minute of review work. The 80% figure is an assumption to test, not a safety standard.

The calculation must include returned work. If 25% of cases need one additional four-minute pass after an initial five-minute review, average effort rises to six minutes per reviewed case. At the example’s 192 cases per day, demand increases from 16 to 19.2 hours, while the two reviewers still have 16 hours of capacity. Tschopp also says to separate specialist queues when only some reviewers can judge particular exceptions, and to measure the full review—including gathering context, checking evidence and follow-up—not just the approval click.

The essay describes a browser-based Review Capacity Lab where users can change reviewer counts, protected hours and re-review assumptions, inspect a daily table, and export a scenario and workload timeline. It uses averaged daily totals; it does not predict actual waiting times, reviewer fatigue, decision quality or the effects of bursts of difficult cases. Tschopp recommends tracing requests from arrival to finished outcome, observing the work, and replacing initial assumptions with measurements.

## What the archive adds

New Runtime’s September 27, 2026 [earlier coverage](https://newruntime.com/posts/when-ai-moves-faster-than-the-organization-analysis-61d4a8/) argued that enterprise AI capability depends on the working system around a model or agent. Tschopp adds a specific operational measure to that broader point: protected review hours against incoming workload. This is a new fact on a known story, not a restatement.

## Trend signal

This supports the view that human review and verification capacity can bind how much work a team ships as agents accelerate implementation. The relevant New Runtime pattern, [AI-native organizations move toward review and orchestration](https://newruntime.com/patterns/ai-native-orgs-move-to-review-and-orchestration/), holds; this essay makes the review constraint measurable through demand, protected capacity and rework rather than leaving it as a general operating-model concern.

## Why it matters

A human approval step is often treated as a safeguard that can simply be added to an AI workflow. Tschopp’s arithmetic shows why that assumption fails at scale: the control is only real if qualified people have enough time, context and authority to exercise it. If work arrives faster than reviewers can inspect it, a growing queue, overtime or thinner review may become the hidden cost of automation.

For teams, the useful consequence is to make intake capacity part of workflow design. A bounded queue, dispatch limit or pause can prevent an agent from creating more review work than the organization has committed to handle. That does not mean rejecting every request when the queue is full: customer acknowledgement, escalation and time-sensitive exceptions still need owners. The calculation gives teams a way to expose those choices before launch, and to revisit them when reviewer availability or rework changes.

## Limits and uncertainty

The examples use assumed request volumes, review shares and durations; they are not measurements from a deployed organization. The 80% intake threshold is explicitly a planning example, not a demonstrated safety level. Tschopp’s lab averages daily totals and does not model actual waiting-time distributions, fatigue, decision quality or bursts of difficult cases. The essay also describes Microsoft’s Copilot Cowork account and an AWS–U Mobile helpdesk account as examples of human review points, but neither establishes how much review traffic those workflows can absorb. Teams need local observations before using the arithmetic to set operating limits.

## Skill to build now

This week, map one AI-assisted workflow from request arrival to finished outcome. Sample actual requests and record how many reach a person, who is qualified to review them, protected review time, complete active review effort, return passes, and existing backlog age. Separate elapsed waiting time from hands-on effort, and ask reviewers to challenge the estimates. Then calculate daily demand and capacity, including rework, and identify who decides what happens when the queue is full. Treat the first result as a planning hypothesis to improve, not permission to expand an agent’s authority.

## Reader takeaway

Before increasing what an agent can produce, calculate what qualified people can responsibly review. Count the whole job—including context gathering and returned work—and protect time for it. A review gate without enough capacity is not a dependable control; it is a queue whose limits the team has not yet chosen.

## Open question

What review-load threshold should teams use for different kinds of decisions, and how should they validate it against real queue delays and decision quality?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Workflows](https://newruntime.com/topics/workflows.md): Explore the workflows topic hub.
- topic hub: [Org Design](https://newruntime.com/topics/org-design.md): Explore the org-design topic hub.
- topic hub: [Engineering Management](https://newruntime.com/topics/engineering-management.md): Explore the engineering-management topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)