Why AI Workflow Estimates Ignore Review, Correction, Escalation Time

I start with a blunt distinction: the usual estimate has one attractive line, manual handling time minus AI execution time. That line answers the wrong question.

The decision is whether the task is finished after the model runs. If a reviewer checks it, corrects it, escalates it, or waits for it, those minutes belong in the estimate.

What were the actual observed results?

The actual observed outputs of the deterministic reproduction show that the all-in estimate still won overall, but it was materially smaller than the straight-through estimate. Four of 30 tasks were faster manually once review, correction, escalation, and waiting were counted. The rows are synthetic fixtures, so this is a run-level result, not a production rate.

Result table

Measure	Total for 30 tasks	Per task	What the estimate sees
Manual baseline	279.0 min	9.30 min	Human handling counterfactual
AI execution	36.6 min	1.22 min	Straight-through machine step
Naive savings	242.4 min	8.08 min	Manual baseline minus AI execution
Reviewer time	27.0 min	0.90 min	Active checking
Correction or rework	18.5 min	0.62 min	Active changes and bounded reruns
Escalation	17.5 min	0.58 min	Active specialist or owner work
Queue or waiting	37.4 min	1.25 min	Elapsed delay, not paid labor
All-in elapsed automation	137.0 min	4.57 min	Every automated-path component
All-in savings	142.0 min	4.73 min	Manual baseline minus all-in time

Review, correction, escalation, and waiting consumed 41.4% of the reproduction's naive savings.

That is the sourceable result on this page. It belongs to this controlled synthetic reproduction, not to every AI workflow. The row-level data and calculation rules are below so you can replace the values with your own.

Why does a straight-through estimate miss the real work?

It misses the work because the model is treated as the workflow rather than as one segment inside the workflow. The estimate stops when a response exists. The operator stops when the outcome is acceptable and owned.

NIST's AI Risk Management Framework is designed to support trustworthy considerations across design, development, use, and evaluation. Its companion Playbook organizes suggested actions around Govern, Map, Measure, and Manage, while stating that it is not a checklist to follow in full. That distinction matters here: the estimate needs a measurement boundary, not another generic risk list. (NIST AI Risk Management Framework, NIST AI RMF Playbook)

Google Cloud's current agent design guidance asks teams to define task characteristics, latency and performance, cost, and human involvement. It also says predictable or highly structured tasks may be more cost-effective with a non-agentic solution. Those are estimation inputs, not architecture trivia. (Google Cloud agent design guidance)

I use the same distinction when I teach product managers to build and ship instead of stopping at specifications: “done” has to describe the accepted outcome, not the moment a tool returns. That is a teaching observation from Marius Manolachi's product-management work, not a measured success rate. (Marius Manolachi's AI teaching work)

What should an AI workflow estimate count?

Count each task from input arrival to an accepted outcome, and keep active labor separate from elapsed delay.

Field	Definition	Include in active labor?	Include in all-in elapsed time?
Manual baseline	Minutes for a human to complete the same task under the stated counterfactual	Yes	Yes
AI execution	Machine time from invocation to usable output	No	Yes
Reviewer time	Active time checking the output against the acceptance rule	Yes	Yes
Correction or rework	Active time editing, repairing, or rerunning the output	Yes	Yes
Escalation	Active time spent by a specialist, owner, or second-line reviewer	Yes	Yes
Queue or waiting	Time the task is waiting for a worker, reviewer, dependency, or response	No	Yes
Outcome quality	The accepted result, such as pass, corrected, or escalated	No	No, but required for analysis
Manual faster	Yes when all-in elapsed automation time exceeds the manual baseline	No	No, derived

The distinction prevents two common errors. If you exclude review and rework, you overstate capacity. If you charge every minute of queue time as reviewer labor, you overstate payroll cost. Report both views.

What method and sample produced the row-level result?

The method was a dated 2026-08-23 deterministic controlled reproduction of a bounded product-feedback classification and routing workflow. The sample was 30 completed synthetic fixtures, numbered T01-T30. It did not call a production model, use customer data, or measure a live team's timestamps. The values are visible scenario inputs, and the totals and derived findings are the observed outputs of the published formulas.

