Human-in-the-loop is a control plane, not a confirmation dialog

At 9:14 a.m., an operations agent receives a supplier invoice for $4,820.

It finds a matching purchase order. The amount is within budget. The vendor already exists in the company system. The agent is ready to release payment.

A small window appears:

Approve payment?

The reviewer sees 17 tool calls, a long transcript, and the model’s sentence: “Everything appears correct.”

They click Approve.

That is not meaningful oversight. It is a person being asked to bless an answer without being given a decision.

Human-in-the-loop, usually shortened to HITL, means a person participates in an automated system’s decisions or actions. The common implementation is a confirmation dialog placed immediately before a tool call. That design is attractive because it is easy to build and easy to explain.

It is also how teams create confirmation fatigue, slow down harmless work, and still miss the dangerous mistake.

HITL should be designed as a control plane: the policy layer that decides what requires human judgment, what information makes that judgment possible, and what the system does with the answer. The human is not a decorative lock icon. The human is one component in a decision system.

A confirmation is not a control

Suppose an agent handles 200 payment-related prompts every day. Each prompt asks for one click. The reviewer takes 30 seconds per item, including opening the request and scanning the context.

That is 100 minutes of repetitive approval work.

By the 80th request, “Approve” has stopped meaning “I independently checked the action.” It means “This looks like the other 79.” The reviewer is now a rubber stamp, and the company has bought liability rather than safety.

This is confirmation fatigue. Repetition reduces attention precisely when an unusual request needs it. The problem is not that the reviewer is careless. The interface has turned judgment into clerical throughput.

Naive HITL can be worse than no HITL for another reason: it creates false confidence. People assume the system has a human safeguard, so they may give the agent broader permissions or inspect incidents less carefully. Meanwhile, the reviewer is approving actions with insufficient context.

The answer is not “ask a better question” at the last step. The answer is to decide which cases deserve interruption.

A good policy asks four questions:

1. How reversible is the action?
2. How large is the blast radius?
3. What evidence supports the action?
4. What does a mistake cost?

Model confidence is not a substitute for these questions.

A model may be highly confident that an invoice matches a purchase order. That confidence says little about whether the vendor’s bank account was changed yesterday, whether the purchase order was itself fraudulent, or whether releasing the payment is legally consequential. Even a well-calibrated probability of factual correctness would not tell you the cost of being wrong.

Escalate by consequence, not by vibes

Reversibility means how reliably an action can be undone. Blast radius means how many people, records, dollars, or systems an action can affect.

These are related but different.

A typo in an internal draft is highly reversible and has almost no blast radius. An email sent to 50,000 customers may be technically followed by a correction, but the original message cannot be unsent. A payment to an existing vendor might be recallable, but recovery is not guaranteed. A change to a shared access policy can affect thousands of employees in seconds.

A practical policy can use four tiers. The dollar amounts below are examples for a mid-sized company, not universal laws.

Tier	Example action	Default treatment
0	Read records, compare an invoice, draft a payment	Automatic
1	Add an internal note or send a low-stakes acknowledgement	Automatic, sampled for review
2	Release a verified $4,820 payment to an existing vendor	One informed reviewer
3	Change bank details, pay a new vendor, delete records, or affect many accounts	Two-person approval or block

The important part is not the number of tiers. It is the policy behind them.

The invoice agent can perform Tier 0 work without interruption. It can retrieve the purchase order, compare the amount, check the vendor record, and prepare a payment request. None of those steps changes the outside world.

A low-stakes internal update might be Tier 1. The system can perform it automatically and send a random sample to quality review. Sampling preserves visibility without forcing a person to click through every routine action.

The $4,820 payment is Tier 2 if the vendor identity, account, purchase order, and amount all match trusted records. One reviewer should approve it because money leaves the company, but the action is bounded and the evidence is available.

Changing the vendor’s bank account is Tier 3. The agent may detect that the request is legitimate. It may even have strong evidence. The action still deserves stronger treatment because a successful mistake can redirect future payments and expose the company to fraud.

A policy should also define what happens when a dimension is unknown. If the system cannot establish whether the payment is reversible, treat it as less reversible. If it cannot determine how many records a bulk update will touch, treat the blast radius as high. Uncertainty about consequence is itself a reason to escalate.

This is where agent decision theory helps: the useful quantity is not “How likely is the model to be right?” but “What is the expected cost of letting this action happen without another check?”

Show the decision, not the archaeology

Most agent review screens show the raw trace because the trace is what the system already has.

That is backwards.

A raw trace is useful for debugging. It is usually a poor decision interface. The reviewer should not have to reconstruct a business event from a dozen searches, retries, tool outputs, and model messages.

For the invoice, the review card should say:

