By Mehdi HassanHow do you design human-in-the-loop controls for AI actions?
Design human-in-the-loop controls by deciding, for each kind of action, whether the AI suggests, asks first or acts and reports, and then building the matching interface: a suggestion, an approval or a log entry with undo. The level should depend on how costly and how reversible a mistake would be.
Many products treat oversight as a single confirm dialog. That works for one action a day and fails at fifty. As AI features move from writing text to sending emails, updating records and moving money, approval design becomes the main interface rather than an afterthought. This guide is part of our hub on AI product UX, and it pairs with our guide to agentic UX, which covers how agents plan and act.
What are the autonomy levels in human in the loop UX?
Human in the loop UX usually works with four autonomy levels: suggest only, ask before acting, act and report, and act silently. Each level shifts work from the human to the AI and shifts the interface from review before to review after.
Level | What the AI does | Human's role | Interface | Fits actions like |
|---|---|---|---|---|
Suggest only | Drafts or recommends | Decides and acts | Inline suggestion or draft | Customer replies, contract edits |
Ask first | Prepares the action and waits | Approves, edits or rejects | Approval card or review queue | Sending emails, refunds, record updates |
Act and report | Acts, then tells the user | Reviews after, undoes if needed | Action log with undo | Tagging, routing, internal notes |
Act silently | Acts without notice | Audits occasionally | Searchable history | Formatting, deduplication, sorting |
The useful move is to treat these levels as a setting per action type rather than one switch for the whole AI. A support team might let the AI tag tickets silently, act and report on routing, ask first on refunds and only suggest replies to enterprise customers. That's a far better fit than all-or-nothing.
How should autonomy settings work in the product?
Autonomy settings should list the actions the AI can take, show the current level for each, and let an admin change them in plain language. Users should never have to guess whether the AI will act on its own.
- Group by action, not by model. Send emails, Update deal stage and Issue refunds are settings people understand. Agent mode is not.
- Default to cautious. New workspaces should start at suggest or ask first for anything that touches customers, money or data deletion.
- Add limits, not just levels. Act automatically on refunds under a set amount, ask above it. Thresholds let teams relax control gradually.
- Show the setting where the action happens. A small label on the approval card, such as Ask first, change in settings, connects the rule to the moment.
- Log changes to settings. Who raised the AI's autonomy and when is part of the audit trail.
What should an AI approval flow show?
An AI approval flow should show what the AI plans to do, why, and exactly what will change, with approve, edit and reject as equal options. An approval card that only says The AI wants to send an email, Approve or Cancel asks users to trust blindly.
State the action in plain words
Send this reply to Dana at Acme, or Change deal stage from Demo to Proposal. Name the target, not just the action type.
Show the exact change
The full email text, the before and after of the record, or the amount and account. For edits, show a diff.
Explain the reason
One line on why: Customer asked for pricing in their last message. Link to the source, as covered in our guide to AI citations UI.
Offer edit, not only approve
Most useful approvals are approve with changes. Let users fix the draft in place and then approve.
Confirm what happened
After approval, show a short receipt with a link to the result and an undo window where the action allows it.
Keep approval cards consistent across every action type. When the layout is always the same, users learn where to look and approve faster without approving carelessly.
How do you design an AI review queue that scales?
Design an AI review queue as a focused inbox of pending actions that users can sort, filter, batch-approve and clear quickly. Once an AI prepares dozens of actions a day, one-by-one pop-ups become a wall of interruptions, and a queue puts review on the user's schedule.
- Group similar actions so users can approve ten tag changes at once while still opening the one refund.
- Sort by risk and urgency, with the highest-stakes items first and a clear due time where there is one.
- Show enough in the row to decide: target, action, reason, and a flag if the AI was unsure.
- Support keyboard review, such as approve, reject and next, for teams clearing many items.
- Expire stale items instead of letting them pile up, and tell users what happens when an item expires.
For example, suppose a finance team reviews AI-coded expenses
For example, suppose an expense tool uses AI to categorize receipts and flag policy issues. Low-value receipts with a clear category are coded automatically and appear in the log. Receipts above a set amount, or ones the AI was unsure about, go into a review queue sorted by amount. Each row shows the merchant, amount, proposed category and a one-line reason. The reviewer selects all clear items, approves them in one action, then opens the two flagged ones.
This is a hypothetical walkthrough to show how levels, thresholds and a queue work together, not data from a real product.
How should undo work for AI actions?
Undo for AI actions should work after the fact, from a log, not only in the seconds after the action. When the AI acts on its own, users often find out later, so the ability to reverse an action has to live where they'll look: an activity log tied to the record or the workspace.
Each log entry should say what the AI did, when, on what, and why, with Undo next to it when the action is reversible. Some actions can't be undone, such as a sent email or a completed payment. For those, say so on the approval card before the action, and offer the closest recovery afterward, such as a follow-up correction draft. Never show an undo button that only partly reverses an action without saying so. Our guide to AI loading states covers how to show these actions while they run.
Pros
- Lets teams grant more autonomy with less risk
- Gives a clear audit trail for compliance
- Turns mistakes into fixes instead of incidents
Cons
- Needs reversible actions in the backend, not just a UI button
- Logs get noisy without grouping and filters
- Some actions can never be truly undone
How do you choose the right AI oversight UI for your product?
Choose the right AI oversight UI by mapping each AI action to two questions: how much does a mistake cost, and can it be reversed. Costly and irreversible means ask first. Cheap and reversible means act and report. Everything in between gets a threshold.
Start strict and loosen with evidence from your own users. It's much easier to grant autonomy than to win back trust after an AI does something embarrassing on its own. If your AI mostly assists rather than acts, you may not need queues at all, and our guide to copilot vs agent vs chat helps you decide. When you do need them, approval cards, queues and logs belong in your component library, which our guide to design systems for AI products covers.
