Human-in-the-loop design places people at specific decision points where an agent lacks authority, confidence, evidence, or business accountability.
The best review flow is risk-based. Harmless read operations can run automatically, while payments, messages, record changes, and irreversible actions require stronger approval.
A review request must be actionable: it should show the proposed action, evidence, affected resources, uncertainty, policy checks, and available reviewer choices.
Human review is a control surface, not a panic button. The agent prepares a decision package; the reviewer applies accountability where uncertainty or impact is too high.
Review requirements should depend on impact, reversibility, confidence, user intent, and policy. A low-confidence answer may need clarification, while a high-confidence payment still needs authorization because the consequence is financial.
Avoid requiring approval for every step. Excessive review creates fatigue and encourages rubber-stamping.
A reviewer should not reconstruct the run from raw logs. Present a concise summary, proposed action, key evidence with source links, policy result, risk level, and what will happen after approval.
Offer meaningful choices such as approve, reject, edit, request more evidence, or escalate. Record both the choice and any reviewer changes.
Approval may arrive minutes or days later. Persist workflow state, pending action, tool arguments, version information, and a stable review ID so the run can resume safely after a process restart.
Before execution, revalidate time-sensitive facts and permissions. An action that was valid when proposed may be stale when approved.
Every approval queue needs an owner, service-level expectation, reminders, expiry behavior, and fallback. Silent waiting is not a workflow.
Expired requests should not execute automatically. Cancel them, regenerate current evidence, or route them to another authorized reviewer.
Edits, rejections, and escalation reasons are valuable evaluation data. Track where humans disagree with the agent and use those cases to improve prompts, retrieval, tools, and policy.
Do not automatically train on all reviewer actions. Check quality, privacy, and whether the reviewer had the right context.
Human-in-the-loop is not a pop-up sprinkled on top of an agent. It is a real workflow state with inputs, outputs, timeouts, audit records, and resume behavior. When an agent needs approval, it should pause at a known boundary, show the reviewer exactly what will happen, and resume from a durable checkpoint after the reviewer accepts, edits, rejects, or escalates.
The best approval systems separate three different review types. Approval review asks, "May this action happen?" Edit review asks, "Should this generated content be changed before use?" Escalation review asks, "Should a human take over because the task is risky or ambiguous?" Combining these into one generic approve button makes the product harder to trust.
Review payloads should be written for humans, not just machines. Show the action, target system, important arguments, evidence, risk level, and consequence. A reviewer should not need to read a raw trace to understand whether approving will send an email, change a ticket, issue a refund, or delete a file.
Not every action deserves the same amount of friction. A read-only search across approved documents may run automatically. A draft response might require lightweight review. A refund, permission change, production deployment, or external message should require explicit approval. This risk-based model keeps users safe without making the agent unusable.
Approval policy should be deterministic. Do not ask the model whether its own action is risky. Let trusted code classify actions by tool type, target, amount, audience, tenant, confidence, and policy rules. The model can explain why it recommends an action, but the application decides whether review is required.
Human review should be designed as a repeatable control pattern. The agent prepares a proposed action, the runtime packages the evidence, the reviewer makes a decision, and the system resumes with an auditable record. This pattern is much stronger than asking a model to "be careful" before important actions.
Different review types need different interfaces. A content review should let the reviewer edit text. A permission review should show the target, role, and consequence. A risk escalation should show why the agent is uncertain and what specialist input is needed. One generic approve button is rarely enough for production workflows.
Human control also needs measurement. Track approval rate, edit rate, rejection rate, escalation rate, time in queue, and common reviewer comments. These signals show whether the agent is improving or merely pushing work onto humans. If reviewers edit every output heavily, the model, retrieval, or instructions need attention.
The most reliable systems use human feedback to improve evaluation sets. Reviewer corrections should become test cases so the same mistake is not repeated silently in future releases.
Design three review screens for the same agent: one for approving a tool action, one for editing generated content, and one for escalating an uncertain case. Each screen should show different information because the reviewer decision is different.
Then define the resume behavior after each decision. Approval may execute the action, edit may update state and continue, rejection may stop or re-plan, and escalation may transfer ownership. This makes human review part of the workflow instead of an interruption bolted on later.
Define timeout behavior for every review queue, because an approval that waits forever becomes an operational failure rather than a safety control.
For expert-level work, keep this page connected to an actual run trace. Concepts become much easier to understand when learners can see the input, state, model decision, tool behavior, safety check, and final outcome side by side.
Deterministic policy decides whether a proposed action may run.
def approval_policy(action: dict) -> str:
write_actions = {"send_email", "issue_refund", "delete_record"}
if action["name"] in write_actions:
return "human_review"
if action["confidence"] < 0.70:
return "request_clarification"
if action["estimated_cost_usd"] > 5:
return "human_review"
return "auto_execute"
action = {
"name": "issue_refund",
"confidence": 0.96,
"estimated_cost_usd": 0.02,
}
print(approval_policy(action))The packet contains enough information to pause and resume safely.
review_packet = {
"review_id": "review-2048",
"run_id": "run-813",
"proposed_action": {
"name": "send_email",
"args": {"template_id": "refund-approved", "customer_id": "C-19"},
},
"evidence_ids": ["order-17", "policy-4"],
"risk": "medium",
"policy_checks": {
"refund_window_valid": True,
"recipient_verified": True,
},
"choices": ["approve", "edit", "reject", "request_more_evidence"],
"expires_at": "2026-06-10T12:00:00Z",
}
print(review_packet["choices"])No. Review should be targeted to risky, ambiguous, or unauthorized decisions.
Validate the edited action again, record the change, and execute only under the reviewer authority granted by policy.
Yes. Persist the state and use a stable thread or run identifier so the workflow can resume later.
Explore 500+ free tutorials across 20+ languages and frameworks.