Production and case studies
Human-in-the-loop
A human approves, edits or takes over before the system proceeds. Use it for irreversible actions and the long tail your evals have not made safe.
HITL is when a human must approve, edit or perform a step before the system proceeds. Autonomy is a dial. More HITL means more safety and less scale. Automate the 60 to 80% that evals show are safe. Keep humans on the long tail.
Concept
Before you start: an agent can call write tools. A gate is a product step where a person sees the proposal and must act before those tools run.
The big idea
Use HITL when actions are irreversible or expensive (refunds, production deploys, legal notices), when error cost is high and detection is hard, or when you are still learning failure modes in early rollout.
| Pattern | Behavior |
|---|---|
| Approve / reject | Agent proposes; human gates |
| Edit then approve | Human fixes the draft |
| Review queue | Low-confidence items land for specialists |
| Escalation | User or model routes to a person with full context packaged |
Package handoff context: transcript, retrieved docs, tools already tried, suggested reply. Dumping the user into a blank human chat wastes the automation.
Shadow mode (AI drafts, human sends) is a standard bridge during rollout.
AI features are often multiplayer. Attribute AI-assisted edits in history ("drafted with assist v12"). Preserve human overrides when regenerating ("keep my edits to paragraph 2"). In support and ops tools, make the handoff pack visible to both sides where appropriate.
Walking through a refund
The agent proposes refund $40 on order 1842 with the order JSON and the policy snippet. The reviewer sees the proposal, the rationale and a preview. They click Approve. The executor runs. The audit row stores who approved.
If the reviewer is offline, the timeout fails safe: no refund, not an automatic send. Blanket "Allow all" is hidden or expensive to enable, because click fatigue is how gates die.
Measuring the surface
Vanity metrics ("messages sent") lie. Prefer:
- Acceptance rate — suggestions kept or sent without heavy edit
- Edit distance — how much users change the draft
- Task success — ticket resolved, PR merged, form submitted
- Time-to-completion versus the baseline without AI
- Regeneration rate and escalation rate
- Retention of the AI surface
Tie metrics to evals. Offline quality should predict online acceptance. If offline scores rise and acceptance falls, the eval is measuring the wrong thing. Verbosity bias is a common culprit.
Common mistakes
- A blank handoff. The human starts over. Package the transcript and the tools already tried.
- Fail-open timeouts. The email sends because nobody clicked.
- Measuring messages, not acceptance. A chatty failure looks like engagement.
Check yourself
- Evals say 70% of drafts are safe to send. What happens to the other 30%? They stay on a review queue. You do not flip the whole stream to auto-send.
- Offline judge scores go up and users edit more. What is wrong? The eval is not measuring what users keep. Check verbosity bias.
Key takeaways
- Use HITL for irreversible or hard-to-detect errors.
- Automate the slice evals show is safe. Keep humans on the tail.
- Package context on every handoff.
- Measure acceptance, edit distance, task success and escalation, and align them with evals.
Further learning
People + AI Guidebook (Google PAIR)A toolkit for teams building human-centered AI products.pair.withgoogle.com
Guidelines for Human-AI Interaction (Microsoft HAX)Best practices for designing AI user experiences What are the Guidelines? The Guidelines are evidence-based best practices for designing your AI user experiences. How do I use the Guidelines? The Design Library helps …Microsoft HAX Toolkit
Related
Designing AI product experiences
Interaction design for probabilistic systems: trust, control, failure states and human-in-the-loop.
Agents and agent architectures
Workflows vs agents, the core patterns, ReAct loops, planning and knowing when to stop.
Evaluating LLM apps
A fixed set of inputs plus a way to score outputs, so you can tell whether a change helped.