Human-in-the-Loop
"Human-in-the-loop" has become a catch-all phrase in AI product development, used to describe everything from explicit approval flows to passive monitoring to the ability to stop an agent mid-run. But the UX requirements of each pattern are very different. Conflating them leads to products that are either too interruptive (users get approval fatigue) or too opaque (users don't trust the automation).
This is a taxonomy of human-in-the-loop patterns for production AI agents, with UX considerations for each.
What it is: The agent proposes a plan and waits for human approval before executing any actions.
When to use it: Long-running tasks with irreversible consequences, or tasks where the plan itself might be wrong. Example: "I'm going to run a three-step campaign that includes deleting the old segment, building a new one, and sending to 5,000 customers. Here's my plan — approve to proceed."
UX considerations: The plan must be presented in enough detail for the user to evaluate it, but not so much detail that they're overwhelmed. Editing the plan should be possible: don't make approval binary if the user might want to approve steps 1 and 2 but modify step 3.
Common mistake: Showing the technical plan (a JSON object or a list of function calls) rather than a human-readable narrative. Engineers understand the plan; most users need the narrative.
What it is: The agent executes steps sequentially and pauses at defined checkpoints for human review before continuing.
When to use it: Multi-step processes where later steps depend on the output of earlier ones, and where proceeding with incorrect earlier output would be expensive to unwind. Example: data transformation pipelines, content generation workflows, multi-stage outreach sequences.
UX considerations: The checkpoint UI must show: what was just completed, what it produced, and what will happen next if the user approves. The cost of pausing is real (the user has to switch context to review); make it efficient. Checkpoint cards should be scannable in under 10 seconds.
Common mistake: Pausing at too many checkpoints. Every checkpoint is an interruption. If users routinely approve without reading, you have too many checkpoints — and you've trained users to rubber-stamp, which is worse than full automation.
What it is: The agent proceeds automatically when its confidence is above a threshold, and requests approval when confidence drops below it.
When to use it: Tasks where most cases are routine but some are edge cases that benefit from human judgment. Example: a document classification agent that handles 95% of documents automatically but escalates the ambiguous 5%.
UX considerations: The confidence threshold should be configurable by users. Show users their approval rate over time so they can tune it. When escalating, explain why ("I'm not sure how to categorize this — it has characteristics of both Category A and Category B") in plain language, not a confidence score.
Common mistake: Surfacing raw confidence scores ("confidence: 0.67"). Users don't know what 0.67 means in the context of your model. "I'm not sure about this one" is more useful than a number.
What it is: The agent proceeds with an action and notifies a human reviewer afterward. The reviewer can reverse or correct the action within a defined window.
When to use it: Actions that are reversible within a reasonable time window, where the cost of latency (waiting for approval) exceeds the risk of occasionally acting wrong. Example: sending a message, publishing a document, updating a record — where a 15-minute reversal window is acceptable.
UX considerations: The reversal window must be clearly communicated ("this action will take effect in 15 minutes unless reversed"). The notification should arrive in the right channel (email, Slack, in-app) with a one-click reversal. After the window closes, communicate that clearly.
Common mistake: Setting the review window too short. If users need 10 minutes to check their email, review the action, and decide, a 5-minute window is effectively no window at all.
What it is: The agent operates autonomously, but produces a real-time or near-real-time activity log that a human can monitor and interrupt.
When to use it: Long-running autonomous tasks where interruption should be possible but isn't expected to be needed. Example: a research agent running overnight, a data ingestion pipeline, a background content moderation task.
UX considerations: The monitoring view should be glanceable — it should be possible to assess that things are running normally without reading every log entry. Use color and status indicators aggressively. The interrupt mechanism must be obvious and immediate ("Stop agent" should be one click, not buried in a menu).
Common mistake: Building a monitoring view that's only useful for debugging after something goes wrong. Real-time monitoring should surface problems before they compound — anomalous behavior, unexpected tool usage, actions that look out of scope.
What it is: The agent produces a draft that the human edits before finalizing. The agent may offer multiple drafts or respond to edits with revisions.
When to use it: Creative or judgment-intensive outputs where the agent provides a strong starting point but the human should own the final result. Example: email drafting, report generation, proposal writing.
UX considerations: The editing interface should be familiar (it should look like a document editor, not an AI interface). The agent's contributions should be distinguishable from human edits, at least initially. Revision requests should be conversational ("Make the tone less formal") rather than requiring formal prompts.
Most production agent products need more than one pattern, applied to different types of actions. A useful decision framework:
The best human-in-the-loop is one that users trust so much they rarely need to use it — but are glad it's there when they do.
There's a failure mode in human-in-the-loop design where approval flows exist but don't provide real oversight. Users see an approval prompt, click "approve" without reading it, and the system logs a human-in-the-loop interaction that provided no actual oversight.
This is approval theater. It's worse than full automation, because it provides the appearance of human oversight while delivering none — and it erodes user trust when something goes wrong and they realize they were approving things they didn't understand.
If your approval flow is being rubber-stamped, fix it. Either the flow provides too little information to make a real decision, asks users to approve too frequently, or the approval threshold is set wrong. Design your way out of theater.
Agent Interface provides the ApprovalFlow and ToolTrace components that implement these patterns. MIT-licensed, production-ready. Get early access →
Continue reading
All the UI primitives you'll need, and why they're harder than they look.
Read →The specific design decisions that make approval flows trustworthy.
Read →Making tool call traces legible to non-engineers.
Read →