The first time an agent tried to send an email on my behalf, I realized that autonomy is not a single feature. It is a spectrum, and one of its most useful control points is the moment before an irreversible action. A mistaken email, a production data deletion, or an unintended payment can cost far more than a 30-second review.
Human-in-the-loop (HITL) is not merely a fallback for an uncertain model. It is a deliberate control mechanism: decide which actions require review, who may approve them, and what happens while the agent waits. A reliable design must solve three connected problems: pausing execution, returning a decision, and preserving state until the agent can safely resume.
Choose the actions that require approval
Requiring approval for every action quickly creates review fatigue. If people must approve routine searches, drafts, or reversible edits, they may stop paying attention to the prompts. At the other extreme, letting the agent execute every action can expose systems and customers to preventable harm.
A useful starting point is to classify actions by their impact and reversibility. Reading a record or drafting a message may need no approval. Sending that message to a large group, deleting a record, changing access permissions, or charging a customer may require review. The boundary should reflect the consequences of an error, not simply the model’s confidence.
For each gated action, define three things:
- The action: What exact operation is waiting for approval?
- The approver: Which person or role has authority to decide?
- The waiting behavior: What may the agent do while approval is pending?
Keep the approval request narrow. “Approve this plan?” is difficult to evaluate. “Approve sending this email to 248 customers, with this subject and body?” gives the reviewer the context needed to make a decision. If the action depends on data that could change, include a timestamp or version so the reviewer knows what they are approving.
Pause at a safe boundary
Pause before the side effect, not after it. The agent can prepare an action, validate its inputs, and present a proposed operation, but it should not perform the protected step until approval arrives.
The safest pause point is usually a task or tool-call boundary. Persist the proposed action and its inputs, then stop the worker. Avoid keeping a process alive in memory while it waits for a person: approval can take minutes or hours, and the process may be interrupted by a deployment or machine restart.
While paused, the agent must not silently continue the same task through another route. If sending an email requires approval, it should not send it through a different tool or ask a second agent to do so. Make the pending action explicit in the workflow state, and enforce the gate at the execution layer as well as in the agent’s instructions.
Return decisions through an explicit workflow
For a short, interactive task, a synchronous approval prompt can work. For production workflows, approval is usually asynchronous: the system creates a review request, notifies an authorized person, and waits for a decision delivered through a webhook, queue, or polling endpoint.
Treat the decision as a structured event, not free-form text. A minimal record might include:
{
"request_id": "req_7f2c",
"action_id": "send_email_104",
"decision": "approved",
"approver_id": "user_42",
"decided_at": "2026-09-28T03:15:00Z"
}
Use a unique request ID and make decision handling idempotent. If a webhook is delivered twice, the second delivery must not execute the action again. Check that the approver is authorized for this action, and record the decision with the exact action version it applies to. If the proposed action changes after review, require approval again.
Approval does not have to be a simple yes or no. Depending on the task, useful outcomes may include approved, rejected, needs changes, or deferred. A conditional approval should spell out its conditions in machine-readable form where possible; otherwise, the agent may interpret the reviewer’s words differently from what they intended.
Set a timeout policy before deployment. If no one responds within, for example, 30 minutes, the system might escalate to another approver or leave the action pending. For high-impact operations, the safe default is usually to avoid execution until approval is recorded. That reduces availability, but prevents silence or a delivery failure from being mistaken for consent.
Preserve state across the wait
A paused agent needs more than its conversational history. It needs a durable record of the workflow: the task, completed steps, pending action, relevant inputs, tool results, approval request ID, and the version of the policy or prompt used to create the action.
Store this state outside the worker process, typically in a database or durable workflow engine. Serialize it in a versioned format so a later version of the application can restore it. For example, a workflow saved as schema version 3 can be migrated when resumed by code that expects version 4.
Separate the proposed action from the approval event. The action record describes what the agent intends to do; the approval record describes who authorized which version and when. This separation makes the system easier to audit and prevents a later edit from changing the meaning of an earlier approval.
On resume, reload the saved state and revalidate the action. Check that the request is still pending, the approval matches the current action version, the approver remains authorized, and any time-sensitive assumptions still hold. If the underlying data has changed, pause again and present the updated action for review.
Make rejection a recovery path
A rejection should not automatically end the entire workflow. The agent can record the reason, revise its plan, or ask for clarification. But it must not treat rejection as permission to try a nearly identical action through another tool.
For example, if a reviewer rejects an email because it includes the wrong customer list, the agent can prepare a corrected recipient list and submit a new request. The new proposal should have a new action version and a clear summary of what changed. If an operation partially completed before the checkpoint—such as a multi-step update—the workflow should define whether to roll back, compensate, or stop for human intervention.
Account for the operational cost
HITL adds latency and consumes reviewer attention. A queue of approvals can become a bottleneck, particularly when every low-risk action uses the same path. Measure approval volume, time to decision, rejection rate, timeout rate, and how often reviewers request changes. Use that evidence to refine which actions need review and how requests are routed.
Avoid reducing delays by weakening the gate without examining the consequences. Instead, route requests by risk and expertise, batch related low-risk reviews where appropriate, and provide enough context for fast decisions. For critical actions, include an audit trail of the proposed operation, the decision, the approver, timestamps, and the eventual execution result.
HITL is also distinct from training methods such as reinforcement learning from human feedback. Training may shape how a model behaves across future tasks; an approval gate controls whether a specific action may happen now. Both can be useful, but only the runtime gate provides a direct checkpoint before a particular side effect.
A practical checklist
Before shipping an approval workflow, confirm that:
- High-impact actions stop before execution.
- The reviewer can see exactly what they are approving.
- Only authorized people can decide, and decisions are recorded.
- Duplicate or stale approvals cannot trigger execution.
- Timeouts and unavailable approvers have explicit outcomes.
- Workflow state survives process restarts and schema changes.
- Resumed actions are revalidated against current data and policy.
- Rejections lead to a safe revision, escalation, or stop.
The core pattern is simple: pause before the side effect, carry an explicit decision back, and resume from durable state only after validation. Done well, HITL gives an agent room to handle routine work while keeping people in control of actions whose consequences matter.