Human in the Loop Automation: How to Design the Review Step

An AI agent that drafts text is easy to supervise. An agent that updates job records, matches payments and emails customers needs a review step. The common first design puts an Approve button on everything. The queue fills by Wednesday, and by Friday reviewers are clicking through without reading.

Human in the loop automation works when you decide review by action. Sort what the agent can do by how hard it is to undo. Auto approve the safe tier, queue the risky tier, and let rules and calibrated confidence route the middle. Then size the queue to the hours your reviewers have, and log every decision so you can loosen the rules with evidence.

This guide walks through each step for operators putting agents into a CRM, QuickBooks or a field service tool. You get a tier table to copy, a calculator for reviewer hours, the fields a review card needs, and the audit fields we design for.

Step 1: Sort agent actions by the cost of undoing them

Start with a list of every tool the agent can call, then give each one a tier. OpenAI's practical guide to building agents recommends rating each tool low, medium or high risk by its access, reversibility, permissions and financial impact. The OWASP entry on excessive agency names "excessive autonomy" as a root cause of damaging agent actions and recommends human approval for high impact actions.

We use five tiers, because three is too coarse for a service business where a status change and a refund both count as "writes."

Two rules make the table work. First, split tools that mix tiers. "Update customer" becomes "add note" (tier 3) and "merge customers" (tier 4), so the cheap version can run on its own. Second, sending is always a separate action from drafting. A septic company's agent can draft 200 pumping reminders overnight, and the person who reviews them approves one batch in the morning.

The split between who creates an action and who controls its rules comes from ordinary operations software. When we built CurbPricing, a commercial roofing quotation portal for Horizon Roofing, contractors generated and submitted quotes, and admins managed pricing, labor, margins, approvals, users and workflows. An agent fits the contractor's seat in that design. It proposes, and the rules a person owns decide what goes through.

Step 2: Route the middle tier with rules first, confidence second

Tiers 1, 2 and 5 route themselves. Tiers 3 and 4 hold most of the volume, and that's where the routing logic lives. We build it in this order.

1. Hard rules come first. These are checks a person can read and argue with: dollar amount over a limit, a new customer, a field that changed in the source system in the last hour, a mismatch between the agent's answer and the record. Any hit sends the action to the queue, whatever the agent's confidence.
2. Confidence comes second, measured against outcomes. A score earns trust after you check it against what reviewers decided. Research on large language models found that when models state their confidence in words they tend to be overconfident. So we use signals we can test: agreement between two extraction passes, a match score against the CRM, or a classifier trained on past reviewer decisions.
3. A random sample runs underneath both. A small share of auto approved actions still goes to a person. AWS built this into its review service, which sends low confidence predictions or random samples to reviewers. The sample is how you find the errors the agent was confident about.

Set the first threshold from data. Run the agent in shadow mode for two to four weeks: it proposes, people do the work as before, and you log both. Then pick the confidence cutoff where the agent's proposals matched the human decision often enough for that tier. A tier 3 tag can tolerate a miss rate a tier 4 payment match can't, so each action type gets its own cutoff.

Frameworks now support this directly. LangChain's human in the loop middleware lets you set a policy per tool: auto approve, interrupt, or interrupt only when a condition on the arguments is true, with approve, edit and reject as the reviewer's choices.

Step 3: Design a review queue your team can clear

A review queue fails in one of two ways: it grows faster than people clear it, or people clear it without reading. Both come from volume. Studies of automation bias find that people tend to accept automated suggestions even when other information contradicts them, and that holding reviewers accountable for their decisions reduced the effect.

Size the queue before you build it

Work out reviewer hours first. Daily actions, times the share that gets queued, times minutes per review, gives you the daily load. Docsumo's guide to review design gives a useful version of this check: a team that can review 500 documents a day out of 2,000 can route at most 25% to review, and it recommends keeping the backlog within two to three days of what reviewers clear.

Remember the spot check sample too. Auto approved actions still send a slice to review, and at high auto approval rates that slice becomes a real share of the work.

The chart uses example inputs. Plug in your own volume, auto approval rate and minutes per review in our reviewer hours calculator below.

At these inputs, each 10 points of auto approval saves about 6 reviewer hours a week. Cutting review time from 2 minutes to 1 halves every bar, which is why the review card matters.

Build a review card someone can decide in under two minutes

Every queued item should answer five questions on one screen, so the reviewer never opens another tab.

• What the agent wants to do, in one sentence: "Apply $1,240 payment to invoice 10482 for customer 2291."
• The change as old and new values, field by field, in the target system's terms.
• The evidence: the remittance PDF, the bank line, the CRM record, linked or shown inline.
• Why it's in the queue: "Amount over $1,000" or "Customer name matched at 78%." Reviewers who see the reason know what to check.
• What happens on approve, and how to undo it.

Give three buttons with equal weight: Approve, Edit and Reject. Ask for a reason code on Edit and Reject; those codes become your list of what to fix in the agent. Sort the queue by risk and age, and put a time limit on each tier, with escalation to a named backup when an item sits too long. Batch similar items so a reviewer can approve 20 matching reminders after checking a few.

