dooopSoftware · Product · 5 min

How to Design Human Approval in AI Products

Design approvals that show action, evidence, and alternatives. Connect the user’s choice to what will be executed and the outcome reported.

Published on September 6, 2026

CORE THESIS

A confirmation button does not solve a proposal the person cannot verify.

Approval must correspond to the presented action and what the product executes.

Human approval in an AI product needs to allow an informed decision about a concrete action. The user must understand what will be done, on which object, with which information, and relevant consequences. Placing a confirmation button at the end of the flow does not solve this design if the person cannot verify the proposal or choose an alternative. Approval must be part of the task’s operating contract.

Define Which Decision Requires Approval

Start with the action, not the screen. Is the person approving a text, a state change, the sending of information, or a sequence of operations? A broad request like “authorize the assistant” may hide decisions that should be examined separately.

Describe the scope of the approval and its duration. If the proposal changes, is the previous confirmation still valid? If a new recipient or an additional effect arises, will it be necessary to present the change again? These conditions need to be defined before implementation.

Anthropic on agents distinguishes predefined flows from systems that dynamically choose steps and tools. In a product that delegates this choice, this guide proposes keeping explicit the boundary between what can be prepared and what requires the person’s decision.

Show the Information That Influences the Choice

The approval screen must present the object of the action, the proposed change, and the relevant evidence. For an update, showing the current state and the proposed state can help verify the change. For communication, recipient and content are essential parts of the decision.

Avoid filling the interface with technical details that do not help evaluate the action. The origin of information may be relevant; the name of an internal component may not be. Offer access to details when they allow investigating a real doubt.

A verification script includes:

What will happen after confirmation.
Which information supports the proposal.
Which uncertainties remain relevant.
What the person can edit or refuse.
How the product will inform completion, failure, or the need for a new decision.

Preserve Useful Alternatives for the User

A person should be able to refuse without losing all work when unnecessary. It may be useful to edit the proposal, request additional information, save a draft, or proceed manually.

These alternatives must correspond to actual operation. If the product offers “edit,” the change must be incorporated into what will be executed. If it offers “cancel,” it must explain the final state of the task when some steps have already occurred.

Also consider information that became unavailable. If confirmation depends on data that could not be consulted, the product should not hide this absence behind a generic trust message. The decision may be to stop the action, request completion, or present a restricted proposal.

Fictional Example: Approving a Project Update

Imagine a system where AI suggests updating the responsible person and the status of an activity based on recent messages. The screen shows the activity, current values, proposed values, and the excerpts that motivated the suggestion.

The person notices that one message described only a possibility. They can keep the current responsible person and accept only the status update if the product allows this separate decision. Execution must correspond to the effectively confirmed set.

Afterward, the system reports which changes were completed and which could not be applied. The example does not claim this interface eliminates errors. It shows how to make the proposal, choice, and result examinable.

Do Not Confuse Confirmation with Completed Execution

Authorization records a decision. Execution may fail, be interrupted, or encounter a different condition. Define how the user will track this status and how the team will investigate a dispute.

Record the presented proposal, what was confirmed, changes made before confirmation, and the observed result. The depth of the record should match the investigation need and the organization’s data handling rules.

When the action cannot be repeated without risk of duplication or other unwanted effects, the recovery path must be defined by engineering and product. The interface should reflect this path rather than invite the person to try again without sufficient information.

Evaluate Whether Approval Helps Decision-Making

Test the experience with representative tasks and doubts. Observe if people can identify the object of the action, explain the effect, and locate the information needed to disagree. Confirmation time alone does not demonstrate understanding.

Microsoft ExP describes the link between hypothesis, measurement, and iteration. The interface hypothesis may be that a clearer presentation helps detect an inadequate proposal without creating unnecessary effort. The effect must be observed; do not attribute safety to simply adding a step.

Before releasing the flow, use a correct proposal, an ambiguous one, and one that should be refused. Check if the interface allows different decisions and if execution respects what was confirmed. This correspondence is what approval needs to support in the product.

If you want to discuss this decision in your company’s context, talk to dooop.

Sources

To Continue This Reading

How to Integrate External Tools into a Product Agent

NEXT DECISION

Discuss Application in the Company

Conversation about the software company context

Content by dooop. Registration allows relating this topic to the reader’s journey and tracking interest in the subject.