What share of agent actions should need human review?

Low single digits once the policy is tuned; the 2% figure is a design target, not a law. If more than 10% of actions queue, the policy is tighter than the business it governs or the agent is drafting out of bounds. A sustained 0% deserves suspicion too: verify the checks are actually in the send path.

Should the human review before or after the action ships?

Before, for anything consequential. Reviewing transcripts after the fact is monitoring, and its defining property is that the customer saw the action first. The approval queue exists so that order is reversed for exactly the actions where order matters.

Does human in the loop still count as automation?

Yes, and it is what makes the automation durable. Routing 2% of actions to a person is the concession that lets the other 98% run with no oversight cost at all. The alternative concessions are worse: blanket review that defeats the economics, or no review and an incident postmortem.

How fast does the loop need to be on live channels?

Deterministic checks return in milliseconds and the semantic pass in a second or two, so the check itself fits any channel, including voice. Human approval takes minutes, which asynchronous channels absorb invisibly; live chat needs a holding line while the reviewer is paged.

Human in the loop for AI agents: routing the 2% that matters

Published 2026-07-27 · EvalLayer

Human in the loop for AI agents works when a policy layer triages every action and routes only the risky few to a person: clean actions ship instantly, over-authority actions queue for approval, and hard violations stop. The design goal is not more review, it is better-aimed review. In a tuned deployment the queue holds roughly the 2% of actions that carry real commercial risk, reviewers decide each one in seconds from an excerpt, and the other 98% never wait on a human at all.

The two traps

Review everything

Put a person on every outbound message and you have not deployed an agent, you have hired it a proofreader. The economics collapse first, then the quality does: reviewer attention is a wasting asset, and someone approving hundreds of clean drafts a day stops reading them by Thursday. The rubber stamp fails exactly when it matters, because the one bad draft looks like the four hundred good ones. Blanket review quietly degrades into no review while still billing as oversight.

Review nothing

The opposite trap ships faster and ends worse. A 2026 Gravitee survey found 82% of US companies had seen an AI agent go rogue in the previous 12 months. The public incidents are what review-nothing looks like at the moment of contact: an after-hours chatbot negotiated into 80% off an 8,000 GBP order in February 2026, a support bot inventing a licensing policy in 2025 and triggering cancellations before anyone inside the company saw the thread. In both cases a human did eventually review the action. The customer just saw it first.

Triage by decision ladder

The way out of both traps is triage that runs before the send, action by action. Pre-action authorization checks each action against commercial policy and returns one of four decisions:

allow: no violations. The action ships with zero human involvement. This should be the overwhelming majority of traffic.
rewrite: soft violations only, like a missing disclaimer or an unapproved claim. A compliant version is generated and re-checked before it is offered. Still no human.
require_approval: the agent attempted something legitimate but above its authority, like a 25% discount against a 15% cap. The action queues for a person. This is the loop, and it is narrow by design.
block: hard violations, like a forbidden delivery guarantee or a blocked topic. The action stops. There is nothing to review, though the record feeds the postmortem and the next policy revision.

The human is not in the loop for everything. The human is the escalation path for authority, which is exactly how human organizations already work: a rep does not ask a manager to approve every email, only the ones above their signing limit. Where those limits come from, and how severities map to the four decisions, is covered in the guardrails guide.

What the reviewer should see

The naive queue shows the whole transcript and asks "approve?" That recreates the proofreading job the triage was supposed to eliminate. A reviewable queue item is closer to a diff than a document:

The violation, with the offending excerpt. "25% discount" against a 15% cap. Not fourteen screens of chat with the problem buried in turn thirty.
The policy line it violated, inline, so the reviewer compares two facts instead of recalling policy from memory.
The action in one or two lines of context: what it is, who it goes to, what it commits.
Two buttons and a note field. Approve ships the original; reject kills it or sends it back for a rewrite. Either way the decision lands in the audit record with the reviewer's identity and timestamp.

Excerpt-first design is also a privacy control: the reviewer sees the sentence that needs judgment, not every customer's full conversation. Decisions in this shape take seconds, and seconds per item is what makes the latency budget below achievable.

Latency budgets

Each rung of the ladder has a different clock, and channel design should budget for all three.

Deterministic checks (discount caps, spend authority, required disclaimers) run in milliseconds. Every channel can afford them on every action, including voice.
The semantic pass adds one model call, typically a second or two. That fits inside an email send, a quote pipeline, or a chat typing indicator.
Human approval is minutes. On asynchronous channels (email, tickets, quotes) minutes are invisible: an over-cap offer waits quietly instead of shipping. On live chat, give the agent a holding line ("let me confirm that number and come right back") and page the reviewer. The mistake is pretending the minutes do not exist, which ends either with the check skipped or the customer staring at silence.

Measuring reviewer load

The queue is instrumentation, not just workflow. Four numbers tell you whether the loop is healthy:

Queue rate: the share of actions ending in require_approval. Low single digits is the healthy band. Above 10%, the policy is tighter than the business it governs or the agent is drafting out of bounds. A sustained zero deserves suspicion: verify the checks are actually running in the send path.
Approval rate: the share of queued items a human approves. Near 100% means the cap is wrong, not the agent: raise the limit and version the policy change. Near zero means the agent keeps attempting things the business never does, which is a prompt problem to fix upstream of the enforcement layer.
Time to decision: how long items sit before a human rules. This is the number your channel latency promises depend on, and it is the first metric to degrade when reviewer load creeps.
Reviewer minutes per week: the total human cost of the loop. This is the figure that proves the design: an agent doing thousands of actions a month should consume a reviewer-hour, not a reviewer.

Tuning is a cycle: the queue produces data, the data changes the policy, the better policy shrinks the queue. Inside a governance framework, that feedback loop is the difference between oversight as theater and oversight as a control. To see what a queued decision actually looks like, the live demo returns a require_approval card with the violation excerpt attached.