Action
Release $4,820 to Northstar Components, vendor account ending in 1842, scheduled for 3 September.

Actual effect
Funds will leave the operating account and create a payment record in the accounting system. The payment may not be recoverable after settlement.

Evidence
Purchase order PO-3817 matches the invoice amount and line items. The invoice was received from the vendor’s recorded domain. The account ending in 1842 has been used for the last six payments. No duplicate invoice was found.

Cost of being wrong
Possible loss of $4,820, delayed supplier relationship, reconciliation work, and a fraud investigation if the account is unauthorized.

That is enough to support a decision in seconds. It also exposes the gaps. If the vendor domain was not verified, the reviewer can see the missing evidence instead of inferring completeness from a confident summary.

The card needs direct links to the source records, but it should not dump every source record into the first view. Detail is available on demand. The first screen should answer four questions:

• What will happen?
• What will change?
• Why does the agent think it should happen?
• What happens if it is wrong?

The controls should reflect real decisions. “Approve” and “Reject” are not always enough. A reviewer may need to approve with an edited amount, request another document, send the case to a specialist, or approve only one step of a larger plan.

The response should therefore be structured. Record the decision type, the reason, any edits, and the reviewer’s role. A free-text note saying “looks fine” is not useful evaluation data six weeks later.

The review interface should also make the boundary explicit. If approving the card authorizes only the payment described on it, the agent must not interpret approval as permission to change the vendor record, pay other invoices, or send a supplier email. Permission should attach to a specific action and scope, not to the vague idea that “the human approved the agent.”

This separation is part of agent safety controls: policy, permissions, and presentation need to agree about exactly what is being authorized.

Review the plan once, not every breath

An agent may need several steps to complete one business action. The invoice workflow might:

1. Retrieve the invoice.
2. Find the matching purchase order.
3. Check the vendor record.
4. Check for duplicates.
5. Prepare the payment.
6. Release it.

Asking for approval after every step produces six interruptions for one decision. A reviewer ends up approving “retrieve invoice” and “check duplicate” with the same attention used for releasing money. The signal disappears.

Review the plan once when the steps are bounded, predictable, and mostly reversible. In the invoice case, the agent can present a plan such as:

Match invoice INV-8842 to PO-3817, verify the existing vendor account, check duplicates, then release $4,820 if all conditions remain true.

The reviewer approves that plan once. The agent can execute the preparatory steps without further interruption, then pause at the external side effect if the policy requires it.

Plan-level approval works when several conditions hold:

• The tools and sequence are known.
• The plan has a clear scope.
• Preparation does not itself create meaningful side effects.
• The agent must stop if a material fact changes.
• The final action is still checked against the approved conditions.

Review every consequential step when the environment is dynamic or the agent is crossing security boundaries. Examples include changing a bank account, granting administrator access, deleting data, sending legal language, or acting on information supplied by an untrusted webpage.

A hybrid pattern is usually strongest. Approve the bounded plan once, then require a checkpoint before each irreversible or high-blast-radius action.

The critical rule is reapproval on material plan change. If the agent discovers that the vendor account differs from the approved account, the amount rises from $4,820 to $48,200, or the action expands from one invoice to 300 invoices, the old approval is no longer valid.

A plan is not a magic spell. It is a scoped authorization with conditions.

Approval should not freeze the agent

Human decisions are often slow. The agent is often fast. That mismatch creates a design trap: the system pauses an in-memory process and hopes the reviewer returns before a timeout, deployment, credential expiry, or worker crash.

Do not make the reviewer a held database connection.

When the invoice reaches a human checkpoint, the workflow should park durable state containing the work item, approved scope, evidence snapshot, policy version, current plan, and an idempotency key. An idempotency key is a stable identifier that lets the system recognize a retry as the same action rather than issuing the payment twice.

The worker can exit. The queue can persist the case. The reviewer can respond two hours later, or the next morning.

When approval arrives, the agent should resume and revalidate facts that may have changed:

• Is the invoice still unpaid?
• Is the vendor account still the approved account?
• Is the amount unchanged?
• Has the approval expired?
• Does the agent still have permission to perform the action?
• Has another worker already completed it?

This matters because approval creates a time gap. Between 9:14 and 2:00 p.m., an invoice might be paid manually, a vendor record might change, or the purchase order might be cancelled. The agent must check the world again before acting.

Durable execution is the infrastructure pattern that makes this reliable: store progress and decisions so work can survive process failure and resume safely. The implementation details belong in durable execution. The policy decision is simpler: an approval is an event in a workflow, not a pause button on a thread.

Set an expiry for approvals. A decision about a $4,820 payment may remain valid for one business day. A decision about access permissions may need to expire within an hour. Expiry forces fresh review when the context is stale.