Step 4: Log every decision so you can explain it later

The audit trail answers the question someone asks after a mistake: what did the agent see, what did it propose, who approved it, and what changed in which system. If you can't answer that in a few minutes, the review step gave you no protection. The EU AI Act's Article 14 on human oversight asks for the same abilities in high risk systems: people must be able to override or reverse an output and stop the system in a safe state, and they must stay aware of the pull to over rely on it.

These are the fields we log for every proposed action, whether it ran on its own or went through a reviewer.

The action ID matters more than it looks. Shopify's docs warn that an app can receive the same webhook more than once and recommend checking the X-Shopify-Webhook-Id header before processing. An approval is an event too. Reviewers double click, sessions retry, and a queue tool can resend. Store the ID and check it before the write.

Regulated work shows why the log belongs in the first design. On the New York Lottery data pipeline we built in 2025, encrypted files moved through AWS ingestion and batch processing for a system reaching over 6 million users. At that scale, you need to be able to say which file went through which step. An agent's actions deserve the same record.

The log also feeds the next step. Every reviewer edit is a labeled example of what the agent got wrong, and the share of approvals with no edits, by action type, is the number that tells you when to loosen a rule.

Step 5: Roll out in stages and loosen one action type at a time

Move the agent toward autonomy one action type at a time, with a number behind each move. OpenAI's guide says high risk actions should trigger human oversight until confidence in the agent's reliability grows. Here is the sequence we use.

1. Shadow mode, weeks 1 to 4. The agent proposes and people work as usual. Compare proposals to what people did, per action type.
2. Queue everything at tiers 3 to 5. Reviewers approve, edit or reject. Track the clean approval rate (approved with no edit) for each action type.
3. Auto approve one action type. Pick the tier 3 action with the highest clean approval rate and a cheap undo. Keep a random sample going to review.
4. Watch the sample and the error log for a full cycle. For billing actions, that means one month end. If the sample stays clean, move to the next action type.
5. Keep tier 5 in the queue. Customer messages, refunds and deletes keep a named approver. As volume grows, batch them so one person approves a reviewed set at once.

Also give the agent a failure threshold. The same OpenAI guide recommends limits on retries and escalation when the agent keeps failing, such as when it can't understand a request after several attempts. An agent that has tried three times to match a payment should stop and hand the item to a person with its notes attached.

Tighten when the numbers turn. A rising edit rate on an action type that was auto approved usually means something upstream changed: a new price list, a renamed field, a new crew. Move that action back to the queue until you know why.

FAQ

What is human in the loop automation?

Human in the loop automation is a workflow where software or an AI agent does the work and a person approves, edits or rejects selected actions before they take effect. The design question is which actions need that person and how to route them.

Which AI agent actions should always need human approval?

Actions that leave your systems or can't be reversed: messages to customers, refunds, payments, deletes and record merges. Keep a named approver on these even after the agent has a strong track record, and batch them as volume grows.

What confidence threshold should I use for auto approval?

Pick it from your own shadow mode data, per action type. Log the agent's score next to the human decision for two to four weeks, then choose the score above which proposals matched the human call often enough for that action's risk. A model's stated confidence tends to run high, so test any score against outcomes first.

How many reviewers do I need?

Multiply daily actions by the share that gets queued and by minutes per review, then compare that to the focused hours your team can give each day. Plan for peak days such as month end. Our calculator in Step 3 does the math on your inputs.

How do I keep reviewers from rubber stamping?

Keep queue volume low enough that each item gets real attention, show the reason each item is in the queue, make Edit as easy as Approve, and hold reviewers accountable for decisions. Research on automation bias found that accountability for decisions reduced it.

What is the difference between human in the loop and human on the loop?

In the loop, a person approves an action before it runs. On the loop, the agent acts on its own and a person monitors results, samples actions and can stop the system. We usually design for both: in the loop for costly actions, on the loop for reversible ones.

Start human in the loop automation with one action type

A good review step lets the agent handle the safe work on its own and sends your people the few decisions that need judgment, each with the context to make it in a couple of minutes. Every decision lands in a log you can audit and learn from. The agent earns more room one action type at a time, backed by approval data, and every customer message has a named approver.

If you're planning an agent that writes into your CRM, accounting or field service tool, we can help you map its actions into tiers and size the review queue before anything goes live. Send us the workflow and we'll review a small set of your records and show where review belongs. You can also see how we build AI agents and integrations.

Sources

• A practical guide to building agents, OpenAI, 2025
• LLM06:2025 Excessive Agency, OWASP Gen AI Security Project, 2025
• Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs, Xiong et al., arXiv, 2023 (revised 2024)
• Using Amazon Augmented AI for Human Review, Amazon Web Services
• Human in the loop, LangChain documentation
• Article 14: Human Oversight, EU Artificial Intelligence Act, 2024
• Verify webhook deliveries, Shopify developer documentation
• Automation bias, Wikipedia
• Human in the loop systems: how to design review that holds up in production, Docsumo