When an AI Assistant Should Clarify, Confirm or Take Action
Design AI assistant action confirmation with required inputs, a proposed-action record and tests for ambiguity, stale approvals and duplicate retries.
Luka Abramovic3 min read
AI assistant action confirmation should approve a concrete action, not an intention the system has not yet resolved. Clarification asks for missing information. Confirmation asks the user to approve the identified target and change. Execution then checks whether that exact action is still permitted.
A specialist product might translate a request such as move the review to Friday. If several reviews exist or the date is ambiguous, the product needs clarification before it can present a meaningful confirmation.
List the information each action requires
| Action | Required facts | Reason to ask a question |
|---|---|---|
| Reschedule a review | Review identifier, date, time and zone | More than one review matches |
| Share a brief | Brief version, recipient and access level | Recipient is unclear |
| Replace a generated output | Output identifier and replacement version | User edits may be lost |
For each action, choose whether confirmation is needed under the product’s actual rules and consequences. Do not substitute a model confidence score for user permission. Confidence concerns interpretation, while permission concerns whether the action is authorized.
Show the exact proposed change
Action
Target record and current version
Values before the change
Values after the change
Recipient or affected users
Consequence that cannot be undone through normal controls
Confirm or cancel
Operation referenceBind the approval to these values. If the user changes the recipient or date, ask them to review the new proposal where confirmation is required. Reusing an earlier yes after changing the proposal approves something the user did not actually see.
Test stale approval and changed access
Prepare an action, then change the target record in another authorized session before confirming. The product should detect the changed state and decide whether the proposal remains valid. Next remove the user’s permission and confirm again in a controlled test. Permission must be checked at execution, not assumed from the earlier conversation.
In an illustrative three-action feature, each action has an allowed case, missing-input case, changed-record case and denied-access case. That creates 12 behavioural checks before duplicate retries are considered. The count is a test-plan example, not a universal coverage standard.
Handle an uncertain result without repeating the action
If the action succeeds but the response is lost, retrying as a new operation can perform it twice. Keep one operation reference and inspect or retry that operation according to the receiving system’s contract.
As a concrete API example, Stripe’s idempotent request documentation describes reusing an idempotency key and comparing parameters to prevent accidental misuse. Other services have different contracts, so verify the actual API rather than assuming this behaviour everywhere.
Test a lost response and inspect the authoritative record. The user should see one completed change or a clearly unresolved operation, with a route to check it. A second confident success message does not prove there was only one side effect.
Bring one AI action and an ambiguous user request. We can define the clarification, confirmation and execution checks around it. Discuss the first release with Adamant Code.