A decision that disappears cannot improve the system

Teams often record that a human clicked approve and stop there. That throws away the most valuable feedback the system produces.

The invoice workflow should record the policy version, the proposed action, the evidence shown, the reviewer’s decision, the reason, any edits, the final executed action, and the eventual outcome.

A rejection should distinguish “wrong amount” from “missing evidence,” “outside policy,” and “vendor appears fraudulent.” An edit from $4,820 to $482 is different from a request for another document. A reviewer who repeatedly overrides one extraction field has identified a system weakness, not merely expressed a preference.

Approval is not always proof that the agent was correct. A reviewer may approve under time pressure. The payment may still fail later. Conversely, a rejection may be caused by a confusing interface rather than a bad recommendation.

That is why the useful label includes what happened afterward. Did the payment settle? Was it reversed? Did the vendor dispute it? Did a later audit find the source document was wrong?

Those records can produce several evaluation sets:

• Cases where the agent proposed the right action.
• Cases where a human corrected the action.
• Cases where the human requested evidence.
• Cases escalated unnecessarily.
• Cases that should have been escalated but were not.
• Cases where execution changed after approval.

This turns review from operational tax into a learning loop. It supports the evaluation practices described in agent evaluation, including measuring false escalations and missed escalations rather than celebrating a high approval rate.

Protect the data, too. Review logs can contain invoices, customer information, and employee decisions. Store only what is needed, restrict access by role, and define retention. A feedback loop that becomes a second uncontrolled data lake has solved one problem by manufacturing another.

Staffing is the constraint teams discover late

The capacity calculation is not complicated. That is why it is so often skipped.

At 200 requests per day and 30 seconds per review, one reviewer spends 100 minutes on clicks. Five agents produce 1,000 requests, which means 500 minutes, or 8 hours and 20 minutes, before context switching, escalations, meetings, and breaks.

If each case takes an extra 15 seconds to open records and write a reason, that adds 250 minutes. The “30-second approval” has become more than 12 hours of human time.

Latency matters as well. A payment approval queue that waits six hours may cause a supplier discount to expire. A customer-support action that waits until tomorrow may violate its service target. A security action that waits behind routine invoices is not merely slow; it is mis-prioritized.

Policies need service targets by tier. Routine Tier 1 sampling can wait. A Tier 3 security decision may need an on-call specialist. If nobody is available, the system should fail closed for dangerous actions and offer a safe alternative for low-risk work. “No reviewer answered” must not silently become “proceed.”

Track queue age, review time, escalation rate, approval rate, edit rate, and missed-escalation incidents. If the queue grows, do not immediately add reviewers. First ask whether the policy is routing too much routine work, whether the review card is too slow to understand, or whether the agent is generating low-quality proposals.

The goal is not maximum human involvement. It is maximum useful judgment per minute of human attention.

The strongest argument for reviewing everything

The strongest counter-argument is straightforward: agents are unreliable, consequences are hard to predict, and humans are the only accountable decision-makers. Therefore, every externally visible action should require explicit human approval.

That position is defensible in a narrow setting. If the action is irreversible, high-impact, legally sensitive, or poorly understood, requiring a person is sensible. Some actions should remain human-only.

But “review everything” does not create reliable accountability at scale. It creates a queue. Once the queue exceeds human attention, the nominal safeguard becomes routine clicking. The organization then has both slower work and an illusion of control.

A better answer is to keep humans where their judgment changes the outcome: ambiguous evidence, high consequence, unusual scope, and irreversible action. Automate preparation and low-risk execution. Present high-risk cases with enough context to decide. Record the decision. Revalidate before acting. Measure whether the intervention caught anything.

That is a control plane.

What to do on Monday

Pick one agent workflow, preferably the invoice example in your own environment. Write down every action it can take, not just its final goal.

For each action, record its reversibility, blast radius, evidence requirements, and cost of error. Define three or four escalation tiers. Use fixed thresholds where they help, but make the policy conservative when impact is unknown.

Replace the confirmation dialog with a decision card. Put the proposed action, actual effect, evidence, and cost of being wrong above the raw trace. Add choices for edit, request evidence, delegate, and reject where the workflow needs them.

Decide whether the human is approving a plan, a step, or both. State the scope and expiry of the approval. Stop and re-escalate when the plan changes materially.

Persist pending work durably. Store the approval with the workflow state, resume through a queue, and recheck the world before execution. Use an idempotency key so a retry cannot create a duplicate payment.

Finally, log every human decision as evaluation data. Review the cases humans changed, not just the cases they approved. If 99.5 percent of requests are approved, that may mean the agent is excellent. It may also mean the reviewer has become furniture. The data should tell you which.