When should an agent act immediately, ask a clarifying question, preview a proposed action, or require explicit confirmation? Design the interaction for a task where mistakes are costly but excessive interruptions would make users abandon the agent.
Act immediately for clear, low-risk, reversible work; clarify only when ambiguity could change the result; preview meaningful plans so users can inspect them; and require explicit confirmation before irreversible or high-blast-radius actions. Batch routine actions and use bounded standing authorization to avoid turning the agent into a permission pop-up.
How to think about it
Act immediately when intent is clear and the action is low-impact, reversible, and within standing authorization; ask a clarifying question when missing information could change what success means; show a preview when the user should inspect a meaningful plan; and require explicit confirmation before an irreversible, externally visible, or high-blast-radius action. For costly tasks, do not confirm every step: batch routine work and spend an interruption only when the expected cost of a mistake is greater than the friction of asking.
Why these are different decisions
This is not four levels of politeness. It is a risk decision based on three separate questions.
What does the user mean? This is intent uncertainty. Are they asking to pay one invoice or all invoices? Does “unusual” mean over $10,000, a new bank account, or both? If the answer could change the action, clarify.
What happens if the agent is wrong? This is consequence. Reading a report is usually harmless. Sending money, deleting records, or emailing 50,000 customers is not. Reversibility matters too: an unsent draft is easy to change; a bank transfer after submission may be difficult or impossible to recall.
Is the agent authorized? Authorization means permission to perform a particular class of action. A user asking for “help with invoices” has not necessarily authorized transfers from the company account. A saved policy might authorize invoices under $5,000 when the purchase order and bank details match.
The crucial distinction is this:
- Clarification resolves uncertainty about the desired action.
- Preview exposes the proposed action for inspection.
- Confirmation grants permission for a known consequential action.
A preview is not permission. Showing “I am about to delete the customer table” does not make deletion safe to perform without approval.
| Situation | Agent behavior | Reason |
|---|---|---|
| Clear intent, low impact, easy to undo | Act and record it | Asking would cost more than the risk |
| Ambiguous target, scope, or constraint | Ask one focused question | Guessing could produce the wrong outcome |
| Meaningful but inspectable multi-step work | Preview the plan and material changes | The user can catch a bad assumption |
| Irreversible, external, costly, or broad action | Preview, then require explicit confirmation | The user must knowingly authorize the consequence |
The agent should also consider urgency. During an outage, waiting five minutes for approval may cost more than a bounded rollback. That does not mean “production incident” becomes a magic word for unlimited autonomy. It means the team should define the rollback policy before the 3 a.m. page arrives.
A concrete design: the invoice agent
Suppose a finance manager tells an agent:
“Pay this week’s approved invoices, but hold anything unusual.”
The agent should not immediately submit 42 payments. “Approved” is clear enough to search for, but “unusual” changes which invoices are eligible. If there is no existing policy, the agent asks one high-value question:
“What should count as unusual: an amount over $10,000, new bank details, a missing purchase order, or any of these?”
That is a clarification, not a confirmation. The agent does not yet have a complete definition of the task.
Once the manager chooses “any of these,” the agent can work without interrupting. It reads the accounting system, checks purchase-order matches, compares bank details with the vendor record, and calculates the totals. Those are read-only checks. They create no external side effect, so asking permission for each lookup would be pointless theatre.
It finds 42 approved invoices worth $186,400:
- 35 routine invoices, totaling $127,640
- 7 flagged invoices, totaling $58,760
Now it shows a preview:
Proposed payment batch
Pay 35 invoices totaling $127,640 from the operating account ending in 4421.
Hold 7 invoices totaling $58,760 because they have new bank details, missing purchase orders, or amounts over $10,000.
Payment date: August 28, 2026.
No customer or vendor messages will be sent.
The preview gives the user the facts that can change the decision: count, total, source account, date, exceptions, and side effects. It does not dump the agent’s entire internal reasoning or 42 rows into the main interaction. The user can expand the list if needed.
Submitting the payment batch is an external financial action and is hard to reverse. The agent therefore asks:
“Submit this batch of 35 payments totaling $127,640?”
That is explicit confirmation. It names the action and its scope. “Are you sure?” would be a poor confirmation because the user has to remember what “it” means.
The agent should ask once for the batch, not once per invoice. The invoices share one intent and one risk boundary. Grouping them reduces interruption without hiding the total. The seven exceptions remain separate because approving a changed bank account is not the same decision as approving a routine, matched invoice.
The production pattern
A robust agent separates preparation from commitment.
It can search, calculate, validate, draft, simulate, and assemble a proposed batch immediately. These steps should be visible in an activity log, but they do not need a modal interruption every time.
At the commitment boundary, the interface should show:
- The exact objects affected.
- The total scope and cost.
- The assumptions and exceptions.
- What can and cannot be undone.
- Any external messages, permissions, or notifications that will follow.
Then use one of three paths:
- Proceed automatically when a saved policy covers the action. For example: “Pay invoices under $5,000 only when the purchase order matches and bank details are unchanged.”
- Preview and confirm when the action is consequential but the user can inspect a coherent batch.
- Stop and escalate when the action is destructive, ambiguous, outside policy, or requires a second approver.
A saved policy must be bounded. “The user approved the last ten payments” is not a reason to approve the next ten. The policy should specify limits such as amount, vendor set, account, action type, and expiry. A confirmation click should not silently expand those limits.
The trade-off that earns the senior signal
Risk is not just probability. It is roughly probability of error × impact of error, adjusted for reversibility, scope, authority, and urgency.
A low-probability mistake can still deserve confirmation if the impact is enormous. Conversely, a moderately uncertain action may not justify an interruption if it only creates a reversible draft.
The textbook mistake is to treat all ambiguity the same. If the agent cannot find a preferred currency for a draft report, it can use the account’s default and mention that assumption in the preview. If it cannot tell which bank account should receive $80,000, it must ask. The difference is not linguistic uncertainty. It is whether the uncertainty changes a costly outcome.
Another mistake is treating confirmation as a substitute for good design. If users see 30 confirmation dialogs in a morning, they will approve them mechanically, disable the feature, or route around it. That is the first symptom of a bad policy: the confirmation rate is high, but the user’s attention is not. Batch related work, make low-risk authorization durable, and reserve interruptions for decisions that genuinely belong to the human.
If the user does not answer, silence is not consent. The agent may finish the read-only checks and save the preview, but it should hold the payment and state exactly what is waiting. In an urgent system, it can escalate to a named backup approver. It should not guess merely because the person is offline.
What they’ll ask next
How do you decide whether an action is “high risk”?
Use consequence, reversibility, financial or operational scope, external visibility, privacy impact, authorization, and urgency. A label such as “medium risk” is useful only if it is tied to observable rules.
What if the user explicitly says, “Pay them all”?
That establishes intent, but not necessarily sufficient authorization for every account, amount, or exception. If the scope is clear and a policy permits it, proceed. Otherwise show the exact batch and request confirmation at the financial commitment boundary.
How do you learn from repeated approvals without becoming reckless?
Offer to save an explicit rule with limits and an expiry date. Do not infer permanent permission from clicks, silence, or a pattern of past approvals. Every automatic action should remain auditable.
The line to use in the room
“I separate intent uncertainty from action risk: clarify only when the meaning could change, preview the consequential plan, and require confirmation at the irreversible boundary while letting bounded, reversible work run without interruption.”