How should AI agents handle approval, undo, and human handoff?
Published
An AI agent that changes a record, submits a request, or contacts another person needs an explicit action flow. The interface should show what the agent may do, what it proposes, what has happened, and what can still be stopped or reversed.
Approval and undo depend on the underlying system. A reassuring button cannot make an external action reversible. The suggested design checklist below starts with those limits so the interface can describe them accurately.
What exactly is the agent allowed to do?
Write a permission statement for each action type. Separate reading data, preparing a draft, editing a record, and sending information outside the product. A user may authorize one without authorizing the others.
Record the scope as well as the action: which workspace, which records, and whose account. Show the active scope near the action when a mistake would matter. Permission checks belong in the application’s enforcement layer; the interface should explain them rather than substitute for them.
Google’s People + AI Guidebook on feedback and control discusses how users can understand and influence automated behavior. A practical application is to make autonomy a visible product setting with a clear effect, rather than an unexplained switch labeled “Agent mode.”
What should a user see before approving an action?
In a hypothetical customer operations tool, an agent prepares to update an account owner and notify a colleague. The approval screen should show the affected account, the previous owner, the proposed owner, and the exact notification recipient and text.
Give the user a way to edit the proposal without reconstructing it in a prompt. If the agent changes the proposal after review, require fresh approval for the changed action. A confirmation for an earlier version does not cover a new recipient or an additional record.
Choose a specific button label such as “Update owner and send notification.” Use separate approvals when the actions have different consequences or when users commonly want only one of them. Avoid a generic confirmation that hides the scope in a collapsed panel.
How can a team test whether approval was informed?
Microsoft’s Human-AI Interaction guidance recommends explaining how a user’s actions affect later AI behavior. Apply that principle to approval testing by asking the participant to predict the consequence before pressing the button.
Illustrative exercise, not a client result: show an agent proposal to update one account and notify its owner. After review, change the proposed notification recipient. The test checks whether the interface makes that change apparent and requests approval for the new version.
- Ask the participant which record will change, who will receive the message, and what can be reversed.
- Check whether rejecting the notification still allows a permitted record update.
- Show a partial completion and ask what a retry will do.
- Treat an incorrect prediction as a design finding. A click on the confirmation button alone does not demonstrate understanding.
Sources: Microsoft HAX guidance on consequences of user actions
Which states must the action flow cover?
Specify these states with engineering before polishing the success screen. Some actions may finish too quickly to show every intermediate state, but the product still needs an accurate way to report their outcome.
- Proposed: nothing has changed; the user can inspect or edit the plan.
- Awaiting approval: the system is waiting for permission to execute the displayed version.
- Running: the system has started; the screen identifies the work in progress.
- Completed: the screen confirms the changes that succeeded.
- Partially completed: the screen separates successful changes from failed or untouched ones.
- Stopped or failed: the screen explains the known outcome and the available next step.
Keep a stable action identifier or receipt so a user returning later can find the result. Reopening the conversation should not require guessing whether the action ran.
How should cancellation and undo differ?
Cancellation asks the system to stop work that is still in progress. It may not stop a request already accepted by another service. Until the outcome is known, show that the stop request is pending rather than claiming that nothing happened.
Undo is a separate operation that restores a previous state where the system supports it. Define which fields it restores, whether later edits prevent it, and whether an external effect remains. Reverting an account owner does not retract a notification somebody has already read.
For the hypothetical account update, a partial failure could mean the owner changed but the notification failed. Offer a retry for the notification alone. Before retrying an action with an uncertain outcome, check whether it already succeeded; otherwise the product may send the same message twice.
When should a person take over?
Define handoff triggers for the task. Examples include missing authority, contradictory source records, an unsupported request, and a user explicitly asking for help. These are proposed product rules, not universal thresholds.
Google’s guidance on AI errors and recovery distinguishes different failure causes and emphasizes useful recovery paths. For an action-taking product, recovery may require a human who can inspect what happened and decide what to do next.
The handoff should include the original request, the approved action, completed steps, unresolved steps, and relevant source links. Respect the receiving person’s access permissions. Tell the user where the request went and what happens while they wait; do not imply live support if nobody is available.
These specifications belong in the acceptance criteria for an AI feature in a SaaS product. If the uncertainty is why users avoid the feature, start with an AI copilot adoption audit and use observed failures to decide which controls need attention first.
