Human review is a queue, not a checkbox.

NIST's AI Risk Management Framework Core does not describe human oversight as a single UI control. Govern 3.2 calls for policies and procedures that define and differentiate roles and responsibilities for human-AI configurations. Map 3.5 calls for human-oversight processes to be defined, assessed, and documented. In the Manage function, resources are allocated to risks, responsibilities are assigned, and systems that produce outcomes inconsistent with their intended use need mechanisms to be superseded, disengaged, or deactivated.

That language changes the design question. The question is not merely, "Can a human approve this?" It is, "Can this organization sustain the role, evidence, response, recovery, and monitoring needed for this class of decision?" A queue is where those commitments become visible. Items arriving faster than the organization can decide are evidence that the stated control is under-resourced.

Google's SRE guidance supplies the operational analogy. Its overload chapters explain that long queues increase latency and consume resources, while overloaded systems may need to degrade service or reject work early. Retries can amplify load into cascading failure. A human queue is not a server thread pool, but the governing dynamics are similar: arrivals, finite processing capacity, wait time, and deadlines. Unlimited intake does not create unlimited review.

n8n's current Gmail node documentation provides a concrete orchestration primitive. A configured human-review step can pause an AI Agent and request approval before an overseen tool executes. The same documentation distinguishes a simple send-and-wait approval from complex approval flows, for which it points users toward the Wait node. That pause is useful plumbing. It still needs an operating contract around the exact proposal, recipient, deadline, and result.

Suppose an automation evaluates 1,000 items per day and routes 8% to review. That is 80 decisions. If a complete review takes four minutes, the queue creates more than five staff hours of work each day before interruptions, handoffs, or follow-up evidence. A threshold that looks conservative in a model evaluation can be operationally impossible. The queue will grow even when every component is working exactly as designed.

Measure at least five signals: incoming review items per interval, completed decisions per interval, age of the oldest item, time from arrival to decision, and the distribution of escalation reasons. Backlog count alone hides severity. Ten low-priority items with a two-day lifetime may be healthy; two payment or access changes near a fifteen-minute expiry may be urgent. Segment by action class and risk rather than presenting one comforting total.

The escalation-reason distribution is also product evidence. If a model update doubles missing-field escalations, the review team should not simply work twice as fast. If a policy change routes most ordinary cases to review, the intended automation has degraded into manual operations with extra latency. Queue data should trigger an upstream investigation and, when appropriate, a rollout pause.

Capacity planning does not require a false promise of precise human behavior. Use observed service-time percentiles and explicit coverage assumptions. Test a burst larger than the normal queue. Ask what work is dropped first, which action classes are disabled, and how source systems learn that a proposal was not accepted. A control that only works at average volume is not ready for production.

A complete review receipt records the proposal identifier and hash, action class, reviewer, decision, reason, decision timestamp, and expiry. The action executor validates that receipt before it uses any credentials. It rejects an expired receipt, a proposal-hash mismatch, an unauthorized reviewer, or an action outside the approved class. This makes the approval a verifiable input instead of a loose message such as "looks good."

Execution creates a second receipt. Store the provider request ID, response status, created object or message ID, operation key, and any later terminal outcome the provider exposes. If the request becomes ambiguous after approval, do not ask the reviewer to approve it again as if the first attempt never happened. Reconcile the provider state first. Human approval authorizes one bounded intent; it does not authorize unlimited transport retries.

Separating these receipts also improves audit quality. The review receipt answers who authorized what and under which policy. The action receipt answers what the system attempted and observed. A business-outcome record answers whether the intended result became true. A green workflow execution is useful operational evidence, but it cannot substitute for all three questions.

Choose a consequential but bounded action, such as sending one class of outbound message or updating one non-sensitive record. Define its proposal schema, policy reasons, reviewer role, SLA, expiry, and receipts. Run in shadow mode first: create review items without executing actions, then compare demand with actual staff capacity.

Move to supervised execution only when reviewers can understand the evidence, decisions are consistent, duplicate claims are prevented, and expiry works. Keep an immediate deactivation mechanism. NIST's Manage guidance explicitly treats disengagement and deactivation as part of responsible risk response when outcomes diverge from intended use. A kill switch is not an admission of failure; it is evidence that the control has an owner.

Expand action classes separately. Approval to send a low-risk draft is not evidence that the same queue can authorize refunds, account access, or irreversible record deletion. Different consequence, evidence, expiry, and expertise requirements deserve different contracts. Keep the review surface as small as the decision allows.