Confirmation Prompts in Microsoft 365 Copilot - Building Agents That Ask Before They Act
There is a moment in every Copilot agent project where the conversation gets serious. Up to that point you are building something that reads data and answers questions, and the worst case is a wrong answer. Then someone asks for the agent to actually do something, create the invoice, send the email, update the record, and the risk profile changes completely. Now a misunderstanding does not just produce a wrong answer. It produces a wrong action, in a real system, that someone has to unwind.
That is the exact problem confirmation prompts are built to handle. When you extend Microsoft 365 Copilot with a plugin that can take actions, you can require the agent to stop before an action runs, show the user what it is about to do, and wait for a yes. Microsoft's documentation on confirmation prompts covers the mechanics. What I want to add is why this small feature is one of the most important design decisions in the whole build, based on the agent work we do for Australian businesses.
Read actions and write actions are not the same risk
The first thing to get clear is the difference between an agent that reads and an agent that writes, because it shapes everything.
A read action fetches information. "Show me open orders for this customer." If the agent misreads the request, you get the wrong list, you notice, you rephrase. Annoying, not dangerous. A write action changes something. "Raise a credit note for this customer." If the agent misreads that one, it has now created a financial document in your accounting system, and the cost of the mistake is real. Someone has to find it, cancel it, and explain it.
Confirmation prompts exist to put a human checkpoint in front of that second category. Before the agent runs a write action, Copilot shows the user a summary of what it intends to do and asks them to confirm or cancel. It is a deliberate speed bump, and it is the difference between an agent you can trust with real operations and one you can only trust with lookups. My rule of thumb on client work is simple: anything that changes data, sends a message, moves money, or touches a system of record gets a confirmation prompt. No exceptions, no matter how clever the model looks in testing.
Designing that boundary, which actions are safe to run silently and which absolutely need a human yes, is one of the core judgement calls in building these agents. It is the kind of thing our AI agent builders think about from the first design session, not after something has gone wrong in production.
How the confirmation actually works
The mechanism is straightforward, which is part of why it is easy to underuse. In the plugin definition for your action, you mark it as needing confirmation. From then on, when Copilot decides to invoke that action, it does not just fire it off. It surfaces a confirmation card to the user showing what the action is and the values it is about to use, and the action only proceeds once the user approves it.
The detail that matters here is what the confirmation card actually says. A confirmation prompt is only useful if the user can understand, from the card alone, what is about to happen. "Confirm action?" with no context is worthless, because the user has no idea what they are agreeing to and will just click yes out of habit. A good confirmation shows the specifics: which customer, what amount, which system. The whole point is to give a human enough information to catch a mistake before it happens, and that only works if the card tells them what the mistake would be.
So when we build these, we spend real time on the wording and the parameters shown in the confirmation. It is not an afterthought. It is the entire safety mechanism, and a vague confirmation is barely better than no confirmation at all.
The habituation trap
Here is the thing that keeps me honest about confirmation prompts, and it is a genuine weakness worth naming. If every single action throws up a confirmation, users stop reading them. They learn that clicking "confirm" is just the price of getting things done, and they click through without looking. At that point the prompt is theatre. It feels safe, it satisfies an audit requirement, and it catches nothing, because nobody is actually reading the card.
This is a real human-behaviour problem, not a hypothetical. Anyone who has clicked "I agree" on a terms-of-service page they did not read knows exactly how it works. So the design goal is not "confirm everything". It is "confirm the things that genuinely warrant a human pause, and let the safe stuff flow". If you make people confirm reading a customer's phone number, you have trained them to ignore the prompt that asks them to confirm deleting the customer.
Getting that balance right is a judgement call, and it depends on the specific business and the specific consequences of each action. A prompt on a low-stakes action is friction with no payoff. A missing prompt on a high-stakes one is a landmine. The skill is knowing which is which, and that comes from understanding the business, not just the technology. This is where sitting down and mapping out what an agent should and should not do without asking becomes the valuable part of the work, and it is a big part of what we cover in AI strategy engagements before a line of the agent gets built.
Where this fits in a safe agent design
Confirmation prompts are one layer, and I want to be clear they are not the whole safety story. They are the last line of defence, the human checkpoint right before an action fires. Around them you still want the other layers: scoping what the agent is allowed to do at all, limiting the permissions of the account it acts under, logging what it did so you can audit later, and testing hard against the ways a user might phrase something that leads the agent somewhere you did not intend.
I think of the confirmation prompt as the seatbelt. It is essential, you should always have it on the actions that matter, and it will save you in a crash. But you do not drive recklessly just because the seatbelt is there. The confirmation catches the case where the agent misunderstood and the user notices in time. It does not fix an agent that has too much power or too little oversight in the first place. Both matter.
For write-capable agents I also push clients toward reversibility wherever the underlying system allows it. An action you can undo is far less frightening than one you cannot, and where an action is genuinely irreversible, that is precisely where the confirmation needs to be clearest and most detailed. Deleting something permanently deserves a more emphatic, more specific prompt than drafting something that sits in a review queue.
My honest take
Confirmation prompts are a small feature that carries a lot of weight, and they are the thing that makes me comfortable putting an action-taking Copilot agent in front of real users. Without them, a write-capable agent is a mistake waiting to happen, because the language model will occasionally misread intent, and when it does you want a human between the misunderstanding and the consequence. With them, thoughtfully placed, you get an agent that is genuinely useful and genuinely safe.
The honest caveat is that they are only as good as the thinking behind them. A confirmation on every action trains people to ignore confirmations. A vague confirmation card gives people nothing to check. The mechanism is easy. Using it well takes real judgement about your business, your actions, and your users, and that judgement is where the value actually sits. This is not a feature you switch on and forget. It is a design decision you make action by action.
If you are building a Copilot agent that does more than answer questions, that actually takes action in your systems, this is exactly the sort of thing worth getting right early rather than patching after an incident. That is the work we do every day. Have a look at how we approach AI agent development, or get in touch and tell us what you want your agent to do, and just as importantly, what you never want it to do without asking first.