An AI service can process a thousand cases while the people responsible for its exceptions are still reviewing the first dozen. Model latency looks excellent. The workflow is getting slower.

Consider a support operation where an AI workflow proposes account adjustments. Most cases follow an approved, narrow automation path. Ambiguous evidence and higher-impact actions require human decisions. A change in incoming documents raises the exception rate from 5% to 8%. Nothing crashes, yet the same traffic now demands substantially more reviewer time. Scaling inference makes the problem worse.

Human review capacity must constrain how much work an AI workflow starts. Estimate the review minutes each case class creates, account for sampling and rework, and admit work against the capacity of qualified reviewers. When that capacity runs out, defer or reduce intake through a defined service path. Approval requirements remain in force.

This is a capacity-design problem for asynchronous business workflows. It assumes that the organization has already defined which actions need approval. The human-in-the-loop approval architecture covers that decision and its execution controls. Here, the question is whether those controls can keep working at the volume the service accepts.

Count review minutes, including the work that comes back

A queue of twenty cases could contain twenty routine checks or twenty investigations. Queue depth alone cannot tell you whether today’s staff can finish it.

Google’s SRE chapter on handling overload explains why request counts are often a poor substitute for actual resource consumption. Applied to human review, the useful planning unit is qualified reviewer time. The application below is a proposed operating design, not a staffing formula prescribed by Google.

Start with distinct sources of human work:

• Mandatory review before an action, including exceptions that require a person to resolve conflicting evidence.
• Quality sampling of cases eligible for automated completion under the existing policy.
• Reopened cases, corrections, second opinions, and investigation of downstream failures.

Count each activity once, but count every visit. A case that needs two approvers consumes time in both pools. A rejected proposal that returns after correction consumes another review visit even though its business case ID has not changed.

For one interchangeable reviewer pool, a simple planning model is:

1
2
3
4
5

review demand (minutes/hour)
  = incoming cases/hour × expected total review minutes/case

available capacity (minutes/hour)
  = qualified reviewers on duty × allocated review minutes/hour/reviewer

Estimate handling time from representative cases, including evidence reading and decision recording. Separate active handling from waiting for a customer or another department. Both affect completion time; only active handling belongs in this labor calculation. Unknown cases need an explicit conservative allowance until measurements improve.

A small exception-rate change can consume the reserve

The following figures are illustrative design inputs, not measured results. Assume 1,200 cases per hour, six minutes for a mandatory review, three minutes for a quality sample, and four additional minutes when a reviewed case reopens. Sampling covers 2% of the cases outside mandatory review. Ten percent of mandatory-review cases reopen once; assume no other rework for this example.

Sixteen qualified reviewers, each allocated 45 minutes of review per hour, provide 720 reviewer-minutes per hour. The allocation already excludes other duties. Suppose the team plans to use at most 80% of that capacity to leave additional room for variable case difficulty and arrival bursts: its operating ceiling is 576 minutes per hour.

The 5% case fits that ceiling. The 8% case exceeds it, even though average demand remains below absolute capacity. There is little room left for an absent reviewer or a difficult batch. Neither 45 minutes nor 80% is a universal recommendation; calibrate both with actual schedules, handling-time distributions, and service commitments.

At the higher exception rate, expected review demand per incoming case is:

1
2
3
4

0.08 × 6 + 0.92 × 0.02 × 3 + 0.08 × 0.10 × 4
  = 0.5672 reviewer-minutes/case

planning intake ceiling = 576 / 0.5672 ≈ 1,015 cases/hour

That is an initial planning ceiling for this case mix with no backlog-reduction allocation. It is not a deadline guarantee. Existing backlog, clustered exceptions, skill restrictions, and changes in handling time can require a lower admission rate. Changing the routing thresholds merely to send fewer cases to people would change the control policy; it is not a capacity adjustment.

Budget each qualified pool against its own calendar

An available support reviewer may not be authorized to approve a credit adjustment. A legal specialist may be able to review only one jurisdiction. A nominally global team can have zero coverage for a particular action overnight.

Maintain capacity by authority, skill, and working window. For each pool, estimate the visits and minutes that every case class generates. Subtract existing commitments and any deliberate backlog-drain allocation before budgeting new admissions. If a person belongs to two pools, divide their available time between them; counting the same hour twice creates fictional capacity.

For dual approval, include both labor demand and the sequencing delay. Two reviewers each spending four minutes is eight reviewer-minutes, but the second decision may wait hours for the right person. Separation-of-duties rules also prevent treating those two roles as interchangeable.

Use a short, explicit planning horizon, such as the next staffed hour, alongside the business deadline. A daily average can conceal a midday surge or a queue that nobody will touch until Monday. If deadlines continue across unstaffed hours, the admission policy has to account for that gap.

This gives the CIO operating model a concrete dependency: a workflow launch needs an owned reviewer-capacity allocation as well as model quota and platform capacity. The process owner commits the staffing and service outcome; the platform team enforces the resulting limits.

Put backpressure before expensive work starts

A message broker can absorb a burst. It cannot create reviewers. Microsoft’s queue-based load leveling guidance explicitly calls out continuing queue growth when average production exceeds consumption and warns that scaling consumers can move overload downstream.

For an AI workflow, enforce two boundaries:

1
2
3
4
5
6
7
8

