Human-in-the-loop automation: how to design the review step

An automated refund workflow can check an invoice, calculate an amount, and prepare a payment request. Someone may still need to decide whether the refund is justified. Human-in-the-loop automation puts that decision inside the workflow: the software prepares the work, waits for a person, and uses their answer to choose what happens next.

The difficult part is the wait. The reviewer may be away, the worker may restart, or the underlying request may change before anyone answers. A useful design accounts for those events before connecting the workflow to a system that sends money, publishes content, or changes access.

This guide covers the workflow design. For AI agent tool boundaries, read the human-in-the-loop AI agents guide. For implementation code, use the n8n human-in-the-loop tutorial or LangGraph interrupt tutorial.

What human-in-the-loop automation means

A human-in-the-loop workflow includes a point where a person's input affects the result. That input could be approval, a correction, a choice between options, or missing information. It can be part of a conventional rules-based workflow or an AI system.

For an approval workflow, the protected operation waits until the person authorizes it. Sending a notification after the operation has finished is a different kind of oversight.

Consider these illustrative uses:

These are design examples, not customer results or evidence that approval alone makes a workflow safe.

Choose which requests need a person

Start with a decision rule that an operator can explain. For refunds, that might be an exception to the normal policy. For publishing, it might be the first public release of a document. The rule should identify a reason for review that the request can show to the person answering.

Avoid routing every routine step to the same reviewer. A queue full of low-value requests consumes the time needed for difficult ones. Equally, a model's confidence score alone does not tell you the impact of a mistake. A confident request can still target the wrong account.

Write down the allowed automatic path, the review path, and the conditions that require stopping work. Choose thresholds from your own operating policy. A dollar amount copied from an example says nothing about your customers or risk tolerance.

Write the request before building the workflow

The reviewer needs to understand what will change and why their answer is needed. "Approve task 8472?" makes them investigate. "Refund $425 for duplicate invoice 8472?" gives them a decision, provided the supporting evidence is available.

Use this worksheet to define one review step. It is a planning template, not an API payload:

Operation to review:
Exact record, version, or destination:
Proposed change:
Reason this request needs a person:
Evidence the reviewer can inspect:
Who is allowed to answer:
Deadline and reason for it:
What rejection does:
What happens if nobody answers:
What changes would require a new review:
How execution success or failure will be recorded:

Include enough context to judge the operation without copying credentials or entire customer records into the request. If a person needs information that you cannot safely include, provide an appropriate authenticated path to inspect it.

Separate waiting, deciding, and executing

Your workflow needs to remember the proposed operation while the person considers it. The approval record and the execution record have different jobs: one records permission, and the other records what the software actually did.

Store this information in the system responsible for running the workflow. An approval service does not automatically preserve a worker's local variables or reconstruct a lost execution.

In ActionBox, the hosted service stores the human request and decision. Your integration owns the job and performs the approved operation. The integration architecture explains that boundary.

Decide what happens when nobody answers

A deadline should reflect how long the proposal remains useful. A deployment window can close. A customer can cancel their request. Leaving an approval open indefinitely may produce an answer to a question that no longer applies.

For an operation that requires explicit permission, reaching the deadline should stop execution. Assign responsibility for checking the unresolved business request separately. Expiration is not proof that someone handled the underlying problem.

ActionBox supports an expiration time on a request. Follow the expiration and timeout documentation when configuring it. Your workflow must still handle network failures and local timeouts without treating them as approval.

If a reviewer asks for a change, compare the revised proposal with what they originally saw. A different amount, destination, or document version may require a new decision. Do not apply permission for one operation to another.

Make retries safe on both sides of approval

Suppose the workflow creates a request but loses the HTTP response. Retrying should recover that logical request instead of asking a second person the same question. ActionBox supports idempotency for this purpose; keep the request identity and payload stable when retrying, and respect the documented retention window. Persist the returned Action ID so recovery can read the existing request. See idempotency and dedupe.

There is a separate retry problem after approval. A payment provider might accept a refund before your worker loses its connection. Retrying the payment blindly can repeat the effect even though the human approved only once. Use the downstream system's idempotency mechanism when available, or reconcile its result before retrying.

If you receive decisions through ActionBox callbacks, verify the signature and deduplicate deliveries. Delivery is at least once. A callback that arrives twice must not cause the protected operation to run twice. The callback documentation describes verification and the decision binding to check before continuing.

Choose an implementation that fits the existing workflow

Start with the system that already owns the work. A native review step may be enough when it reaches the right people and retains the decision where you need it.

For example, n8n documents Gmail approval messages and human review for AI tool calls. LangGraph provides interrupts and checkpoint-based resume for graphs. These solve different parts of the problem.

An external approval service is useful when several workflows need a shared place for people to answer. ActionBox supplies that request and decision layer while your existing workflow continues to own execution. Use the n8n guide for an HTTP workflow, the LangGraph guide for graph interrupts, or the webhook integration guide for an application receiving callbacks.

Test the paths that happen after the demo

Before connecting a real side effect, test rejection, no response, a changed proposal, a worker restart, and duplicate delivery. Also test approval followed by a downstream failure. A green approval screen should not hide a failed operation.

Measure how many requests need clarification, how long they wait, and how often they expire. If people repeatedly ask for the same missing field, improve the request. If requests expire because nobody owns the queue, change the assignment process before shortening the timer.

Start with one operation and a reviewer who can explain the decision. Create a free Source, then follow the ActionBox quickstart to connect the request to your workflow.