Human-in-the-loop does not mean putting an approval button after every model call. That design is safe in the way unplugging the server is safe: nothing useful happens.
The goal is to place human judgment at the point where it changes risk or quality. Reads, drafts, and reversible calculations often run automatically. External communication, financial actions, destructive writes, and unresolved ambiguity deserve a different path.
Use four intervention patterns
| Pattern | Human role | Best fit |
|---|---|---|
| Approval | Accept or reject a proposed action | Consequential tool calls |
| Review and edit | Correct a draft before release | Messages, reports, code changes |
| Clarification | Supply missing intent or facts | Ambiguous requests |
| Escalation | Take ownership of an exceptional case | Policy conflict, uncertainty, repeated failure |
These patterns solve different problems. A yes/no approval is poor UX when the agent needs one missing date. An open editing interface is excessive when the only decision is whether to issue a refund.
Put approvals immediately before the side effect
Approve the validated action, not the vague plan.
Weak approval:
The agent plans to resolve this support case. Continue?
Useful approval:
Send this email to customer@example.com?Subject: Replacement order confirmedBody: ...Related order: ord_81ks92Side effect: external email
The approval payload should include the tool, resource, arguments, expected effect, and relevant evidence. If arguments change after approval, invalidate the approval.
For long-running workflows, persist the paused state. OpenAI's Agents SDK, for example, surfaces approval interruptions and serializable run state so execution can pause and resume without replaying completed work.
Make policy decide when approval is required
Do not ask the model whether its own action is risky. Put the rule in the runtime.
def approval_policy(call, context):if call.tool == "refund_order" and call.amount_cents > 5000:return "supervisor"if call.tool == "send_external_email":return "requesting_user"if call.tool == "get_order_status":return Nonereturn "security_review"
Useful policy inputs include:
- side-effect class;
- amount or data sensitivity;
- user and agent permissions;
- confidence or evaluator result;
- novelty of the action;
- customer or regulatory requirements;
- whether the operation is reversible;
- recent failure or attack signals.
Policy should default safely when metadata is missing. An unknown tool is not a low-risk tool.
Review drafts when editing adds value
Some outputs need human judgment but not a binary gate. Give the reviewer an editable artifact:
- customer-facing messages;
- generated reports;
- pull requests;
- proposed database migrations;
- policy summaries;
- high-impact recommendations.
Track what changed between the agent draft and the approved version. Those edits are valuable evaluation data. Repeated corrections to tone suggest one fix; repeated factual corrections suggest another.
Do not automatically treat every edit as a new global training example. It may be customer-specific, legally required, or simply one reviewer's preference.
Ask for clarification before doing expensive work
The best human intervention often happens at the beginning.
“Prepare the migration.”
The agent might need to know the target environment, downtime tolerance, rollback constraint, and owner. Guessing creates a polished plan for the wrong task.
Define clarification triggers:
- two plausible interpretations lead to different actions;
- a required identifier cannot be resolved safely;
- the requested action conflicts with policy;
- the consequence is high and intent is implicit;
- the agent cannot establish which resource the user means.
Ask one compact question containing the decision the human must make. Do not dump the agent's internal uncertainty as a questionnaire.
Escalate with a useful packet
An escalation should save the human time. Include:
- the user's goal;
- current workflow state;
- evidence collected;
- actions already completed;
- the exact blocker or policy conflict;
- proposed options and consequences;
- trace and resource identifiers.
“Agent failed—please help” transfers the entire investigation. A good escalation transfers a decision.
Define who owns each class of escalation and what happens if nobody responds. Approval queues need deadlines, reminders, reassignment, and cancellation semantics just like other operational queues.
Resume without repeating side effects
Pause and resume creates a retry boundary. The workflow must remember which tools already completed, which action was approved, and whether the external side effect occurred.
Use stable operation IDs and receipts. If an approval arrives after the underlying resource changed, revalidate the action. If a run is resumed twice, the operation should still happen once.
The detailed failure model is covered in Idempotency and Retries for Reliable AI Agents.
Keep the human decision auditable
Record:
{"approval_id": "apr_9021","trace_id": "trace_188","tool_call_id": "call_44","decision": "approved","decided_by": "user_17","policy_version": "refund-v3","arguments_hash": "sha256:...","decided_at": "2026-08-20T12:15:00Z"}
The log should establish what the reviewer saw, which policy applied, and whether execution matched the approved arguments. This is part of the LLM observability trace, not a separate spreadsheet.
Measure whether the loop is working
Track:
- approval rate by action type;
- rejection and edit rate;
- time waiting for a decision;
- expired or abandoned approvals;
- side effects attempted without required approval;
- outcomes after approval and rejection;
- repeated corrections by category;
- percentage of escalations resolved without re-investigation.
A 99% approval rate may mean the agent is excellent. It may also mean the gate is placed on harmless actions and reviewers click through automatically. Sample decisions and interview reviewers before removing the control.
Human-in-the-loop checklist
- Each intervention is an approval, edit, clarification, or escalation.
- Runtime policy—not the model—decides when intervention is required.
- Approval shows the final validated action and consequence.
- Changed arguments invalidate prior approval.
- Paused state survives process restarts and long delays.
- Escalations include evidence, state, blocker, and proposed options.
- Resume paths are idempotent and revalidate stale resources.
- Decisions record reviewer, policy, arguments, and timestamp.
- Reviewer edits feed evaluation without becoming unreviewed global memory.
- Metrics reveal approval fatigue and queue bottlenecks.




