AI Action Confirmation UX: When Should an AI Ask Before Doing Something?

An AI should ask before acting when getting it wrong would be costly or hard to undo. Score each action on seven factors: risk, reversibility, financial impact, external communication, privacy, permissions and blast radius. Then map the score to one of four modes: automatic for low risk, notify with optional review for medium, explicit approval for high and human-controlled for critical actions.

Asking too often is a failure too. People approve without reading when every step needs a click. Prefer undo for reversible actions, batch related approvals and reserve confirmation for actions that matter.

Classify by the highest-risk factor, not the average: a single irreversible external payment is high risk even if everything else is low.

When an action needs approval, the request should let a person decide in seconds without opening other tools. It needs an action summary in plain language, the object and recipients affected, the impact (amount, number of records), a risk indicator and why it is that level, the context and evidence the AI used, and four responses: approve, reject, edit and delegate to someone else, plus an escalation path when the approver is unsure. State what happens if nobody responds; the safe default is that nothing happens.

For actions that were taken automatically, undo must be real: reversing a database change is easy, but recalling an email or a payment is not. AI agent rollback covers what can be reversed and how.

Approve should commit exactly what was shown; if anything changed since (price, stock, recipient), show it again. Reject should ask for a short reason, which becomes feedback for the agent and its evaluation set. Edit lets the approver correct details without rejecting the whole action, and the edited version is what executes. Delegate sends the request to someone with more context or authority, keeping the history. For queues of many approvals, see the operational guidance in human-in-the-loop AI.

Over-confirming has real costs: slower work, users who stop reading and approve everything, and frustration that pushes people to disable the AI. Practical ways to keep confirmations meaningful:

A confirmation that exists only in the interface can be bypassed by a bug, a different client or a prompt injection. Store the confirmation tier per action in policy, require an approval token from the right person for high-tier actions at the API, and log who approved what. The same thinking at the level of the whole agent is in AI agent autonomy levels.

The right answer to 'should the AI ask first?' depends on what the action can break. Score actions on risk, reversibility, money, external reach, privacy, permissions and blast radius; automate the low tier, notify on the medium, require approval on the high and keep people in control of the critical. Design approval requests that can be judged in seconds, prefer undo where it is genuine and enforce the rules on the server. For explaining actions after they happen, see AI agent trust UX.