Each fixture recorded a manual baseline, AI execution, reviewer time, correction or rework, escalation, queue or waiting, a quality label, and whether all-in elapsed automation was slower than the manual baseline. The units are minutes per task, rounded to one decimal place. all_in_elapsed is the sum of execution, review, rework, escalation, and waiting.

ID	Manual	AI exec	Review	Rework	Escalation	Wait	Quality	Manual faster?
T01	8.0	1.0	0.0	0.0	0.0	0.2	pass	no
T02	10.0	1.2	0.0	0.0	0.0	0.4	pass	no
T03	7.0	0.9	1.0	0.5	0.0	0.8	corrected	no
T04	12.0	1.5	0.0	0.0	0.0	0.2	pass	no
T05	9.0	1.1	0.8	0.0	0.0	1.0	pass-after-review	no
T06	11.0	1.3	1.2	0.8	0.0	0.6	corrected	no
T07	8.0	1.0	0.6	0.4	0.0	0.4	corrected	no
T08	10.0	1.2	0.0	0.0	0.0	0.3	pass	no
T09	6.0	0.8	0.5	0.2	0.0	0.7	corrected	no
T10	9.0	1.1	0.9	0.6	0.0	0.9	corrected	no
T11	12.0	1.4	1.5	1.2	0.0	1.2	corrected	no
T12	7.0	0.9	0.7	0.4	3.5	2.0	escalated	yes
T13	8.0	1.0	0.0	0.0	0.0	0.3	pass	no
T14	11.0	1.3	1.0	0.5	0.0	0.8	corrected	no
T15	9.0	1.1	0.8	0.4	0.0	0.5	corrected	no
T16	10.0	1.2	1.1	0.9	0.0	1.0	corrected	no
T17	6.0	0.8	0.5	0.2	0.0	0.6	corrected	no
T18	13.0	1.6	3.0	2.5	4.0	5.0	escalated	yes
T19	8.0	1.0	0.0	0.0	0.0	0.4	pass	no
T20	9.0	1.1	0.9	0.5	0.0	0.7	corrected	no
T21	10.0	1.2	1.0	0.7	0.0	1.0	corrected	no
T22	7.0	0.9	0.6	0.3	0.0	0.5	corrected	no
T23	11.0	1.3	1.3	1.0	2.5	2.3	escalated	no
T24	8.0	1.0	0.7	0.3	0.0	0.6	corrected	no
T25	12.0	2.5	3.0	2.5	3.5	5.0	escalated	yes
T26	9.0	1.1	0.8	0.6	0.0	0.9	corrected	no
T27	10.0	1.2	0.0	0.0	0.0	0.3	pass	no
T28	7.0	0.9	1.1	0.8	0.0	1.4	corrected	no
T29	14.0	3.0	3.5	3.0	4.0	7.0	escalated	yes
T30	8.0	1.0	0.5	0.2	0.0	0.4	corrected	no

The reproduction contains 23 reviewed tasks, 22 with correction or rework, and 5 escalations. Those counts describe this fixture set. They are not expected rates for your workflow.

When does automation win, tie, or lose?

Use the row-level all-in formula first. Then test the mean result against the mean manual baseline and add fixed setup time to the volume calculation.

all_in_elapsed = AI execution + review + rework + escalation + wait
all_in_savings = manual baseline - all_in_elapsed

In this reproduction, mean all-in time is 4.57 minutes against a 9.30-minute manual baseline, so the mean task wins. The four “manual faster” rows show why the mean is not enough for an operating decision. An exception route can erase the benefit on the exact tasks that need the most ownership.

The review-rate sensitivity below holds correction, escalation, waiting, and AI execution at the reproduction means. The fixed non-review portion is 3.67 minutes per task. “Win” means all-in time is below the 9.30-minute manual mean.

Review rate	1 min/review	3 min/review	5 min/review	7 min/review
25%	3.92 win	4.42 win	4.92 win	5.42 win
50%	4.17 win	5.17 win	6.17 win	7.17 win
75%	4.42 win	5.92 win	7.42 win	8.92 win
100%	4.67 win	6.67 win	8.67 win	10.67 lose

