Extending Microsoft 365 Copilot: Agents, MCP & Production-Grade AI with Yves Habersaat [MVP]

Welcome everybody to the MC65 and podcast. Today we are going beyond one of the most common conversations around Microsoft C-5 co-pilot prompt engineering because one of the organizations start using co-pilot seriously, the question quickly changed from how do we write better prompts to, how do we connect co-pilot to the applications, data, APIs, business processes and knowledge that actually run in our company. And that's where co-pilot extensibility becomes interesting. My guess today is Evis Hava State, Microsoft MVP Business Application Consultant, AI Ashley, its workgroup in Switzerland. Evis works across Microsoft C-65 Azure Dynamics 365 and the Power Platform. This particular focus on extending Microsoft C-65 co-pilot through Agents and Customs. The development. We are going to explore Microsoft 365 co-pilot extensibility, co-pilot studio, Microsoft Fowlery, Azure Foundry. I don't know, they changed the name, Microsoft Graph, Customs Development, MCPs and so on. So yeah, it was welcome to the MC65 and podcast. Yeah, hello everybody, thanks for having me, Mirko. It's a good opportunity for me to be here, so thanks for having me. Yeah, thank you. Before we get technical, can you tell a little bit about your journey, how you get into the Microsoft ecosystem? Yeah, yeah, yeah, of course. Because I started my career, not in the Microsoft world, to be honest, so I started my career on the Apple world. I was a software engineer on the Mac platform and after I moved to iOS, it's kind of like, and it was like a long time ago and maybe like, I don't know, 15 or 20 years ago, I moved to Microsoft world, to be honest. I started my career on the shop on the shop, on the shop, all the world. And after I moved to cloud Azure, M365, it was sharpened on premises, I started my career like this. And after I moved to all the cloud services and at the end, platform and more, most recently, all the AI stuff, to be honest, because it's now a big part of M365 now, because you have an adjunct teach transition now and basically, this is in an ad shell, my journey. But I started my career in the software engineering world, which is today, you may be a world that a lot of people are forgetting because you have all the AI stuff now. And basically, is this kind of activities or jobs have moved to AI? So it's quite different than 20 years ago to then as well. Yeah, you work, you say you work with Chapppoint and I see also you work with Graph, SPFX, Azure Dynamic, how did the background prepare you for the current generation of the AI development? And basically, I have my profile is really, it's really transversal, basically, because in my career, I use to work with many, many products. It could be Microsoft and non-Microsoft products. So basically, I have a large scope of skills on a lot of different technologies and tools. So all my jobs give me a good background because now with the AI, it's a lot of things it's a white topic because you have different kind of approaches, different kind of technologies to do AI now. It could be agentic, it could be more workflows, these kind of things. So basically, all my previous jobs give me a lot of skills to be ready for this AI transition now to be honest. So I move to local, to know, to to procre tools. So yes, all this opportunities and activities in my jobs give me a good good skills to take advantage of in the AI work to be honest. Yeah, and now you are and I, I actually, what do I, I actually, it's a really good question because a lot of people ask me. So my job is just to match functional specification to technical, to technical stack. So I'm taking the lead when the business analysis has been made. We have defined use case in the AI, for the AI staff. We have defined scenarios use case. We have defined, we have made the full business analysis and my job is, okay, I'm taking the, this needs and I'm matching the leads to the technical stack behind the scene. And after I'm leading all the implementation of the, of the tools and the, and the solution when, when we already to start developing. Yeah, interesting. I actually, I see a lot of companies by their employees trainings, especially, yeah, for prompt engineering and, and why will you say that not enough? Only prompt engineering, you mean, nowadays? Yeah, yeah, why, why, why, why, why it's only, you know, why is for, for companies, not enough, only teach the people that the prompt engineering. Ah, yeah, okay, I see, I see, okay, yeah, yeah. And basically, to be honest, nowadays you have, as I said before, you have a lot of different tools and technologies. So, and basically, at some point, yeah, I can, can understand what to do and maybe a little bit guide you. But for me, the role of, for example, architect or software designer, you need to have a human behind the scene because you need to understand the customer. Basically, AI sometimes cannot understand the context of the customer. You see, there's a full need. But behind the scene, to have just a focus on the prompt engineering is, it could be good at some point, but you need to have more because you need to have a behind the scene, some, some people that are architect software engineering behind the scene. And basically, a lot of people who have skills in technologies, information technologies, like SharePoint, like OneDrive, like, I don't know, Salesforce, this kind of stuff. You need to have specialists in those technologies because AI can understand a lot of things. You can guide you, you can generate some great technical or functional documents, but you need to have human behind the scene who take care of it. Okay. Is it good? Is it answering the customer needs, this kind of thing, to validate everything? And focusing on only the prompt engineering for me now is, yeah, it could be an option. If you don't have as a time to train or to invest in accruing some skills, but for me, you need to have good skills in foundation technologies where you want to build your solutions to be honest. Yeah, yeah. And you're an expert in co-pilot extensibility. Where do standard co-pilot, Microsoft, the 65 co-pilot stop and where did co-pilot extensibility begin? Yeah, it's a good question because to be honest, two years ago, when one co-pilot was released and maybe the first session, basically the chat was, to be honest, really minimalist. Basically, you can, okay, it was a chat GPT-like, but Microsoft has evolved Microsoft, crucified co-pilot a lot. Basically, now you have co-work, you have a different kind of feature. So now, the extensibility is less than before because in the past, you developed some plugin, these kind of things. But nowadays, to be honest, at this time, the extensibility is when you want to build something and you want to customize, basically, the orchestrator, or you want to personalize a little bit more, for example, you use your interface, if you want to integrate your agent, not only in Microsoft 365 chat, but for example, you know, website, these kind of things. So the extensibility begins when you want, basically, to customize more, behind the scene, you want to customize a little bit more. It could be orchestrator, if you want to customize your orchestrator, if you want to customize your interface, if you want to customize different aspects, where basically, co-pilot chat cannot do, cannot answer the slide. And I think a lot of people talk about agents. Why do we think so many now in co-pilot agents and why we don't build, I don't know, what one dec co-pilot for everything? Yeah, it's interesting because now, to be honest, Microsoft, as I said before, has evolved a lot. And maybe if we were six months before, okay, agents was a topic. Now Microsoft has introduced the co-pilot co-rocks and to be honest, nowadays, co-pilot co-rocks can replace a lot of agents. And while we think about agents, it's just to separate the things. Because now, we are more in a multi-agent model, where each agent has a scope and is responsibilities. And we don't do a big co-pilot in, basically, it's simple because of performances, first, because when you have a bit set of instruction and tooling in terms of performances, it will be a mess. And the architecture now is more multi-agent. It could be in co-pilot studio, it could be in custom agent in terms of procode or custom development. But nowadays, it's better to have a multi-agent approach where each agent has a scope and is responsibility in terms of just in terms of performance and to have a clear architecture in terms of agents. And when we look at this, I think, basic, I agent architecture, then we have some passwords that I would pass, but we have to think about reasoning, tools, knowledge, and instructions. How did this fit into an I agent architecture? The first thing to do is one of the questions you need to answer is, OK, what is the goal? The first objective of this is the agent. Basically, after agent architecture, it really depends on if you are in a local approach or if you are in a custom dev approach, because it's totally the approach, totally different, because in a custom dev approach, you manage everything, so you manage security, you manage the hosting, you manage a lot of different things. In the local approach, it's really different because you think about, OK, you give the instruction, you select some tools. So basically, the architecture in the local approach is really, it's not as simple as I said now, but it could be really fast because you can determine, OK, I'm going to have the instruction, you can select your tools, you can select a different other agent if you want to connect, but it's really simple. When you are dealing with custom dev or when you develop your own agent, it could be, for example, semantic kernel, agent from all these kind of things, an architect could be really more complex because you need to deal with concepts, really advanced concepts, as I said, security in terms of authentication, if you have multi, if you have for example, multi tools and you want to integrate some NCPs, you want to connect to internal tools protected by some reverse proxies, these kind of things. So basically, you need to reflect more in terms of architecture when you are dealing with custom agents. For example, in Copilot Studio, in terms of architecture, you have, it's really fast to define the architecture. In a custom dev approach, you have to deal with advanced concepts and for a lot of people, it could be difficult because it's really from that channel aspects. In my job, to be honest, I deal with a lot of different needs. It could be custom dev, it could be Copilot Studio, it could be simple agents in agent builder, with really simple needs. So basically, defining an architecture is really based on which approach you want to take basically. You have a general architecture you can make, but after it really depends on the approach you want to local or for code. You see? Yeah. And can we, can, could you describe the anatomy of a typical enterprise, AI agent? Oh, yes, I can. Basically, if you want to talk as simple as possible, when you have the needs, for example, it could be an IT support agent, for example. And basically, it could be, it could be, you have a set of things, basically, but after nowadays, as I said, you have this multi agent approach. And basically, I put, I put the first agent as the front, like a front end. So this is the front agent. And this front agent will route all the, all the requests across, for example, different agents. So, for example, if the user is asking about, I don't know, Salesforce question, for example, you will route all the requests to the Salesforce IT support agent. You see? So basically, for some customer, we have made this kind of architecture because each agent take care about the scope. It could be for products like Salesforce, it could be for m 365, these 10 of steps. And behind the scene, each agent has a set of instructions and a set of two. And nowadays, it's better to use MCP servers because the MCP server allows with universal plug for, to integrate multi services with AI. So I have a set of MCP server. And I have also some internal knowledge sources. It could be like GERA, it could be like service knowledge base, it kind of fix. So you have a set of instruction per agent. And this, those instruction define the scope of the agent and what is the role of each agent and after, you have a set of MCP server and maybe knowledge sources could be, PDF values. It could be multi kind of, multi kind of data sources. And after, when a user is requesting, for example, to the main agent after, it will define, okay, I need to delegate this task to the respective agent. So let's a little bit look into the possibilities or the co-pilot still you were, do you set fit into the overall architecture? Co-pilot Studio, to be honest, it's a local tool from Microsoft first. And in terms of architecture, co-pilot Studio is really, the, the, the file for, for maker, basically for, for people who are not developers. And in terms of the architecture, basically, for example, if we, if it takes the example, like to before the IT support, for example, co-pilot Studio will fit because in terms of architecture, co-pilot Studio will do the job because you can define, in some time, you can define MCP server, you can integrate ECD some, some external knowledge sources or internal knowledge sources if you want. After, as I said before, if for example, you have use case where you want to customize a little bit orchestrator because behind the scene of co-pilot Studio, you cannot customize the orchestrator. So you activate the AI orchestrator, that's all you cannot, for example, customize the priority of, for example, the task you want to achieve because behind the scene co-pilot Studio will define, okay, your plan, and after it will execute it. That's issue, if you want to have a little bit more customization. In this case, you need to use custom dev with, for example, semantic terminal, long chain, age of the framework most recently because Microsoft has released this framework. And in this case, you carry, easily customize orchestration. You can define some more flows, you can, you can customize what you want. And co-pilot Studio has an architect that is really defined for build roles and makers because it's really simple to have an agent working. The only problem with co-pilot Studio and you need to take care of this because when you define, when you choose your path and maybe you define your architect, you need to take care about the license because it's a big part of every solution now. Nowadays, co-pilot Studio has evolved a little bit in a pay as you will model and you need to take care about cost estimation because based on what you want to achieve, sometimes it's better to make a custom dev because after you roast where you want and you take care about all the costs and you can estimate more easily than now because with the co-pilot credits approach is sometimes difficult to predict how much, how much it costs for one month, two months and this kind of thing. And what are the limitations from co-pilot Studio when I shall choose then I think Microsoft or a phone, I don't know what's that really name, but when I have to say, I must do completely custom development. The first question to answer is, do I need to customize or question? That's the first for me, because this question will tell you, if you don't want to customize or question to go deep in all the or question is made or the plan is generated, you can use the approach with co-pilot Studio. For example, H&B there also, sometimes you have simple use case, you can use these kinds of tools, but if you want to customize the or question, you need to go to specific development and in this case you need to, you need to, you foundry for the model or if you have your own platform, because the advantage of custom dev is you want, you can integrate models that are not or state in Microsoft for me, if you want. You can use foundry models, but also if you have AWS or Google platform or Google platform for me, and you have a set jab now, for example, or you have deployed a model externally, you have the capability to integrate those models directly in your agent when you use custom dev approach. This is also an advantage. And after you can customize or question, all the plan is generated, all the things will go in the agent, foundry, the problem of foundry nowadays is at the beginning, foundry was just a model or state platform, when you see back a few years ago, it was like that, just simple model catalog and you deployed nowadays, Microsoft does evil this product to have like, okay, you can create agents with co-pilot Studio like user interface, basically without any code, you can manage governance, you can manage a lot of things, it became a really agente platform, like co-pilot Studio for record and this kind of things. And nowadays, foundry is really difficult to place in the ecosystem because foundry is ever fast and basically Microsoft has introduced some features that are really, I don't know, not different, but there is similarities with co-pilot Studio in terms of MCP integration, these kind of things. But after co-pilot Studio limitation is about the models. So you have, okay, you have the capability to integrate or to crawl the mistrile kind of things. So if you want to integrate, for example, your own model, because you have a specific graph here, your model, you cannot do. And basically, you need to use a custom desk to integrate your own, for example, LLM platform if you have. I have some customers who have their own AWS platform. In this case, you can integrate as this model with a pricing manager externally. Okay. And I think when we build an agent, one topic, it's also all, most people talk is it's MCP, the model context protocol. Why does it become one of the biggest topics in a gently development and for someone who has not worked with it yet? What is a model context protocol? Yeah, it's a big world. And basically, a lot of people are talking about that because it solves a major problem. It's all to unify the integration of tools, skills, maybe, I don't know, external tooling to the AI. And it solves this problem because in the past, without MCP, it was like a mess because a lot of services are talking differently. You have different technology protocols. You have different architecture approaches. And basically, MCP unify or you integrate services to your, it could be AI agent or AI solution. If I'm more generic, but MCP now is really the way to integrate external tooling or internal tooling, it could be the boss. But MCP now is a big part of AI architecture because you have this unity in terms of technology. And nowadays, it's a big point because in the past, it was API integration and now it's MCP. This is not the evolution, but in the past, you integrate your agent with API, you need to manage, okay, auto-optic, auto-manage, auto-tickle tool. Now the AI can, okay, I have this tool available. I can select what I need to achieve the goal. What has really changed from MCP to API connection? Basically, in the past, in terms of integration, basically APIs are not intelligent. I can technically tell that. APIs are just, okay, you call the tool and it gives you data. So the difference with the MCP is more intelligent in terms of architecture because behind the scene you have not only tools, who give you data or information, but you have also skills in instruction and different kinds of things that make MCP really intelligent. And basically, MCP can give the AI, okay, you want to achieve that. I can give you the exact tools that match your request and you can call not only one tool, but you need to call these tools in order to achieve what you want. This is a world of MCP. It gives the AI, okay, I have these tools and after you can call this one or this one or multiple tools to achieve your goals. If your gift AI is a context, the real context of everything. And API is just, okay, you have tools, you have description and that's pretty old. So it's the model context protocol, I think, similar to Meta data or how does it work. And no MCP behind the scene, it's just each protocol, basically it's a technology protocol. And behind the scene, you have, yes, you have metadata, you have description, you have AI skills that describe more, it's really focused on AI. Basically, you have skills, you have instructions and basically AI can understand better. Okay, these tools, do that, these tools do that, okay, I can call these skills, I can request this information to the MCP server in order to achieve my task. But you have, yes, you have a part of metadata because you need to define, okay, the name of the tool, what is doing behind the scene. So can you say the future is MCP, so we have to start to think about, I don't know, a company is a fund of rest API is inside the organization, show they start building MCP servers around them. Yes, yes, basically, basically, MCP server, we work with API behind the scene. This is not a replacement, basically, if I summarize this, because the MCP server is just, okay, it gives the AI the context and behind the scene, the MCP can call APIs behind the scene, but MCP server is a front-end. The front-end, the front tool, you need to call because behind the scene, you will dispatch your request based on, okay, behind the scene, it could be API, it could be database, it could be multiple tools, but you need, if you want to have your own MCP server, for example, if you have internally in your company, you have APIs and you have a different kind of services, it could be, I don't know, financial service, it could be HR service. If you want to build your own MCP, you need to deal behind this field with all these APIs and the MCP server, we will need to expose all these APIs, what are the services, what are the tools available, what are the skills and these kind of things. After you need to deal with authentication behind the scene because APIs are not working the same because you can have authentication by key, by entry, these kind of things, so you need to deal with that. But the MCP will expose the tools available and behind the scene, all these tools can ask you to pull APIs, one API, it could be, you have different kind of architecture behind the scene. Okay. And how do the MCP choose the right tool when I have, I don't know, 100, 500, I have 8 things. It will be based on some things, basically when you have a request in an agent, you will discover all the tools available, MCP server, you will check, okay, I have all these tools available and basically the orchestrator of the agent will understand, okay, I have this, I have an LLM available, after you will create the plan, if I summarize a little bit, you will create the plan with some action to do. And after in this section, in the section you want to execute, you can call one, two, three or more tools in order to achieve the task, the user and the question. So basically the orchestrator of the agent will understand the MCP tools and select the best for the request, you see. And this is really the orchestrator role of selecting tools and this kind of, there is a help of the LLM of course, because the LLM is as part of the brain and orchestrator will communicate with LLM and also the tools in order to make the best choice and the best plan in order to achieve the task. Yeah, I think for a lot of companies have started with PowerShell and now they use Microsoft Grave API, did a Grave and MCP comes or how I store the, yeah, I think the, actually, actually Grave API, to be honest, no, no, there is no MCP for Grave, you know, you have now in the Microsoft 365 world, Microsoft has introduced a lot of MCP servers and those MCP servers are based behind the scene on Microsoft Grave. So for example, if you want to use, I don't know, the team, the MCP server, behind the scene, you have the Grave API being called when you use the MCP server. So Grave API in the Microsoft 365 world is central because behind the scene, the MCP will communicate with Grave behind the scene to make the request, to make the request working well. But yes, nowadays Grave is central also in corporate in general because the semantic index of corporate is based on raw data. But actually, you know, you consume graphs through MCP sounds. Nowadays, it's like that. Microsoft 365 contains incredible value, organizational contexts, documents, meetings, emails, people, teams, conversations and, I say, shaple content. How do we expose that context without a grating, is a security nightmare? You mean in terms of Grave and on these kind of things? Yeah. Yeah. It's always a problem because a lot of people are building agents without making a proper Grave and on the scene. So I want to build an agent. Okay, let's go. We build and we deploy. And after that, okay, this agent will deal with a lot of data. How do I do my own? The first question is, okay, how do I put in place the agent governments before it could be like you said, the mess because a lot of people want to, okay, I want to build agents, agents, agents, or I want to build something, I want to build AI solution. But behind the scene, one of the, I sure, in a Microsoft 365 context, for example, one of the first things to do is, okay, to understand your data because without understanding your data, you are lost. You need to understand your data because it's important to understand, okay, am I dealing with confidential data or not? Am I dealing with highly confidential data? Okay, you need to understand your data. After, if you are in a Microsoft 365 world, you need to put in place, for example, DLP features, a sensitivity level in these kind of things because without this, it could be a problem. And after you need also to clean a little bit your data because AI, with poor, data, your agent won't work like you won't because if you have a mess in your, I don't know, a sharp point style team, team champion, this kind of thing, if it's a mess, basically it will look difficult to work correctly in the agentic approach, but yes, you need to understand your data, you need to put in place some security basics like authentication, like I said, for you features and for you became a central solution to put in place all this security and governance stuff in place. And after, when you have clean your data, when you have put in place some security basics, you need also to understand licensing because before starting to build the agent, you need to understand, okay, what are the developers? Are they trained for that? Are they do we have the correct licensing to start getting? Do we need either some suggestions or things? After, one also of the big problem is the twig, how do I integrate properly all the tools in my development, my agents, do I need to restrict some things, so it's a bit of a silly question. You have different activities to take in consideration, but for me the most important is to understand your data and if the company don't understand the data, it will be your problem to be honest. And when we, how did we ask the security topic, I think there are two kinds of people, they need user permissions and the other one says they need application permissions. So, general, how do you general operate? Generally, and my best recommendation is always basically, when you need to deal with the agent solution, always do in user permissions, delegated permissions, because in terms of security is to be honest, is better because the user will deal only with data and tools it has access to. That's the main principle. After, if you need application permission for specific, I don't know, specific API, specific context, you can, but don't use directly application permission, make it in a context of a wrapper, so you create, I don't know, it could be, it could be an MCP server, for example, and you integrate this MCP with application permission behind the scene, so the MCP will call, for example, I don't know you at the site behind the scene with application permission, and after, he gives you the information or the information you need, but the user don't deal directly with application permission. He calls, with user permission, the MCP server, for example, and the MCP server will call behind the scene application or services with application, with a dedicated application permission. You see the difference? Okay, interesting. I think when we think about architecture, we also have, we look a little bit deeper, I think there are three big topics in architecture. We have the retrieval, augmented generation, we have the knowledge topic, and we have the, I say, vector enterprise search, where does RAC fit into the architecture? RAC, to be honest, RAC is actually the most, to be honest, in terms of performance, because AI need to understand different kind of data, and basically, basically the RAC is here to answer a question, because in the past, when you don't have RAC, basically, you need to deal with different approach, we're not all school, but it was complicated, but RAC is central, because RAC will understand different kind of data, and you will retrieve basically the information that I need, documents, it could be multiple types of data. So yes, RAC is central nowadays in AI architecture, but it's true that for a lot of users, when you are talking about RAC, behind the scenes, they don't know what is it, because Microsoft nowadays are a lot of different software companies don't talk about this, because behind the scene, you have RAC, but for example, in Copa Studio, the user don't understand behind the scene, it's RAC, you see, and nowadays, when you want to go deep dive, okay, you have this kind of concept, but for a lot of users, RAC is totally, they don't know what is it, because they just use tools, and very behind the scene, you have those concepts. And then we have the next topic, it's knowledge, how we get these, where did the AI systems get their knowledge, is it a collect jump-oid, or how this works? Actually, you have to well ask you, the knowledge is, it could be roasted, a lot of different systems, it could be plain text file, it could be marked on file, it could be a knowledge based, it could be an API, but actually, if you have an MCP server, you can access those knowledge, or if you have, for example, I don't know, you have connectors to shoppers, you have connectors to many services nowadays, so accessing the knowledge is more easy than before, to be honest, because in the past, you need to be your plugin, and to be everything, nowadays, you have direct connectors to many systems, you can integrate your knowledge without dealing with big development stuff to be honest. I think, I think often we have, I don't know, I connect to my, I say to my, I don't know, one drive. And how do AI understand what, what are not already documents, or outdated, or I don't know, duplicated, how can, how understand this, an AI system, what it should use, but not it. Basically, you are using Ragn, because behind the scene, you need to understand, okay, what is your data, but to be honest, if I summarize a little bit, you start from the prompt, okay, the user wants to, okay, he wants to, for example, to search for us, I don't know, knowledge base, for example, one drive, behind the scene, when, when the, what the orchestrator with the help of LLM understands the prompt and the, the user intents, behind the scene, you have the index, basically, because for example, in Copilot, you have the semantic index, and this semantic index give you, basically, okay, I have all this knowledge, and you can, with the semantic index query, the AI can query directly, the semantic index to perform, to perform a Ragn, for example, and you can directly, okay, select the right documents based on the needs, but in Copilot, you have the semantic index, and the AI can query directly, this index, with natural language behind the scene, so, yeah, we will ask, okay, I want to understand, I don't know, how, how to set up my company VPN, and behind the scene, you will perform Ragn on the semantic index, and basically retrieve the documents that contain, for example, all the setup of the company VPN, for example. In Microsoft, to see if that Copilot chat, behind the scene, it's graph API, because as I said before, you have the semantic index built on graph API, it's graph feature behind the scene, but when you have custom development, you have, for example, a FoundryAQ behind the scene, it was an Azure services, with a different name, but now you can have your own RAC system, if you want, and basically, you can, when you have a custom agent, you can directly ask this FoundryAQ instance, okay, I want to use, I want to get the setup of my VPN company, and the AI can retrieve what in-in terms of documents, I could be here, so this kind of fix. And that's how the search works, right? Or behind the scene, you mean? Yeah. Ah, behind the scene, yes, you have the search, but basically, nowadays, you have behind the scene, behind the scene of Copilot chat, you have three capabilities, you have the standard search, which is basically a search, that's okay, you simply put some keywords, and you will search across your documents, and this kind of thing, this is a simple search, or we all know, a keyword search, like Google, after you have two different capabilities, you have first the RAC behind the scene, you have the capability of RAC in graph, and you have also the Copilot semantic index search, which is a little bit different, because RAC is really more advanced than the Copilot semantic in that search, but you have all these three capabilities behind the scene in order to make your, it's not true, but behind the scene, I can call these three different capabilities to retrieve the data across one drive teams, M365 in general. After, you can, the semantic index of Copilot include also the Copilot connectors. So, for example, if you have connected Salesforce with a Copilot connector, you can also search across all your data in Salesforce in service now in multiple tools, because it's everything with the Copilot connector, you have integrated all the data in the graph index, semantic index, so you can query directly your external systems. Okay, and I think when we build agents, we have the governance part, and one of the part is also for me, I say, the agent lifecycle management. How does this look actually? It looks actually, it's to be honest, in the Microsoft ecosystem, it's pretty simple, if I can say that, because when you are dealing with Lockout, for example, Copilot Studio, you are dealing with poor platform content, I-L-M, and nothing as change, so you have solution, you have A-L-M in place, you have pipeline, so when you are dealing with Copilot Studio, to be honest, it's like before, because you have all the stuff you invested to in terms of corporate from governance, lifecycle, A-L-M, it's strictly the same. This is a good thing, because a lot of people are asking me, "Oh, Copilot Studio, all do manage, A-L-M, is it different?" No, it's really simple, like, perhaps, or co-automate, application lifecycle management, so in this case, it's agent lifecycle management, but behind the scene, same concept, like, corporate form, and when you are dealing with, for example, Custom Dev, basically, it's like when you are building applications, but not applications kind of stuff, because you manage everything like code, so you have frameworks, you have security aspects, this kind of thing, so everything to be honest, in terms of agent lifecycle management, it's really the same concept than before, and this is a good point for me, because you don't have to invest a lot in terms of lifecycle process, this kind of things, but only you have some change, but one of the big changes, "Okay, you need to take care of that, A-L-M, this kind of stuff, the deployment, this kind of things," but behind the scene, it looks like, in the past, DevOps approach with pipeline, this kind of thing, so... In my opinion, nothing has changed because we manage agents, it could be Custom Dev, or capacity, with the same approach than before, to be honest, nowadays. And this means, when a company, they don't use before AI, but they have the perfect setup for PerView, for Defender, and all the tools. Is there any change that it would do, or is it this means AI readiness? Ah, it's a big question, because AI readiness for Microsoft is okay, are you a sharpening commission, manage, this kind of things, but... okay, AI readiness for me is not only a technical approach, because, okay, technical, we know what to do, okay, we need to manage a commission, a process, not a service, you know, for me, AI readiness must include also the data, the data, understand you, because when you don't understand your data, as I said before, you cannot manage the technical part, because when you don't know what is confidential or not, for example, it's difficult to put in place some security stuff, but if we follow Microsoft, AI readiness is okay, you want to manage commission, you want to put sensitivity, the level in place, you want to make GLP, this kind of thing. But you have also a more high level aspect, and for me, AI readiness is not only technical, you have also a functional or high level aspect to take your incarceration to be honest, nowadays. Hmm. Yeah, that's really interesting. I think a lot of companies, as well start at the AI, but now it was agents, a lot of companies say, "Oh, it's deleted all my, I don't know, emails or doing something evil stuff." How did you think? What will the company say? They fear AI? It's a good question, because I'm living in Switzerland, and basically we have a lot of private banks, and we have a lot of, to be honest, really sensitive customers for, yeah, to be honest. And basically, the most critical part is, okay, where the data is processed from, basically. And yes, also, okay, is AI searching across my emails, this kind of thing, so behind the scene, they always ask this, but the most critical part for them is, "Okay, I need to understand where the data is processed, and also, okay, I am the owner of the AI." So, I put the instruction to the AI, and the AI behind the scene will do the job. And they are afraid of, for example, the autonomous aspect, because nowadays, okay, you can do that, and behind the scene, they will search for something, query something behind the scene, and they are afraid of, "Okay, when I ask the AI to do something, what is behind the scene, apart from?" And yes, there is a lot of questions like this, "Oh, do I take the control of the food process behind the scene of, it could be an AI agent of an AI service?" Yes, there is some questions like this, but it's really a question of adoption, also, training to put in place some training, but, "Okay, all to understand AI, all to understand behind the scene, what is performed exactly, and transparency is also a bit important, because transparency needs to be put in place in every AI solution, because transparency is for me a big topic, because you need to put in place all everything, because your AI solution needs to be transparent. You need to understand what is performed behind the scene, what data is query, you need to trace, you need to log everything, so everything needs to be transparent, when you have a solution nowadays, because you need to understand exactly what is performed behind, and what data is processed, and what is the reasoning behind the scene. "Okay, how do you have generated this problem based on which facts and these kind of things?" Awesome. I see, we run a little bit out of time, so... Yeah, so... No, this was really amazing, but I have an every podcast, I have a rapid fire rounds, so... Yeah. So, I give a short sentence that you give a short answer, so are you ready? Yes. "Copilot Studio" or "Custom Code"? "Copilot Studio". "Microsoft Fowlery" or "Copilot Studio"? "Copilot Studio". "Typescript" or "C#". "Typescript". "Whip-A-Woe-Age-O-Deff-Ops". "Git-A-M". "Rack-O-Fine-Tuning". What's the most under-rapeable Microsoft 365 API? "Rack-O-F-E-I". One technology every Microsoft developer should learn in 2006. "Git-A-P-Copilot". Then, Sajan Idalya comes to you and says, "Give us, you get all the money and resources you want to make our AI platform better. You can develop one feature. What will it be?" All the governance stuff we need. And... Who shall I invite next to the podcast and what questions shall I ask? Oh, good question. I have a lot of friends. Yes, maybe you can ask to... I have a course speaker in many confronts. You can ask for example, Chloe Morro. She was a functional consultant before dealing with the technical side now. And she has a really good story about functional, technical stuff. And the Dynamics 365 world, so maybe you can invite her and ask, "Okay, tell me nowadays how to deal between functional and technical world because you have some big challenges there." Yeah, and my closing question is, what should people, when they can take one running from this session, what should they take? From this session, you mean? Basically, AI is evolving fast. And if you want to be up to date nowadays, you need to follow everything because nowadays, AI is really across all the Microsoft touch to the nest. And nowadays, one of the things you need to understand is the evolution class. And you need to be up to date really, really at any time because you will miss something at some point. You don't learn. You don't understand the evolutionary challenges. Yeah, so, yeah. But thank you for joining me. I think the important takeaway from this conversation is that Microsoft 365, co-pilot extensibility, isn't simply about writing, increasingly means of decayed prompts. I think we are moving towards architecture where co-pilot and agents can connect, organization, knowledge, Microsoft Graph, business application APIs, and so on. Yeah, I think co-pilot studio Microsoft finally custom developed and technically such as MCP, give developers an amazing, powerful toolbox. And yeah, but more capable agents become the more important from the mental spectrum as well, identity, permission, security, governance, testing, observability, application lifecycle management, and so on. So yeah, I think you have really, really good overview of all these topics. So thank you for joining me and for the listeners, all the information about if you find in the show notes on the MC65FM podcast patch. And yeah, well, you can connect, see the work of it. And yeah, thank you for being here. Thanks for having me. It was a really good time with you. [BLANK_AUDIO]