Asynchronous and Proactive Messaging in Microsoft 365 Copilot Agents - When Your Agent Should Speak First
Most people's mental model of a chatbot is a tennis match. You say something, it says something back, you say something, it responds. Turn, turn, turn. That model works fine until you ask an agent to do something that takes real time, or until you want the agent to tell you about something that just happened without you asking first. The tennis match breaks down, and you need a different pattern. In the Microsoft 365 Copilot world, that pattern is asynchronous and proactive messaging, and it is one of the more important capabilities to understand if you are building custom engine agents that do actual work rather than just answering questions.
I want to walk through what this is, where it earns its place, and the parts that are still fiddly, because we've built enough of these now to have opinions. Microsoft's documentation on the asynchronous and proactive flow is the reference for the how. This is the why, and what to watch for.
The problem with the tennis match
A normal request-response conversation assumes the agent can answer roughly straight away. Ask a question, get an answer, within a few seconds. That covers a huge amount of what people want from a Copilot agent, and for those cases you do not need any of this. Keep it simple.
But a lot of genuinely useful work does not fit in a few seconds. Kick off a report that queries three systems and takes ninety seconds to assemble. Submit a request that has to wait for a human somewhere to approve it. Start a long-running data job. Ask the agent to keep an eye on something and tell you when it changes. None of these can be answered inside a single, immediate reply. If you try to force them into the tennis match, the user sits there staring at a spinner, the connection times out, and the whole thing feels broken.
Asynchronous messaging is the answer to the first half of that problem. The agent acknowledges your request straight away, goes off and does the slow work in the background, and then sends the result as a new message when it is ready. You are not held hostage waiting. You get a "right, I'm on it" now and the actual answer a minute later.
Proactive messaging is the answer to the second half. Here the agent starts the conversation. Nobody just typed anything. Something happened in the world, an approval came through, a threshold was crossed, a scheduled job finished, and the agent reaches out to tell the relevant person. The trigger is an event, not a user message.
These two ideas overlap and often show up together, which is why the documentation treats them as one flow. A long-running task starts async and finishes with what is effectively a proactive message when the work is done.
Where this actually matters
Let me make it concrete, because "the agent can message you later" is easy to nod along to and hard to picture.
The clearest case is the approval loop. Someone asks the agent to submit an expense, a leave request, a purchase order. The agent lodges it, tells the person "submitted, waiting on your manager," and the conversation goes quiet. Two hours later the manager approves it. The agent proactively messages the original person: "your purchase order for the new laptops has been approved." No one had to sit refreshing anything. The agent closed the loop when the loop was ready to close. That single behaviour is the difference between an agent that feels like it is actually working for you and one that is just a fancier search box.
The second case is the long-running job. We build agents that pull together reporting from several sources, and some of those queries are genuinely slow. Rather than freezing the chat, the agent says "generating your monthly summary now, I'll send it through shortly," and the user goes and does something else. When it is done, the finished report lands in the chat. The perceived experience is night and day compared to a spinner that might time out.
The third case is the watcher. "Let me know when the Sydney warehouse stock drops below the reorder point." The agent is not answering a question, it is taking on a standing job and then speaking up, unprompted, when the condition it is watching for actually happens. This is where agents start to feel less like tools you operate and more like a member of the team who tells you when something needs your attention.
The parts that are genuinely fiddly
Now the honest bit, because building this well is harder than the happy path suggests and I would rather you go in with eyes open.
The first thing that catches people is that sending a proactive message needs a saved reference to the conversation. When a user first talks to your agent, you get the context you need to message that conversation later, and you have to store it. If you did not capture and keep that reference, you have nothing to send the later message to. So the plumbing has to be right from the very first interaction, well before you actually need to send anything proactively. Teams get to the "now send the notification" step and discover they never held onto what they needed. Design for the async message on day one, even if the first version only does synchronous replies.
The second thing is that proactive messaging is a loaded gun for notification fatigue. The moment your agent can message people whenever it likes, the temptation is to have it message people about everything. Do not. An agent that pings you about every minor event trains you to ignore it inside a week, and an ignored agent is a dead agent. Be ruthless about what actually justifies interrupting someone. "Your approval came through" earns an interruption. "A record was updated" almost never does. The restraint is more important than the capability. We spend real time with clients working out what is worth a proactive message and what should just sit quietly in the agent waiting for the next time you ask.
The third thing is timing and expectations. When an agent says "I'll send it through shortly," shortly needs to mean shortly. If the background job might take ten minutes, say ten minutes, not "shortly." And you need to think about what happens when the slow work fails. An async task that quietly dies and never sends its follow-up message is worse than a synchronous one that errors in front of you, because the user is left waiting for something that is never coming. Every async flow needs a failure path that actually tells the person it did not work, not just silence. This is the sort of edge case that separates a demo from something you can put in front of a business.
The fourth thing is the surface. These agents run inside Teams and the wider Microsoft 365 environment, and how a proactive message shows up, whether it notifies, where it lands, whether the person is even in a state to see it, all depends on that surface behaving the way you expect. Test it where people will really receive it, on the devices and in the apps they actually use, not just in your dev tenant on your own screen.
Where I think this fits
Proactive and async messaging is one of the capabilities that moves a Copilot agent from "answers questions" to "does jobs and tells me about them." That is a meaningful jump, and it is the jump most businesses actually want even if they describe it as just wanting a chatbot. The value is not in the chat. It is in the agent taking work off your plate and coming back to you at the right moment.
That said, I would not reach for this on day one of every project. If your first agent just needs to answer questions from your knowledge base, keep it synchronous and simple, and add async and proactive behaviour when you have a real task that needs it. Building the notification plumbing before you have something worth notifying about is effort spent in the wrong place. Get a useful agent working, then extend it into the async patterns as real long-running and notify-me tasks appear. This is the kind of sequencing our Microsoft AI agent framework consultants help teams get right, because the order you build things in matters as much as what you build.
It also connects to a broader shift we keep seeing. As agents take on more standing responsibility rather than one-off answers, the proactive channel becomes their main way of being useful. An agent that only ever speaks when spoken to is limited by how often you remember to ask it. An agent that can reach out when something needs you is doing a fundamentally different and more valuable job. Getting that behaviour right, useful without being annoying, is a design problem as much as a technical one. If you are thinking about where custom agents fit in your organisation, that is exactly what our custom AI work is about, and it starts with what the agent should actually do rather than which framework to use.
How I'd start
If you want to build toward this, I would begin by picking one real task that genuinely cannot be answered instantly. An approval that waits on a person, a report that takes real time, something you would want to be told about. Build that one flow end to end, including the "it failed and here's why" path, not just the happy case. Capture the conversation reference from the very first message so the proactive plumbing is there when you need it. Then be honest with yourself about whether the interruption is worth it before you turn it on for real users.
Asynchronous and proactive messaging is not the flashiest part of building Copilot agents, but it is one of the parts that decides whether the agent feels alive and useful or inert and forgettable. Get it right and the agent becomes something people rely on. Get it wrong, either by never building it or by over-using it, and you either have an agent that cannot do real work or one everyone has muted.
If you are building custom engine agents for Microsoft 365 Copilot and want them to do actual work rather than just chat, that is very much our patch. Have a look at what our AI agent builders do, or get in touch and we will talk through what you are trying to build.