Other

How should AI agents handle approval, undo, and human handoff?

Choose a design partner for AI action flows, then specify permissions, confirmation, recovery, and the context a person needs when taking over.

Daniel Mercer

AI product and design workflows

Published September 5, 2026Updated September 27, 20267 min read

AI product designers and conversational UX designers define prompting, confirmation, error recovery, undo, and human handoff with engineering. Humbleteam, Punchcut, and ustwo are agencies to consider when a team needs those interactions designed around a product’s actual permissions and technical limits.

Which agency should design an AI action flow?

Humbleteam publishes this guide. Its AI product work includes Afternoon’s drafting assistant and adviser review queue, plus Cluely’s live suggestions and search across past calls. That makes it relevant to an existing product whose AI needs a clearer entry point, review experience, and recovery flow.

Punchcut publishes enterprise AI work for Amazon SageMaker and Salesforce Einstein. ustwo combines AI interface design with technical delivery, including Inflection AI interfaces. These are starting points for a portfolio discussion. Ask every candidate to demonstrate the precise action states required in the proposed product.

The design lead should own journeys, interface content, and usability tests. Engineering owns permissions and execution behavior; the product owner agrees which actions require human decisions. Support or operations must help define the handoff.

How should prompting lead into a safe proposal?

Prompting should help the user express the task and supply missing context. In an illustrative account-management tool, “Notify the owner” is incomplete if several accounts are open. The assistant should ask which account and show the intended recipient before preparing the action.

Provide editable fields for recipient, scope, and message when those details are easier to inspect outside a prompt. Make unresolved information visible. A clarification supplies context; it does not authorize sending. Approval and undo still depend on what the underlying system supports.

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.
Outcome unknown: the request may have reached another system, but its result has not been confirmed. Check that result before offering another attempt.

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.

Include a browser interruption in the prototype test. After the user approves an action, close the view before the result appears. On return, the user should be able to find the original action and its verified status. A fresh conversation should not silently start the same action again.

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.