Inside the Microsoft 365 Agents Toolkit for Developers

Samuel
Hello, Sébastien, and welcome to Mastering AI with the Experts. Thank you so much for joining us today.
Sébastien Levert
Thanks for having me, actually. It's good to have a little chat while we're having a very snowy day here in Montreal.
Samuel
Yes, it is very snowy and very cold as well. Sébastien, you're a principal product manager for Copilot extensibility at Microsoft. Can you please start by briefly describing what it means, actually — in which part of the extensibility of Copilot you're working on?
Sébastien Levert
Yes. Yeah, so my team is the Copilot extensibility and development platform for Microsoft 365 Copilot. So we are the team that is responsible for building the agent platform in Microsoft 365 Copilot. So that means bringing all the capabilities that Copilot has by default and exposing them as capabilities in agents. When you're using, for example, the agent builder that is built into M365 Copilot, you're going to be able to add sites, add connectors, do code interpretation, do graphic art, and so on. All these capabilities are what our team is kind of exposing to that. So we have a strong partnership with the Copilot Studio team that is building the UX for building agents. And my role specifically is for another audience — an audience that is bringing agents the same way, but built with different tools, really mainly for the developer audience or enterprise or LOB developers that want to bring a little bit more control over the agents into M365 Copilot.
Samuel
Great. So we're going to talk about pro-code tools today to extend Copilot. But just before we jump in —
Sébastien Levert
Yep.
Samuel
When you talk about agent extensibility, like in Microsoft 365 Copilot today, I know it's not clear for everyone what an agent is. How can you extend Copilot with agents? So what does that actually mean in concrete terms? And why should both businesses and technical leaders care about this right now?
Sébastien Levert
I think agents are ways to automate business processes. You are, I don't know, an engineering team and you want to be able to handle the tickets, the support things, and you want to automate some of them. You want to use AI to go deeper into your logs and infer some context from it. That's what agents really are. For us, we believe that why you would even care is because you want to use AI for more than just plugging into your productivity data. Yes, productivity data is amazing and we can do really, really cool things with that. But what if you want to connect to your own third-party systems, or to your own SaaS that you're using, or to your own internal tools? So that's really why we think that extensibility is there — to bring
Samuel
Mm-hmm.
Sébastien Levert
Copilot a little bit further, make it even more integrated into your business. So it becomes your de facto landing page. I go to Copilot, I click on my service ticket agent, and now I can do everything from there. I don't need to go to my system. I don't know. Then I can cross-reference so many things around all of that that it just makes sense. So that's really how I'm thinking about why they should care. Automate your business processes and make sure that everything fits within Copilot.
Samuel
So it's not just about retrieving data, right? It's also acting on data, acting on third-party systems. You were mentioning organizations using their own SaaS, using their own third-party systems. So it's bringing those workflows that were historically done by human beings — let's be real — and having an agent go through them.
Sébastien Levert
Yep. Yeah.
Samuel
Directly in M365 Copilot, right? What's the advantage of doing it in Copilot versus having a standalone agent, even if it's built with Copilot Studio, for instance, or the agent toolkit that we'll talk a bit more about later.
Sébastien Levert
I think the biggest advantage of bringing that to M365 Copilot and building what we call declarative agents — basically really native M365 Copilot agents — is the proximity to your productivity data. And that's where it unlocks so many things. Your productivity data has so much potential that when you go to your SaaS, you're losing all of that context. But now you can cross-reference the
Samuel
So, thank you.
Sébastien Levert
emails you got, the conversations in Teams you had with your third-party SaaS now. Because then it can say, I had a conversation with John yesterday about this ticket. He gave me a good way to respond. Can you craft me an answer for my service portal and then send that to the user requesting help? And now it just bundles everything together.
Samuel
Mm-hmm.
Sébastien Levert
The update to the user — call it done. And I think that's really where having your productivity data matched with your line of business and really business-critical data changes everything. So being in M365 Copilot really changes all of that. And sometimes you don't know where the data is coming from. You don't remember. I had a chat with Samuel yesterday. Was it a Teams message? Was it through a comment in a Word doc? Was it an email? Was it in an ADO ticket, like in GitHub or in Azure — where was it? Well, in that case, Copilot doesn't care. It has access to all that productivity data and then can bring it to your third-party data. So that's really where I think the big value is.
Samuel
Yeah, this is really well described. Actually, fun fact — just before we connected to record this episode, I had to prepare for a demonstration for one of my customers. I just didn't remember what we agreed should be demonstrated. I asked Copilot: can you tell me what's been agreed? And look at my email, look at my recording, because we had a previous meeting that was transcribed and recorded. And it just listed what we agreed to be demoed on that day. And then I built one of my own agents that helped me use some templates of demos I did in the past and readapted them based on the customer context and industry, et cetera. So I was able to call this agent afterward and get it to start building a draft of the demo that we'd be presenting. So yeah, it's very powerful. I do agree.
Sébastien Levert
Absolutely.
Samuel
Agent creation in the Microsoft 365 Copilot world — I won't say Microsoft broadly because we also have Azure AI Foundry — but in M365 Copilot, is done through Copilot Studio. And Copilot Studio, which was previously part of Power Virtual Agents, is often positioned as a low-code platform. You've been working a lot with the pro-code Agent Toolkit.
Sébastien Levert
Yep.
Samuel
So you're on the pro-code side of things. What is it really, and what does it unlock that low code alone won't be able to — like, especially when we're talking about scaling, control, engineering discipline? I know it's a totally different way of creating agents. So can you explain what the difference is and what the advantage of it is?
Sébastien Levert
Absolutely. So I think it's more around meeting the agent builders where they are. When I'm thinking about somebody that is an information worker, probably I don't want to bring them into Visual Studio Code or even using the Copilot CLI and bring them into a terminal. Even these days, actually, we're seeing more and more of these information workers being interested in that new way of working in an agentic way. I'm going to come back to that a little bit later, but like —
Samuel
CLI — being...
Sébastien Levert
In the terminal, like literally being inside a terminal window — that is the GitHub Copilot version of that. So like building and so on. In our case, we want to meet the devs where they are, and they are in their dev tools. They are tasked to build agentic scenarios for information workers, so that the information workers can use corporate-approved agents that are useful. Usually these agents are massive agents. Like, okay, we want to build that HR agent that covers all of the scenarios, that connects to all of our Workday data, goes to our internal employee registry, goes to like our really simple, almost access-database-like vacation system — it wants to do all of that in a coordinated single agent. You can ask low-code makers, local people, to actually do that, and that is absolutely fine. But where we want to meet the devs is to meet them where they are, because they're probably building the API. They're probably building some of these systems. So we want to meet them where they are — in Visual Studio Code — where they can build, publish, and use all the engineering practices that they're used to. One of them is like, hey, we're six of us working on the same agent.
Samuel
Mm.
Sébastien Levert
How do we do that? Well, we use source control. We use GitHub. We use Azure DevOps to store the code. We can do versioning of that code. We can do pull requests. We can review every single line that was changed to make sure whether it really brings value or whether it was more like a refactor that didn't bring any value to the actual agent. We also have the ability to work six at a time on our own version of the agent, each bringing more capabilities. I'm focused on this area. You're focused on this other area. So that's really kind of building that team of agent builders coming together. And the output — or the outcome — of that is that agent that you can then put automatically through your own continuous integration process. So you push to your source code, it gets built,
Samuel
Mm.
Sébastien Levert
automatically gets approved by an admin, then the admin automatically puts that into the store and it becomes available to everybody. While we do have the low-code and no-code ways of building these agents, we believe that there are key scenarios that offer high value for enterprises that want to bring some of that. Something to think about also is the way we're thinking about
Samuel
Mm-hmm.
Sébastien Levert
M365 Copilot extensibility — is that there's a lot that you leave behind, or I would say don't have to think about. When you're building an agent as a dev today, would one of your first reactions — especially if you're in the Microsoft ecosystem — be: hey, I'm going to go to Azure AI Foundry and I'm going to build an agent in Foundry. And there I'm going to have to build my own orchestrator. I'm going to have to build and manage my own models. I'm going to have to do my own function calling to third-party systems. I'm going to have to build my own retrieval-augmented generation, or RAG, system myself. And so on — for some scenarios, that totally makes sense. But that's one of the complexities we remove entirely. We're a managed solution. Bring your systems. We're going to connect to them.
Samuel
Mm-hmm.
Sébastien Levert
Bring your instructions and your data sources that you want to RAG on top of — especially in the productivity space, we already have it. So we're just going to pull everything together. We're going to do your function calling. We're going to do auth for you. We're going to do responsible AI on top of this. So if there's some dodgy answers coming back from your API or your third-party system, we're going to protect the user from that. All of that without you having to basically code anything crazy. Just bring your systems in a very standard way. We are using the standards of the industry — either through an API or through an MCP server — bring your systems, and then our M365 Copilot engine will take care of that automatically. From there, it's like a time-to-market that is absolutely crazy. You can go from no agent to an agent within a couple of hours, hosted and deployed in production, without any extra costs involved, because it's part of the license that you have — either from Copilot Chat or from M365 Copilot. If you're not using any grounding data, you can use it on Copilot Chat by default. You don't even have to have the M365 Copilot license. You can just use Copilot Chat and automatically connect to your third-party systems — absolutely — at no extra charge beyond your M365 regular base license.
Samuel
Is it the same architecture as the Copilot Studio pro-code tool, a local tool?
Sébastien Levert
No, it's a different architecture. It's a lot more integrated within the M365 Copilot experience. When we're thinking about the agent builder capability, it's the same architecture as the agent builder capability. It's just that agent builder is really, really focused on the information worker. So it doesn't allow you to bring third-party systems. It doesn't allow you to...
Samuel
Mm-hmm.
Sébastien Levert
Yeah.
Samuel
Mm-hmm.
Sébastien Levert
Have all of the settings that the devs can have. So they have more levers, more settings, more knobs that they can turn on. But in the end, they are the same architecture. When we go to Copilot Studio and build a custom agent that connects to Dataverse, that connects to whatever other systems — that's another architecture that is closer to the custom engine agents, which is: you own everything, but we connect with you. So we make sure that the prompt gets sent to you. We do some checks and validation on top of that, but you're basically on your own. In that case, Copilot Studio handles all of the heavy lifting for you. You don't have to build the orchestrator. You don't have to own the models and so on. But it's two different architectures.
Samuel
Okay, and that's really good to know. So I'll assume that if I start creating an agent in the local tool or in the pro-code tool, I can switch to the other experience, right? Because it's not exactly the same architecture.
Sébastien Levert
So today you cannot. We have plans — we're thinking about that a lot — on how we could expand that. So start in agent builder, export that to your pro-dev tooling, just to maybe expand on top of what an information worker has done. Then they hit limits like: okay, my tool cannot do more than that. Fine, let's give it to the dev team and the dev team will take it further. Or the other way around: my pro-code thing in the end is only a couple of grounding sources, a very complex instruction field — but instructions are instructions. So maybe go back to agent builder and continue there. So we have plans around that — nothing confirmed in the roadmap just yet.
Samuel
Okay, it might be in the plan. You were mentioning Agent Builder — just for the benefit of our audience that might not know what Agent Builder is, specifically given the fact that we've been renaming products from time to time.
Sébastien Levert
Yeah.
Samuel
So Agent Builder is — when a user, an end user, is creating a simple agent that is basically grounded on organizational data or on the web. So it's the lightweight experience that is available inside of M365 Copilot, right? Is that what you're saying?
Sébastien Levert
Exactly. It's the — it's the embedded version of that. It's like, you don't have to go to Copilot Studio. It's really: you stay within Copilot to build an agent that runs inside Copilot.
Samuel
Thank you. So when does low code stop being enough? Like, what are the clear signals — organizational or operational — that tell a business decision-maker that it's time to move to pro code? I like the fact you mentioned source control and multiple people working on agents, because that's one of the challenges I have often when you work in Copilot Studio: you can't go back. If you made a modification to your prompt, you can — if you didn't save it yourself in OneNote or Notepad or whatever — you're kind of stuck with the new version. I'm not seeing how easily I can work in a team on Copilot Studio right now. So I think those two points are really, really interesting. But what else? What are the clear signals a business leader should look at when deciding which way to go?
Sébastien Levert
I think there's also a matter of ownership. Like, sometimes when you're going to build an agent, you're going to want the user to own it because he's the subject matter expert on that thing. And then fine — that is where I think low-code, no-code really makes sense. The user is the owner. Now, when you bring that to the world where you're building this entire HR complex agent, who's the owner of that? It's not John. It's the HR department that is the owner of that. The same way when you build your finance system, it's not one of the devs that is the owner. It's the finance department that is the owner of that, or IT, depending on how the organization is structured. So I think that is also something — like if you are looking to have shared accountability on an agent, you should probably build it in a way that makes it possible to have shared accountability, shared ownership. So that's definitely another thing we're looking at. One extra — and I was thinking this is kind of one of the last ones — is: you want to build for your organization. That's where I think low-code, no-code absolutely makes sense. If you're building for more than just your organization — a good example: we haven't built Researcher in Copilot Studio because it needs to be acquirable by all organizations that are M365 Copilot license holders. So when you're building that, and there's a store for agents today that is available — so as a service organization that wants to build
Samuel
Yeah.
Sébastien Levert
an agent that connects to their own SaaS — think ServiceNow. ServiceNow has their own agent that lives inside M365 Copilot, that has been built using our pro-dev tooling, and now connects to all the customers of ServiceNow in the world. So that's another way. Like if you want to distribute your app at large across organizations,
Samuel
Yeah.
Sébastien Levert
you will want to have a solution that is built the way that the underlying system it relies on — ServiceNow in that case — is built. ServiceNow is built by a team of devs and product managers and designers and scientists. You want to be able to package the agent the same way that the rest is also being made available. So that is definitely something we're thinking about. Like, your distribution channels allow for different things. When you're an agent builder, when you're an information worker, you want to distribute to your team or just around you, maybe to your department. But then if you want to make it a little bit broader, maybe you go to Copilot Studio where you can have maybe a couple of departments together. But if you want a full org-wide or you want to do cross-organization, I think that's another good reason to go that route.
Samuel
Yeah, I like that you mentioned cross-organization, because I think — I mean, we're just at the beginning of this agentic AI wave — and I've seen a lot of organizations investing heavily in building very cool and very powerful agents, and it might even become attractive for, let's say, a retailer building an agent for their own organization to then say: maybe I want to resell this on the marketplace as well. It's not just that I'm building it for my own organization, right? It's that I can sell it afterward based on the work we did with our organization.
Sébastien Levert
Yeah, exactly. And I really think that when you decide what type of agent you want, it's one of the criteria you need to evaluate — okay, that's going to drive which tool I want to use. And also it can be: do I want to live on the Copilot orchestrator, or do I want to have more levers and more knobs? Then I go one step further, which is: okay, I'm going to host it in Azure.
Samuel
Mm. Okay.
Sébastien Levert
I'm just going to connect it to Copilot rather than make it native to Copilot. So depending on the scenarios, depending on the proximity to the Microsoft 365 data you need, you're going to have to change your approach a little bit.
Samuel
People often say you need to ship agents like software. So what does that actually look like in practice? Once you've decided to go pro-code, what's the workflow? Like versioning, environments, CI/CD, rollback — et cetera, et cetera — in the real world.
Sébastien Levert
So there are — we see that there are two approaches that are transitioning from one to the next right now. So the way today — or yesterday — yesterday you were building agents. We have a VS Code extension that is called the Microsoft 365 Agents Toolkit, where you create your agent from there. It creates a bunch of JSON files, and these JSON files are
Samuel
Mm-hmm.
Sébastien Levert
the levers and knobs that you have on top of Copilot. So you create that, you configure that, you can use GitHub Copilot to help you expand and change the instructions — really useful. GitHub Copilot to create instructions is a master at that because it knows your context, it knows what the systems you're connecting with are, and then it comes up with the instructions that will be the most effective for the agent you're building, which is actually really cool when you're building in an agentic way. And then you push that to your team. So we have ways to provision the agent directly to Microsoft 365 Copilot and share it with a couple of your teammates to test. Then afterwards you can broaden the scope to your department. Then you're like: okay, I'm happy with this. Now let me put that into source control. So you add that to your source control. And then from there you can do a full CI/CD pipeline. We have a CLI — Command Line Interfaces — a little tool also built with the Agents Toolkit that allows you to script the deployment of these things. From: okay, I want to build to my dev environment — I'm going to use the dev environment, I'm going to build my agent, deploy to the dev environment, have my QA team test it there. And I want to have my integration environment where I can now really have all of these third-party systems and make sure that you have it there, then you have it. And then after that, we're going to have the prod environment. So all of that through whatever tool you're using for continuous integration, you'll be able to build these pipelines that allow you to go from one to the other, put on some approvals, and so on. That is not specific to the Agents Toolkit or to building agents — that's just how software is being built. Now, one thing that we're seeing more and more is agents building software.
Samuel
Mm.
Sébastien Levert
So when you think about GitHub Copilot, GitHub Copilot is an engine in itself that can reason over your code, it can reason over your spec, it can reason over anything and generate the actual code that needs to be built for this. So we're now coming with a set of different agentic experiences to help devs be really powerful. So one of them is agent skills that basically teach the agent a new skill — how to build an agent, how to build a declarative agent. So now it knows how to start, how to create, how to add the web search capability, how to add this and that. And then it knows. So now it becomes an expert at building declarative agents that live on top of Microsoft 365 Copilot. So we have that available now. Something we launched last Friday — the timing of the recording is really good. We launched last Friday the WorkIQ CLI and the WorkIQ MCP server. What is WorkIQ? I'm pretty sure you've heard about WorkIQ, but WorkIQ is basically the connective tissue that connects your organizational data to your users. But if you're using that in an agentic way now — and that's what we see more and more — people are connecting the WorkIQ superpower, it's called like this, inside their coding agents. So now you can ask questions like: last Friday, we had a meeting with the engineering team. We made decisions. Based on these decisions, can you update my agent based on the decisions that were made in the meeting? So now it's going to go look at the transcript, automatically get all of that back and say, wait a second — we said that we wanted to ground on a new site in SharePoint. It's going to add the site directly inside your SharePoint configuration that says: okay, now I want to ground on this, on top of it. We want to integrate with a new third-party system. Okay, I'm going to go in, I'm going to craft the API integration with our vacation system. It goes and looks at your source code. Wait a second, I just found the reference to the API. I can craft what I need to do. Now, boom, I stitch it all together. So now we're bringing work data — organizational data — inside the life of developers. Because that was always the missing piece. Like, the spec is usually a Word doc lost somewhere in a chat, but now we can actually go and find it, bring it, reason over it, create code that respects the decisions and the design. Call it done and then ship it to the software. So those are two things — more like the experience, UI-based things. Then there's all this new agentic way of thinking about building software.
Samuel
So I'll assume that it has affected or changed the way you code. How do you approach development nowadays? Like, if you compare from three years ago or four years ago?
Sébastien Levert
100%. We can compare to six months ago — it's that fast right now. I think the thing that is mesmerizing for me — like, I'm a PM, but I'm coming from an engineering background. So I used to be a dev lead and I've done my share of coding in the past. I still do a lot of coding. But what I'm realizing is that I don't look at code anymore.
Samuel
Yeah.
Sébastien Levert
I literally look at the outcome and that's it. When I'm building the agent and testing the agent — does that work? I'm all fine. So it
Samuel
So in a sense, it's almost as easy as using the low-code tool, or even easier, because you're chatting with an agent — GitHub Copilot, for instance — an agent that is creating the code for you, leveraging the Agents Toolkit and all the tools available from Copilot Studio. But you don't have to worry about all the backend infrastructure, like you mentioned — orchestration, et cetera.
Sébastien Levert
It is — absolutely. Yep. Exactly, exactly. It really creates that super smooth conversation that is very similar to: hey, let's get into a room and let's just figure out what we're going to build. Now, I'm not saying — like, that's where — I'm not saying don't look at the code. I'm saying that doing really, really rapid progress on an agent is really, really, really interesting, because then you move really, really quick. Then afterwards you go back and you review. Okay. Now I think I have something. Let's review that, and let's use AI to review. Let's use AI to — okay, so this bit, I want to change it. Like this very specific two or three lines of instructions — let's just change it in another way. You want to spin it differently. But in the end, if you're teaching your coding agent the right way to build,
Samuel
Now —
Sébastien Levert
and you're giving it a good steer, you're kind of more like a teammate — like a peer programming session between you and the coding agent. We're realizing that the value we're getting out of this is absolutely stunning. And with the inclusion of WorkIQ in the agentic loop for the devs, now it's not just like: what did my boss say last week — I'll try to remember; I'm going to figure it out. No, now you can just say:
Samuel
Okay. Okay.
Sébastien Levert
My boss said something last week — bring that context back and infuse it in the agent that I'm trying to build.
Samuel
Yeah, WorkIQ gives you access to all documents you have access to, previous meetings that have been transcribed, emails, PowerPoint slides — if you're grounded on it — et cetera, et cetera. Yeah, actually that was one of the challenges I had building some of my agents. I'm very happy to hear that it's releasing now.
Sébastien Levert
Yep, absolutely. It's now in public preview and it's available for all types of coding agents. So we talk a lot about GitHub Copilot, but put your favorite coding agent in there and you can actually talk to it.
Samuel
Switching gears a bit — you're working a lot with customers and partners, so what's a common belief or piece of advice about building Copilot agents that you think is just wrong? Like, yeah.
Sébastien Levert
Oh, that is a good question. I think the first kind of wrong assumption is that you will build a better orchestration layer than Microsoft 365 Copilot can. So it's a little bit — the way I see it might come across a little bit like we're biased. And I don't think that's how I mean it — there is such a huge effort to make the orchestration in Microsoft 365 Copilot as good as possible. You need to realize that all the agents we ship are agents that are built with our own tooling.
Samuel
Mm-hmm.
Sébastien Levert
We're building them all with declarative agents. So if you think our agents are performing and doing some really crazy things — Researcher, Analyst, all the agent modes in Word, Excel, PowerPoint — well, your
Samuel
Mm-hmm.
Sébastien Levert
agent will live on the exact same platform. So I think that's the biggest thing — building with that is very critical. Now, I want to be very respectful of especially people that are doing more than M365 Copilot. Like, let's say you're building an agent that needs to be available within M365, but also outside of M365 — on a website, on, I don't know, by email, via SMS, or whatsoever. Then there are downsides to using our stack, which is: our stack will not allow you to embed your agent elsewhere than M365 and all the collateral — like Excel, PowerPoint, Outlook, Word, Teams. If you are building for your employees, and that's your main target — not the public — I really think that M365 should be your go-to solution. If you go outside of that, then — even if it's not as feature-rich as M365 Copilot is — you need to go there. And that's where I think Copilot Studio plays a phenomenal role, because then they are available outside of that realm, and you can have it also embedded inside M365 Copilot. But if you're really building for employees, no question asked — go all in with declarative agents and pro-code tooling.
Samuel
Okay, that's interesting. So in Copilot Studio, the low-code version, you can deploy your agent on your customer service portal, if you want on your website, inside Power Apps, et cetera. You can deploy it pretty much
Sébastien Levert
Yeah.
Samuel
wherever you want.
Sébastien Levert
Yeah, just about anywhere, right?
Samuel
You know, basically.
Sébastien Levert
You're saying that you use Copilot Studio to go elsewhere?
Samuel
So that's a really interesting point. Copilot Studio, the low-code version, will let you deploy on your customer service portal, if you want on your website, inside Power Apps, et cetera. From my understanding — and it makes sense because you mentioned it — the pro-code version is running on the same architecture as M365 Copilot. So the pro-code will not let you deploy elsewhere, but the low-code version will let you do it.
Sébastien Levert
Exactly.
Samuel
With some limitations that the pro-code doesn't have. Interesting.
Sébastien Levert
Yeah. So you still have the ability to do pro code and go elsewhere. But as part of the Agents Toolkit, the types of agents you can create — you also have custom engine agents. Then that's really where you — I don't know if you remember, maybe 10 years ago, where we had that pizza-as-a-service infographic, where if you're ordering pizza, well, you don't own anything. The only thing you own is the pizza. But if you are baking the pizza at home and you need to do your own crust and you need to do everything, you own all of the layers of the stack. And we're back a little bit in that world. If you're in the declarative agent, you basically own a small slice of it, but the quality is still very great. You don't have to own all the pieces, but if you want to go to complexity and because you need it,
Samuel
Yeah.
Sébastien Levert
then you have the option to own more slices of that pizza. And I think it's important to realize that there's a balance. You will want to be somewhere in that continuum — from, I'm building in agent builder as an information worker, to I'm building in Azure AI Foundry and I own everything — and then I need to own deployments, runtime, and so on.
Samuel
I love the analogy. It makes total sense. If you could give leaders one piece of advice to avoid a painful rearchitecture later, what would it be?
Sébastien Levert
Start with the audience. Start like: what are you trying to do? What is the target audience of this agent? Is it five people, a hundred people, 10,000 people, 200,000 people? Based on that, I think you're going to want to make different choices to deliver your agent. You'll want to think about, like, how — especially in this wave of AI where we're talking about disposable software — like, I'm building an agent. It's good for that event. Then afterwards that event is gone. It was super useful while it happened; afterwards it's just straight to the bin. Well, you need to think about how durable you think the agent will be and for how many people will this agent be. So I think that's what will trigger some of the decisions.
Samuel
Yeah.
Sébastien Levert
Take, for example, my HR support department — it will start with an agent. And then at some point, you're going to hit the limit. You're going to hit: we want somebody to talk to a human. Then the agent will just respond with: okay, here's the ticket that I've created for you in our HR system. But until that point, you might have just interacted with an AI agent up to a certain point. But this is still a big piece of software. And you want to be able to handle that through versioning. You want to be able to go back. You want to be able to roll back to a previous version because you realize: no, we broke everybody. You want to be able to go back to these things. That's — I'm thinking about these scenarios first. Also, I think in the world of AI we need to think about: okay, is it workflow-based? Is it so prescribed that it needs to follow this very specific set of steps? Or is this very open-ended — let AI figure out what needs to be done. And that is where I think we see more and more that declarative agents are 100% AI-driven. You can have some instructions that will guide the AI agent. Instructions are like instructions to children, right? They follow
Samuel
Yeah.
Sébastien Levert
them sometimes. They follow them a majority of the time. Sometimes they're going to go off script, and that is expected at this point in the world of AI. So if you want to really go through a workflow, then maybe that's where you want to have a lot more control — either using the low-code, with boxes in Copilot Studio, or you want to build your own orchestration so that way you can own every single step of the user journey. Well, those are the two things that I would love to have people think about before they go all out into an M365 Copilot agent project.
Samuel
Yeah, thank you. And I like your analogy about bringing it to a child. I think I will reuse this one for my next presentation. Makes total sense. Like, listens, but sometimes it doesn't. Yeah, it summarizes my experience with my kids, I can tell you.
Sébastien Levert
Haha! Just wants to do its own thing. And that's why you have the thumbs down. And by the way, use them. We react to them. We know when things go bad and we improve based on that. So use them — tell us what happened and we're going to react to improve whatever component was broken there. So that's a signal back to the AI, telling the AI that was bad.
Samuel
Yeah. Yeah, I'm telling all my customers: use it, use it. Like you said, we're very reactive. I think, in that — I had a conversation with Aaron Chapple, who is our CVP of the commercial area. And he was explaining how we have this really tight feedback loop between the customer and the engineering group. And in all my years doing Microsoft products, I've never seen a time where we're reacting that fast to customer feedback — it comes from those thumbs up, thumbs down inside of Copilot Studio when we're talking about agents.
Sébastien Levert
Yep. And please do thumbs up when things go right. It's always like — you know how it is — you read these feedbacks and they're always very negative. And that's okay, because in a way, that's good. No news is good news. But sometimes like, 'this was awesome' — it's fun to read some of those sometimes.
Samuel
Sébastien, we're almost at the end of our time. So I have two questions left. Those are my signature questions. First one is, on a more personal note: what's the single AI habit or workflow that has had the biggest impact on your own productivity?
Sébastien Levert
I'll wait for you to be back.
Samuel
It's up. I have a fan but I haven't plugged it yet.
Sébastien Levert
Is your camera heating up, or is it your battery?
Samuel
Yeah. No, it's not — it's because I have an internal one, but I have a fan on it because it just heats up at the bottom. Yeah. In any case, it should be good until the end. I'll plug in my fan.
Sébastien Levert
Okay, so — what I would say is: coming from a dev background, from that side of the house, if you have access to a coding agent — whether you have GitHub Copilot, Claude, or whatever — I invite everybody that might potentially fear going into that world to start using these tools, especially now with the availability of WorkIQ. It's connected to your productivity data now. And see how it might redefine your way of using agents. And I think that's going to boost your love for M365 Copilot, because then you're like: wait a second, I've done that, I've seen that — now I can go and create my own agent in agent builder.
Samuel
Mm-hmm.
Sébastien Levert
That will replicate these scenarios. It's just — it's really, really interesting. Like, one thing: it makes me very productive to live in the terminal, but for me it's not like something that is strange to me. I'm used to that scenario. But for people that are not used to that, it definitely feels like, 'oh my God, I'm in the Matrix.' But get familiar with it. There's a lot of really cool innovation also happening in that space for personal productivity.
Samuel
Wow! I'm not a dev at all. That was one of my biggest regrets in my career. And you just convinced me to start coding, or revive coding. I don't think I'll become a coder, but —
Sébastien Levert
I think everybody is into coding these days. And yeah, that's one of those things — like you have an idea, just express it, say it. And the number of magical things that will happen is quite phenomenal. And sometimes it's just software for yourself, and that's absolutely fine. And sometimes it's just: hey, one of the things — like, I have all these pictures in that folder and I want to rename them using that format. How do I do that? Open a coding agent, just hit enter — it's going to do a bunch of magical scripting for you. You don't need to think about it and it's going to do it. So it's always a little bit of a cool scenario. It can be a little scary at the beginning, but honestly — magical.
Samuel
I will totally try it. And that brings me to my last question, actually. Looking 10 years out — we've seen how powerful these models have become in only three years. What do you think people still underestimate about how AI will change how we work or live? But in that case, for developers specifically — what does it mean? I know a lot of people are scared of losing their job. Some people are just worried about the outputs, in terms of architecture, terms of security, et cetera. Going 10 years into the future, I will just imagine that all of this will improve. So what do you see the world looking like in 10 years?
Sébastien Levert
10 years is really, really far. But I think as individuals, as information workers, as desk workers, I think our daily work will be to drive and steer a team of agents that help you be more productive. That might become autonomous, might become your second brain, but you're still going to be...
Samuel
Yeah, I know.
Sébastien Levert
I want to think that you're still going to be in control of everything that is happening in the AI space. So I think that's really what I'm seeing. You're going to be the manager and mentor of all of these AI agents that will do things on your behalf. I want to believe that the human touch will stay. I want to believe that we're still going to meet as humans and I'm not going to be like just seven AI agents meeting and making decisions. I want to believe that the human has a strong role in this world. I think that's why I love so much the brand that Microsoft represents and how we pitch AI with Copilot — where you're the pilot and there's a Copilot with you.
Samuel
Yes.
Sébastien Levert
Sometimes the Copilot can take over for some time, but at some point it's going to report back to you and say: here's what I did — what do you think? And I want to believe that in 10 years, a lot of the work we'll be doing will be to manage these folks and be more strategic in how we think and how we behave with the rest of our colleagues.
Samuel
And that's how I see things as well. Thank you so much for your time today, Sébastien. I think leaders listening to this conversation will have a clear framework on making the decision of going low code —
Sébastien Levert
Welcome.
Samuel
or pro code, or both — because yeah.
Sébastien Levert
Actually, both. We want people to use both. It's just that there is an option — you have more golf clubs in your golf bag. I'm a golfer, so I went with that analogy. But yeah, you have more than just a putter and a seven iron. You have more than that. Be curious, explore, try it, fail, change, go into Azure, come back to M365. But especially with AI, it's so quick to try things these days that you can make up your mind very rapidly on what really suits you. And from there, you're able to progress and deliver productivity enhancements, deliver value directly to your own business.
Samuel
Thank you so much, Sébastien, for your time.
Sébastien Levert
More than welcome. Thanks for having me. Cheers.
Samuel
Have a great day.