business intake
  -> capacity admission by case class and reviewer pool
  -> AI processing and deterministic checks
  -> durable review case, if required
  -> qualified human decision
  -> authorized business execution

review workload and deadline pressure -> feedback to capacity admission

The intake check budgets expected human work before inference. The post-inference boundary records actual routing and adjusts the remaining budget. A mandatory-review case must still enter a controlled pending state when the forecast was wrong. Its arrival should reduce or stop new starts, not cause its review to be skipped.

Use a shared budget, or bounded per-worker allocations, so multiple inference workers cannot all spend the same remaining capacity. Limit in-flight AI work as well as the waiting review backlog: cases already running can produce exceptions after intake closes. For workflows where nearly every in-flight case could require review during a common failure, reserve for that burst or set a sufficiently small in-flight bound. An average exception estimate is not a hard queue limit.

Before accepting a case, check whether its projected path can fit its deadline using observed queue delays, handling-time variability, coverage, and upstream processing time. A simple sum of average service times is not a tail-latency promise. Use conservative estimates, then validate them under representative load.

Prefer predictable operating states over a queue alarm that asks people to improvise:

Define trigger and recovery thresholds in versioned configuration. Use different close and reopen thresholds, plus a recovery window, to avoid repeatedly opening and closing admission around a noisy measurement. Urgent work needs reserved capacity and a trusted priority rule; a caller-supplied “urgent” flag should not take the whole queue.

An overflow manual route is useful only if it has its own available capacity. Moving cases into the same team’s email inbox hides the backlog. Deferred work also needs an owner, retention limit, deadline treatment, and a status visible to the requester. “Accepted” must have a specific meaning.

Keep the business case durable beyond the queue message

Human decisions can take hours. Do not make a broker’s message lease the only record that a case exists or is being reviewed.

Persist the review case before acknowledging its notification. Deduplicate creation using a stable business case ID and proposal revision, and recover missed notifications from the case store. Store references to protected evidence rather than distributing sensitive documents through every queue message.

Amazon SQS’s visibility-timeout documentation describes how an undeleted message becomes available again when its timeout expires; standard queues can also redeliver during the visibility period. That transport behavior must not create a second review task or a second business action.

Keep reviewer assignment separate from approval validity. A short renewable claim can prevent two people from editing the same case simultaneously. Accept the decision through an atomic state/version check so an expired claimant cannot overwrite a later review. Closing a browser tab must leave recoverable work.

Carry at least the case identity, proposal revision, required reviewer pool, first-admitted time, current state, business deadline, evidence-validity deadline, and rework count. Preserve the original age across requeues and transfers. Re-enqueueing a case must not make yesterday’s unresolved work look new.

Business ambiguity is ordinary review work. It is different from a malformed event or a worker that repeatedly crashes. Use a technical dead-letter path for those processing failures, with an owner and a bounded redrive policy. SQS dead-letter queue documentation also shows why broker age metrics need interpretation: source and dead-letter age/retention behavior differ. Measure end-to-end case age from the business record.

Before execution, recheck that the underlying record, evidence, policy, and authorization still support the approved proposal. If material inputs changed while the case waited, invalidate that proposal and route the new revision appropriately. Bound regeneration attempts; automatically regenerating every aging proposal can manufacture another wave of reviews. The existing tool-contract pattern supplies the action identity and idempotency boundary after approval.

Measure completed outcomes alongside queue pressure

A falling queue depth can mean successful resolution, expired work, hidden transfers, or indiscriminate approval. Distinguish these outcomes.

Track offered cases, admitted cases, deferred cases, completed cases, and unresolved cases by arrival cohort and case class. Within review, measure active handling minutes, waiting time, oldest case age, remaining deadline margin, rework visits, and coverage by qualified pool. Include work already in inference in the demand forecast.

For reviewer quality, use authorized calibration exercises and independent outcome checks. Compare correction rates and reviewer disagreement as workload changes. Fast approval is not itself evidence of good review. Keep quality-sampling capacity protected during overload; removing the measurement precisely when the workflow is stressed makes the dashboard less trustworthy.

The NIST AI RMF calls for defined human-oversight responsibilities in GOVERN 3.2, assessed oversight processes in MAP 3.5, and consideration of risk-management resources and non-AI alternatives in MANAGE 2.1. A funded reviewer pool and an exercised overflow policy are concrete implementations of those ideas. NIST does not prescribe the utilization target or queue design used here.

Choose a model or prompt change using its effect on the whole workflow. A slightly slower model could lower total cost if it produces evidence that reduces review time and rework. A higher apparent automation rate could increase downstream corrections. Compare equivalent case cohorts, outcome quality, total human minutes, and completed work within deadline before claiming a productivity gain.

Exercise the overload policy with real review behavior

Add human-capacity scenarios to the enterprise AI eval gate. A synthetic consumer acknowledging messages in milliseconds cannot validate a workflow staffed by people.

Use representative, appropriately protected cases and qualified reviewers to measure handling and decision quality. Then replay those arrival and handling distributions in a load model, including correlated exceptions and the staffing calendar. Simulations guide sizing; they do not replace checking that people can actually use the evidence interface.

Before expanding intake, demonstrate these cases:

Record the observed exception mix, human minutes per case, qualified coverage, deadline misses, and the admission configuration used. Have the process owner accept the measured service envelope before raising volume. The useful release artifact is a statement of how much work this workflow can complete under its actual controls, with a tested response when that limit is reached.