Place human decisions where they can still affect the action. Meaningful review needs context, time, authority, an enforced hold and a workable response when approval does not arrive.
What you'll learn
- How prior review differs from monitoring and after-action review
- Why an approval button cannot guarantee a correct decision
- What the reviewer needs to approve the exact proposed action
- How to plan rejection, expiry, backup coverage and manual handling
A human checkpoint must match the action you intend to control. Give the reviewer the exact proposal, supporting information and authority to reject it, with a tested hold and a clear route when nobody responds.
Imagine a vendor promising a human-in-the-loop setup. The demo showed a review queue, approvals at every decision point, a human in the flow. Suppose the agent later sends a client a message with incorrect pricing before anyone reviews it.
The system had a human in the loop. The human was in the wrong place.
Define the role of the person rather than relying on the label. If a particular action needs prior approval, the agent must wait for that decision. Monitoring and after-action review can also help, but neither gives a prior decision on an action already completed.
What does human-in-the-loop actually mean?
For an action requiring prior approval, human-in-the-loop means a person can inspect, reject or authorise that action before it proceeds. Give the reviewer enough information, time and authority to make a real decision. AEPD’s February 2026 guidance recommends defining human checkpoints before sensitive actions and assessing the effectiveness of supervision.[1]
The decision is: at which specific points in a workflow does the agent stop and wait for a human before proceeding? Every other design choice follows from that answer — which actions run automatically, which require review, what the agent does if no response arrives.
Specify whether a product’s human-review feature pauses the action, provides monitoring or only reports afterward. Pre-action checkpoints hold a defined action for a decision. A reviewer can still approve a mistake; the checkpoint needs accurate context and an enforced restriction as well as an approval button.
What are the three places a human can sit in a workflow?
A human can sit at three points in any automated workflow: before an action runs, alongside the process as a monitor, or after the output is produced.
Pre-action placement explicitly holds the defined action before execution. The agent reaches a defined checkpoint, prepares the output — a draft, an update, a scheduled send — and stops. Nothing executes until a human decides. That provides an opportunity to refuse the action before it runs, not a guarantee that every approved action is correct.
Monitoring places a human in parallel with the running process. The agent acts; the human watches. Monitoring can catch errors in progress, but monitoring depends on the human being present and attentive at the moment an error occurs. Monitoring cannot guarantee intervention before an irreversible action completes.
Post-action review happens after execution. The agent acts. A log or notification informs a human afterward. By the time review happens, the message has sent, the record has changed, the deal has moved. It can support investigation, repair and prevention of repeat errors, but cannot provide prior approval for that completed action.
The three forms compared:
| Review type | When the human acts | What it prevents | What it misses | Response window |
|---|---|---|---|---|
| Pre-action | Before the defined action executes | Holds that action until an authorised decision | A reviewer can approve an incorrect action; bypasses must be tested | Set from urgency and actual review capacity |
| Monitoring | During execution | Errors caught while still in progress | Any error that completes before the human notices | Requires continuous attention — not reliable for unattended workflows |
| Post-action | After execution | Can guide repairs and prevent repeats | Cannot give prior approval to the completed action | Set an investigation and correction route |
| Hybrid | Different review for different actions | Holds designated actions and checks completed work | Incorrect classification and mistaken approvals | Define prior-review and follow-up arrangements |
Test the exact action you want held. A notification after sending is useful for investigation, but is not a prior sending decision. Check what happens when the reviewer rejects, is unavailable, receives stale information or cannot open the review request.
Why can HITL setups add work instead of control?
A misplaced checkpoint can leave the action you intended to review outside the restriction. An approval gate on a sent email does not prevent a wrong email from sending. An approval gate placed after sending creates a record of what went wrong.
Another risk is an overloaded review queue. Suppose a business starts with approval gates on consequential actions: outbound client messages, deal status changes, financial updates. After a few weeks, someone adds approvals to internal tags and automated routing decisions. The queue fills with low-stakes reviews. The reviewer stops checking promptly. Consequential approvals start waiting hours instead of minutes.
Every item in the review queue has a cost: someone must read it, decide, and respond. Check whether the queue leaves reviewers enough time to assess consequential decisions. Remove a review only after establishing that the remaining controls suit the action; an internal label alone does not make it harmless.
The third failure is no defined consequence for non-response. The agent prepares a draft and requests approval. Nobody responds within the review window. A poorly designed system either executes the action on timeout or leaves it queued indefinitely — both worse than a clear default. For an action requiring approval, missing approval must not become permission. Agree whether it remains held, expires or escalates to a backup, and who handles any time-sensitive work manually. An expired request should not silently disappear from the business’s workload.
What does a well-designed HITL workflow look like?
Write down which actions wait for a decision, what the reviewer needs to see and what happens after approval, rejection or no response. Test the hold with the exact proposed action, and give the reviewer time and authority to refuse it.
Place the human before the action they need to decide.
First, every action the agent can take is classified as automatic or reviewed. Assess the actual data, destination, permissions and consequences. Internal tagging can affect downstream decisions; a draft can expose sensitive information. Use reversibility and visibility as factors, not automatic permission categories. Write down which actions are allowed without review and why.
Second, the request includes the proposed action, destination, relevant source information and reason it was requested. Let the reviewer inspect supporting records, reject the action or request a correction. Reserve the time the decision needs; a speed target must not replace understanding. If the proposal changes after approval, require a new decision for the changed action.
Third, every outcome is logged regardless of the decision. Approved, dismissed, expired — all three produce a record. The system does not rely on human memory for accountability.
What does escalation actually look like in four illustrative scenarios?
The following four scenarios are hypothetical designs. Choose response windows from the actual business deadline and reviewer availability, not a fixed interval for each action label. Adapt them to urgency, staffing and consequences, and test both the primary reviewer and the backup.
What do four escalation designs actually look like?
Four escalation designs cover an outbound client message, a deal status change, a document delivery and an unrecognised input, and each one says what the reviewer receives and what happens when they do not answer.
Outbound client message. The agent drafts a follow-up based on a pipeline trigger — deal inactive beyond the agreed follow-up interval. The reviewer receives: the draft text, the trigger label, the recipient, relevant source facts and options to approve, reject or request a change. Response window: the agreed response deadline for this follow-up. If no response within the window: the draft expires, the event is logged as unactioned, no message is sent. The owner decides whether a fresh proposal is needed; an expired approval must not authorise a later message.
Deal status change. The agent detects conditions matching the "ready to close" criteria defined in the brief. The reviewer receives: a deal summary, the proposed status change, and Approve / Dismiss options. Response window: the agreed deadline before the proposed status change. If no response: the status remains unchanged, the event is logged, and the owner decides whether a fresh request is needed, avoiding duplicate pending approvals.
Document delivery. A client requests a certificate of insurance or a proposal copy. The agent matches the request to a template and routes it for delivery. The reviewer receives: the exact document and version, recipient, authorisation to receive it and options to approve, reject or investigate. Response window: the agreed document-delivery deadline. If no response: the request remains pending and reaches the backup or manual queue. A holding message is sent only if that separate message type is already authorised and discloses no unapproved information.
Unrecognised input. An inbound message does not match any defined template. The agent cannot classify it. The reviewer receives: the full message text, a "No matching template" label, and options to handle manually or propose a scope review. Adding a template is a separate tested change, not an automatic consequence of approving this case. Response window: the agreed triage deadline. If no response: the message is logged as unhandled and no automated response is sent.
What must each escalation design be tested for?
Every one of the four escalation designs must be tested for what it names: the proposed action, the evidence needed for a decision, the response arrangement and the non-response route. Test rejection and expiry as well as approval. The held action should remain held if its review service is unavailable.
What operational cost do businesses not plan for?
Plan review capacity alongside the agent’s operating cost. Count decision time, waiting, interruptions, corrections and backup coverage. A workflow with sequential approvals depends on those reviewers being reachable.
Observe representative requests before promising a response window. Simple cases and uncertain recipients may need different review time. Include work sent back for clarification and the manual response to expired requests; those are part of the workflow, not free overhead.
For time-sensitive workflows — lead follow-up, client communication, support escalation — the approval checkpoint has a response window. If a draft misses the agreed response window, the owner needs a defined fallback rather than an unattended queue. The person responsible for the queue must be reachable within the window the workflow actually requires.
Build the human side of the system with the same care as the agent side.
How do you configure a human-in-the-loop system before the agent runs?
Agree these decisions before enabling the affected automatic actions. If the workflow is already live, identify and hold actions that need an unresolved review decision, while keeping a manual route available.
Classify every agent action as automatic or reviewed
Write down every action the agent can take — send a message, update a field, create a record, route a request — and classify each as automatic or reviewed. Assess the actual data, recipients, downstream effects and ability to undo an action. Do not treat every internal or reversible action as harmless. If you cannot classify an action clearly, treat it as reviewed until its risk is understood.
Place every reviewed action at a pre-action checkpoint
For each reviewed action, define where in the workflow the agent stops and waits. The checkpoint must sit before the action executes — not after. Test that the action cannot bypass the hold and that approval applies to the exact proposal reviewed.
Provide the context for a meaningful decision
Include the exact proposal, destination, trigger and supporting source information. Let the reviewer inspect details, reject or request a correction. Record what was approved and require a new decision when the proposal changes.
Set a response window and define the non-response default
Set the window from urgency and available reviewer capacity. Missing approval must not authorise the held action. Agree expiry or continued hold, backup escalation and the manual handling of time-sensitive work.
Assign a named reviewer with a backup
Name one person responsible for each review queue. Name one backup. Document when the backup is reachable. A queue with no named owner is a queue that fills silently.
Review the queue and reviewer capacity
Review waiting, rejection, correction and expiry patterns at an agreed cadence and after relevant changes. Reclassify actions only when their actual consequences and remaining controls justify it; keep consequential decisions visible.
Frequently asked questions
What does human-in-the-loop mean in an AI agent system?
Specify where a person must decide before a defined action proceeds. A meaningful checkpoint gives them the proposal, sources, time and authority to approve, reject or request a change. Monitoring and after-action review have different jobs; test the actual pause rather than relying on the label.
What is the difference between pre-action review and post-action review?
Prior review holds the defined action for a decision. After-action review supports investigation and repair after execution. Prior approval is an opportunity to catch a mistake, not a guarantee: the reviewer can approve the wrong proposal, so context, authority and enforcement matter.
Why do HITL setups add work instead of reducing it?
A misplaced hold, an overloaded queue or an unclear non-response route can leave consequential work uncontrolled or delayed. Match review to actual consequences and capacity, with a backup and manual route. Do not remove a checkpoint solely because the queue is inconvenient.
What should be automatic versus reviewed in an AI agent?
Assess data, recipients, downstream effects, reversibility and consequences for each action. Internal tagging or a draft can still matter. Document which actions may proceed without review and which need an authorised decision, then test those boundaries.
Notes
Source accessed 15 October 2026. Opening and escalation scenarios are hypothetical; their time windows and triggers are assumed operating choices. Recommendations are not measured industry practice. AEPD guidance concerns personal-data processing and is not a certification of a particular workflow.
- Agentic artificial intelligence. AEPD; v1.1 February 2026, human intervention and intervention checkpoints.
