How to confirm a destructive action, so the confirmation is real
The short answer
The confirmation must be rendered by your interface from the actual pending tool call, and must show the real arguments the call will run with. Never let the model ask for permission in its own words: that produces a sentence that reads like a confirmation with nothing gating the action behind it. Instruct it to call the tool and let the interface stop the call, treat a decline as final, and expire a card nobody answers rather than leaving the action pending forever.
Everybody building an agent arrives at the same idea: before it does something destructive, it should ask. Correct. The trouble is that there are two completely different things that sentence can mean, and only one of them is a gate.
The failure: a confirmation with nothing behind it
Tell a model that destructive actions require confirmation and it will do exactly what you asked, in the way you did not intend. It writes:
Please confirm: reject this submission because not enough documents were provided?
That is plain text. There is no button under it. Nothing is being held anywhere, no call is pending, and the user is staring at a question with nowhere to answer it. If they type “yes”, the model then calls the tool, and the confirmation you thought you had was a piece of theatre both parties performed.
It is worse than no confirmation, for two reasons. It looks like safety, so nobody goes looking for the real thing. And it teaches users to type “yes” to an agent, which is precisely the habit you least want them to form.
The fix is structural, and the instruction is counter-intuitive
The gate belongs in your interface, not in the conversation. The model should call the tool immediately, and your code should intercept the pending call and render a real confirmation from it, with real buttons, before anything executes.
Which means the instruction to the model is the opposite of what people write first. Not “ask before you act” but: call the tool, do not ask in prose, the interface handles confirmation for you. Left vaguer than that, a model will helpfully do both, and asking twice is how you get the fake gate back alongside the real one.
What the card has to show
The real arguments. Cancel order 1041. Remove Priya from Orion. Not “Confirm this action?”, which is a prompt people learn to dismiss within a day, and not the model’s paraphrase of its own call, which can differ from the call in exactly the way that matters.
Render it from the pending invocation. If the arguments are too ugly to show a person, that is a signal about the tool’s design rather than a reason to summarise them.
Handle the answer that never comes
People walk away mid-conversation. A confirmation card with no timeout holds a turn open on your server indefinitely, and a user who comes back twenty minutes later cannot tell whether their action ran while they were gone.
Expire it, and say so in words that resolve the ambiguity: this expired before it was confirmed, so nothing ran. The important half of that sentence is the second half. “Timed out” on its own leaves the user with the exact question they needed answered.
A decline is final
When somebody says no, the model needs to be told not to try again. Left to its own judgement it will rephrase and re-offer, which reads as an agent negotiating with a user about their own data. End the line of action and ask what they would prefer instead.
The three rules, short
- The confirmation is rendered by your code from the pending call, never composed by the model.
- It shows the real arguments, so reading it tells you something.
- It has an expiry, and the expiry message says nothing ran.
Get those right and the gate is real. Get the first one wrong and everything downstream of it is decoration.
Common questions
Why not just have the model ask before it acts?
Because that is a sentence, not a gate. There is no button under it, nothing is actually held, and the user is left staring at a question with nowhere to answer it. Worse, it trains people to type 'yes' to an agent, which is the habit you least want them to have.
What should the confirmation actually say?
The specific thing about to happen, with real values: 'Cancel order 1041' rather than 'Confirm this action?'. A generic prompt teaches people to click through it, and the whole value of the gate is that somebody read it.
What happens if the user never answers?
Expire it and say so. A card left pending holds a turn open server-side, and a user who returns later to a stale confirmation cannot tell whether their action ran. Timing it out with a plain message is the honest outcome.
Should a declined action be retried?
No, and the model needs telling. Left to itself it will rephrase and offer again, which reads as pressure. A decline should end that line of action and ask what the person would prefer instead.
Keep reading
- What an AI assistant should do inside a law firm's software
Why most of a lawyer's time in practice software is small updates after court, and what an assistant needs before a firm lets it make them.
- An AI agent for the back room of a marketplace
Moderation queues, bulk changes and broadcasts: what an agent can take off a marketplace operator's hands, and the confirmations bulk actions need.
- What an AI assistant is actually worth inside a booking product
Why most of what people do in a scheduling tool is procedures rather than questions, and what an assistant has to get right to take them on.
Verb is this, built. An AI assistant you embed in your SaaS with one script tag: it calls your own API as the signed-in user, confirms before it changes anything, and logs every action. Free to build and test.