At the reproduction's 76.7% review rate, the mean breaks even at 7.35 reviewer minutes per reviewed task under the other base assumptions. That is a useful threshold to measure, not a universal limit.

How does volume change the payback decision?

Fixed setup time creates a volume threshold. With a 240-minute setup assumption, the reproduction yields about 5.98 active-labor minutes saved per task and 4.73 all-in elapsed minutes saved per task.

Monthly tasks	Active-labor net after setup	All-in elapsed net after setup	Decision
25	-91 min	-122 min	loses at this setup cost
50	+59 min	-3 min	active labor wins; elapsed is tied
100	+358 min	+233 min	both views win

The break-even volume is about 41 tasks for active labor and 51 tasks for all-in elapsed time. If the setup takes 480 minutes, double those thresholds. If your measured per-task saving is half as large, double them again.

How can you reuse the calculation worksheet?

Start with a row-level log, not an average. Copy these columns into a spreadsheet or event schema:

Column	Entry rule
task_id	Stable anonymized task identifier
completed_at	Timestamp for the completed task
manual_baseline_min	Measured or carefully reconstructed manual counterfactual
ai_execution_min	Invocation start to usable output
reviewer_min	Active review minutes only
correction_rework_min	Active correction, repair, or rerun minutes
escalation_min	Active specialist or owner minutes
queue_wait_min	Time waiting for a worker, reviewer, dependency, or user
outcome_quality	Pass, pass-after-review, corrected, escalated, or another defined label
manual_faster	Derived from all_in_elapsed_min > manual_baseline_min
all_in_elapsed_min	Sum of execution, review, rework, escalation, and wait
all_in_savings_min	Manual baseline minus all-in elapsed

Then run five checks:

1. Measure at least 30 completed tasks before making the first estimate.
2. Separate machine time, active human time, and waiting time.
3. Keep task-level quality and escalation labels beside the timing fields.
4. Compare straight-through, active-labor, and all-in elapsed savings.
5. Vary review rate, review burden, exception burden, and setup cost before approving scale.

The AI agent ROI guide covers the broader benefit and cost ledger. The queue-backed workflow guide covers the durable execution states that make queue and retry timestamps available. The AI proof-of-concept scoping guide is the canonical parent for deciding whether this measurement belongs in a bounded implementation.

What are the limitations, and what do we still not know?

The main limitation is scope: this does not prove that AI saves 4.73 minutes per task in production. The workflow is synthetic, the manual baseline is a counterfactual, and the timing values are transparent scenario inputs. The result is evidence about the arithmetic of hidden work, not a forecast for a real team.

It also does not prove that queue time should be converted into labor cost. Waiting changes elapsed completion and service capacity. Active reviewer, correction, and escalation minutes change labor capacity. Keep those views separate until the decision requires a financial conversion.

We still do not know how review, correction, escalation, and waiting distribute across a real workflow, whether the manual counterfactual matches observed handling time, how task difficulty changes the burden, or whether this break-even threshold transfers to another team, model, or queue. A real pilot must replace the fixtures with timestamped records before a material investment decision.

The external evidence points in the same direction without supplying this page's numbers. The Alibaba field experiment found that AI deployment reduced average chat duration but lowered ratings for AI-eligible chats, and that intervention effectiveness differed by escalation type and timing. The study makes the practical point that “escalated” is not one uniform cost bucket. (Alibaba field experiment)

The developer oversight study identified four forms of oversight work, including proactive control and real-time monitoring as well as post hoc review. That supports measuring review as work before and during execution, not only as a final approval click. (Human oversight of agentic systems in practice)

What should an implementation leader do next?

Replace the synthetic rows with a dated sample from one bounded workflow. Keep the same columns. Do not approve scale from the happy path.

If you want a team to learn this measurement loop while building its own workflow, Marius Manolachi's AI consulting and tutoring work is designed to make existing people capable of building AI products on their own work. The worksheet remains useful without that next step.