Insights View Recording: Low Code, High Impact – Empowering Teams with Copilot Studio

View Recording: Low Code, High Impact – Empowering Teams with Copilot Studio

How Copilot Studio’s Multi-Agent Design Transforms Enterprise AI

AI isn’t just for developers—business teams can innovate too. This session shows how low-code AI agents in Copilot Studio enable employees across functions to build impactful solutions without writing a single line of code.

Discover practical strategies to unlock AI for everyone in your organization, improve collaboration, and create measurable business impact—no coding required.



Discover how Copilot Studio empowers teams to build scalable, modular AI systems using multi-agent design. In this webinar, Corey Milliman from Concurrency explores parent-child agent hierarchies, peer collaboration, and MCP server integration. Learn how organizations in Milwaukee, Chicago, and Minneapolis are leveraging these tools to streamline operations and unify AI governance across departments.

WHAT YOU’LL LEARN

In this webinar, you’ll learn:

  • How to structure parent-child and peer agents in Copilot Studio
  • Key benefits of modular AI systems for scalability and maintenance
  • Technical setup for agent orchestration and environment management
  • How to integrate MCP servers for external system connectivity
  • Real-world demos of HR and IT agent orchestration
  • Best practices for agent descriptions, triggers, and fallback strategies

FREQUENTLY ASKED QUESTIONS

What are the differences between parent-child and peer agents?

Parent-child agents operate within a hierarchy, with child agents hidden from users and triggered by events. Peer agents are independently managed and visible, enabling cross-domain collaboration.

How does Copilot Studio handle agent orchestration?

Copilot Studio uses generative orchestration to dynamically select and coordinate agents based on their domain expertise and descriptions, ensuring seamless user experiences.

What is an MCP server and why is it useful?

An MCP server acts as a universal translator between Copilot Studio and external systems, simplifying integration through standardized JSON RPC 2.0 protocols.

Can agents be reused across departments?

Yes, peer agents are independently managed and can be shared across departments, allowing for scalable and modular AI deployment.

How do I connect external systems to Copilot Studio?

You can use MCP servers or Power Platform connectors to integrate APIs and third-party services, enabling real-time data access and business logic execution.

ABOUT THE SPEAKER

Corey Milliman, Technical Architect at Concurrency, specializes in Copilot Studio and enterprise AI orchestration. With deep expertise in Microsoft platforms, Corey helps organizations design scalable, secure, and modular AI systems tailored to their business needs.

TRANSCRIPT

Transcription Collapsed

Low Code, High Impact Empowering Teams with Copilot Studio November 20, 2025, 5:00PM 46m 23s Corey Milliman 0:10 Pilot Studio talking about multi agent systems and MCP servers. Today I will not be on camera. I have some of the crud that’s going around, so I thought I’d spare all of you. So if I drop on mute for a moment during the presentation, that is why and we’re going to go ahead and get started. So if you have any questions throughout today’s presentation, make. Make sure you drop them in chat. Amy will be helping me monitor that today as we go through. So let’s go ahead and get started today. Like I said, we’re going to focus on Copilot Studio and we’re going to focus on the multi agent design. So this is really important because you know now they’re out of preview. So we’re going to talk about parent agents, parent and child agents. We’re going to talk about the agent to agent model, how those work. We’ll compare the child and connected agents and what those different use cases look like. And then I also want to include some extra information since these parent and child agents are more mature now, and also talk about bringing in an MCP server and what that actually looks like and what that does so. And most of today will be demo. We are going to go through PowerPoint first. This deck will be made available to everybody after the presentation today. So multi agent capabilities. So we really are driving these with three capabilities for multi agent design. So we have collaborative copilot. Design so agents can now collaborate rather than operating in silos. Parent child agents. So a parent child agent hierarchy allows a parent agent to delegate task to its children, so it creates A structured workflow that keeps our conversations coherent. And it also allows us to do a lot of cool things so we don’t have to work so hard on topics. We can actually use sub-agents to handle different domain expertise and that really allows us to increase the velocity to deploying these agents. And third, we have peer collaboration, so connect agents. Connected agents, rather, can work together as equals. They can orchestrate across domains, provide seamless user experiences, and taking all of this together, we form a modular team of specialists. Specialists, excuse me, that are each focused on their own role, but they are all coordinating as part of the bigger picture. And there are some benefits like I started to mention. So we’re simplifying complexity. So by splitting these responsibilities into multiple agents, we keep our logic simpler and this allows us to have also agents as opposed to refining topics. We get specialization of roles, so this way we can have each agent focus on a specific domain and that improves accuracy, tone and depth in that area. Maintainability. It’s a lot easier to update a sub-agent without impacting other agents across the enterprise that doesn’t. And impact other agents. So that reduces our maintenance complexity and cost. And then finally scalability. So scalability comes naturally. So you can add a new copilot agent to extend capabilities just like you add a new team member. So the end result is we have this coordinated system that grows modularly and works more like a team. People than individual agents. All right, so so to connect agents in Copilot Studio, there are a few requirements. So first, the agents that you want to use must be connected to the same environment. It must be published. So this is ensuring stability and consistency. Now when I talk environments, that means they have to be in the same power platform. So I can’t connect to another agent that’s outside of that platform environment. So just so you’re aware of that. Secondly, each agent has an allow connections control toggle. So you have to make sure that if you want other agents to be able to connect to it, you actually turn that on. And 3rd, you also have the option to toggle conversation history. So what this does is if I’m talking to one agent. Copilot understands that I need to be transferred to a new agent. Am I bringing over the conversation history and that previous context or am I basically starting a new? There are times where it is beneficial to pass history because it gets the prior context and sometimes it’s easier to start. With a fresh, clean slate for an isolated task. And finally, management is more flexible. You can enable, disable, or disconnect agents now without deleting them. So that means that you can have different testing and staged rollouts without impacting your production. Oh, I was just looking at chats, so it looks like everybody can hear now. So sorry about that. I didn’t notice and it looks like everything is is working now for everybody. So the design and functionality of child agents. So again, child agents, this is a hierarchy. So these are built inside of a parent and they operate inside that parent. So this ensures that user experiences. Are more coherent and especially when the parent agent remains in control. So child agents are invisible to our users. They work behind the scenes and they simplify the experience. They can also be event triggered, for example, maybe after inactivity. Invocation or workflow completion priorities can be assigned as well to different child agents to determine which child agent responds if multiple agents can handle the same event or task. So this makes child agents powerful for narrow specialized functions where you. We want hidden helpers doing work on behalf of the parent. So peer collaboration, orchestration. So connected agents work a little bit differently. So these are, you know, I publish an agent and then I publish a separate agent. So these are independent co-pilots that can be reused. And each is managing its own lifecycle and governance, which means different departments can own their Co pilots but still share the area, share them across the enterprise. Generative orchestration allows a parent to call one or more connected agents at runtime. Merging those results into a seamless user answer. So the key is to give each connected agent a distinct domain, and we’re going to be going over this in a demo today. I’m going to be demoing, I think, HR and IT, so through one unified interface. Excuse me. So orchestration can select the right agent without confusion, and that’s peer collaboration. So you can also look at this as ways to connect multiple agents throughout the organization so we can have a unified agent experience on the front end. That might connect up to other agents that have been deployed in the organization, and we can also use Copilot Studio to connect to agents that are standing in other systems. So we can also look at Copilot Studio as a way to unify the governance and security and. Entry point for handling our AI agents across the enterprise. So key differences in use cases between our parent child and our peers. Child agents depend on the parent, while connected agents operate as independent peers. So child agents, again, they’re hidden from users where connected agents become visible in conversations depending on our setup. Child agents are lightweight. They’re managed within the parent. Connected agents are independently managed and scalable across solutions. And finally, child agents use triggers and priorities, while connected agents can be orchestrated dynamically at one time. The choice really depends on your needs, so if you really need tightly controlled delegation, use child agents. Again, a really good use case for child agents is taking up. Say we’re working with an HR agent and we have 10 different maybe repositories of information. We have one that is our benefits information. We have another area that is policies and procedures. And we is the sub-agents and I have a benefit specialist. I can create a policies and procedure specialist under the HR umbrella and provide that unified user experience instead of having a flat agent and then having to define complex topics for each one of these things I want to cover. Finally, child agents again use trigger some priorities and so they’re both really flexible. It just really depends on your use case and how we want these to connect. So we’re going to go ahead and we are going to have a demo. On this and I’m going to stop the PowerPoint. I’m going to try to stop the PowerPoint. There we go. So now I’m going to go into Copilot Studio. So what I’ve done is I’ve created an agent policy central and right now this agent is connected to a couple of different tools. I’m going to go ahead and close my test pane here. We’re waiting for the instructions to load up and we’re actually going to expand on this during the demo and create different agents and sub agents here. I’ve also already created an IT agent and I have a separate HR agent. So this is my central policy agent. From here I configure my individual just like I normally would. I have my intro, I have my topics, but now we’re going to go through and I’m going to show you these agents. You can see here is a subagent and here previously I connected my IT agent, my HR agent and this is 1 where I create a subagent. And we’ll create a second sub agent on this demo as well. But for our HR agent here, the sub agent, the agent’s going to choose. I put in a description. It’s going to show us this is about policies and procedures. This agent answers all of our HR questions. We can build out different using different variables. We can define what our priority is. We can capture it, capture different system environment information and bring that in to create the conditions where it understands how it’s going to run as well. And these instructions here, we’re actually able to make these much more robust and I’m going to go ahead and drop in. We’ll drop in people to work on the IT one mostly and then just like our parent agent, we added our knowledge and then we have our tools here. So this is a sub agent that is inside of Veridian Policy Central. So you can see here I’m going to expand our test pane so we can see what happens. I’m gonna say what are our PTO policies? Oh, here we go. So you can see I have a couple of different things that I didn’t. We are going to be looking at MCP server today as well. So it just hit that quickly to make sure that it understood the tools that were available to it. But now it’s going through and it’s summarized our you can see here it went to the HR sub agent. And it summarized the time off policy and it brought this up here. So from a user perspective, I only see the parent agent. I’m working with Viridian Policy Central and my HR self agent is going ahead and querying the information and doing different things there. So if we go back to our agents now to show you the difference in the user experience, we’re going to turn off the HR self agent. That just takes a moment here and I believe I have everything published here, so we’re going to see if Veridian is still published. Thank goodness. Go ahead and click start a new session. So here now we’re going to open up our test panes so you can see the conversation flow and how this changes. So you can see here I’ve been transferred over to a separate agent and now this is actually it decide what the task is to provide a summary PTO policies including key points, accrual rate, eligibility guidelines, any policies, procedures. And. And here we have a little bit of a different response. So here it’s telling me what the policy is. It went and it found it, but it gave me a summary of the policy. So my instructions on this agent are very vague right now, so you can just see that it used the same knowledge. It provided a summary and. It acted a little bit differently. So here we’re going to go ahead and we’re going to walk through how we create these child agents. So go through and choose add an agent and you can see here that new child if you want to add. A peer agent, which is what this HR and IT agents are, it will show you all of the available agents that allow that. These are all published and these are the agents that are published and allow those connections. So we’re going to do a new child agent. Now while we’re waiting for that, I’m just going to review the question, make sure I have the question window up. Does take a little while for those agents to pop through, but what we’re going to do, it does tell you right away that this requires the a description. So this is our short description that the generative A I is going to use in orchestration to understand how to use this tool. So I went ahead and provided my description and now I have a document put together in another window that holds all of my instructions and this is something that has changed as well. So what we can also do. Is we can actually invoke certain topics that might exist. We can invoke different. I don’t have any custom topics here, but if we needed to, I can use the slash command to pull in different tools and different topics into my sub-agent to tell it how exactly to use that. And that’s important because we’re going to go back to our parent agent and we’re going to tell it how to give it some more instructions on how to use our child agents as well. So now for our IT agent, I’m going to go ahead and add my content and here I’ve already. So you don’t have to watch me type. We have our IT documents that I’m going to bring over. So. And we’re going to give this a description as well. Whenever you add a SharePoint site, it’s very important or a knowledge source. You have up to you have over 1000 characters in your description fields to tell Copilot Studio. How do I use this knowledge source? So by default it’s always going to say this information, this SharePoint site contains information about and it’s going to pull this name. So that’s not really useful when we’re working with Copilot. So best practice is to make sure that we are providing an additional description of what our knowledge source is. So that our agents can be smart enough to understand how to use the knowledge we’re giving. If you have very large knowledge sources, it’s a good idea maybe to break that up into smaller pieces so Copilot doesn’t have to go and traverse a giant SharePoint site that just has viewpoint. All of your policies at one place and then copilot might struggle to traverse that giant knowledge source because it has very limited context. It just says these are all of our policies and procedures. Well, there are times again different policies and procedures we need to provide additional context so the agent knows how to use. The information we’re giving it. So again, if you have a giant SharePoint site that’s out there, try to break up different document libraries. You can go down to folders if you need to. You can actually go down to document level if you have certain documents that are out there, say. An employee benefits guide for open enrollment or policy manual, employee handbook, things like that. So I’m going to be general because my SharePoint site is not large. IT policies, procedures and best practice. Go ahead and add this to my agent. All right, so now you can see this has been added over. If I wanted to add additional tools, I can add these here as well. And then we do have some abilities to define how the sub agent responds or doesn’t respond. So by default it’s not going to respond, it’s going to pass the response over to my parent agent. These sub agents can also be used for automated tasks. So maybe I want a sub agent that every time a certain thing happens I want to go upload a document to a SharePoint site or send an e-mail or do a thing. So those are ways we can add external tools through the Power Platform and Copilot Studio based on. Different parameters that we define, automate and create some autonomy with these as well. So all of these sub agents are not just limited to conversation, we can actually do different things as well to indicate how we want to use these. So we’ll go ahead and save that. And now we’re going to go back to our top level agents so we can see what this looks like now because it did, it will have made a change. We’re going to look at that here. You can see that the top level agent still knows about IT documents and HR documents. So even though we added our knowledge and associated it with the child agent, it still understands and adds that here as well. So if I add knowledge at this top level, it’s only available. If I add additional knowledge, it’s only available to Viridian Policy Central. So if I need to add more information relevant to one of my child agents. I need to go into that child agent and give it that knowledge there so that Copilot Studio understands this knowledge source is for this sub agent or child agent. So we want to add it here. Even though our knowledge is showing up at the top level, we want to make sure we’re adding knowledge per child agent. At the agent level itself and I just noticed I did not give this a name. Anybody have any questions so far while I’m waiting for the safe? All right, so now we’re going to go ahead and we’re going to start a new test session. The agent has saved. And. And again, it’s hitting all of our different knowledge sources. This MCP server is connected at the top level to Veridian Policy Central. It understood it has to go to my IT agent. It still generally traversed those two knowledge sources attached to the parent, but still understood. It needed to go down to the next level and here are our password policies. So this is a really good way of taking multiple types of information. We can put these all in one spot if we want to. I could do this again as a departmental level. If I want to create an IT agent that maybe allows users to open up service desk tickets, there are different ways that I can use these sub agents to target certain types of knowledge. So maybe I want to go out and bring the user over to Microsoft Learn. So I can try to help the user maybe self-correct or self-identify the issues that are going on. I can connect to my ServiceNow KB articles and traverse those really easy and use my internal knowledge sources and another sub-agent. And so we have that ability again bolt on all of these different capabilities where we’re providing. Very targeted instructions on how to use these different types of knowledge. One other thing we’re going to go back over to a sub agent here. Go to our IT agent. You can see here that our sub agents do not have topics. So we don’t create topics with sub agents though. So our sub agents are going to be limited to knowledge triggers. We can actually add inputs where we are going to if we’re passing information over to another tool, let’s use ServiceNow as an example and create a connector for. ServiceNow I can map over based on my ticket type. I know for an IT request I need a subject, I need four different fields. I know what those internal field names are in the ServiceNow schema, so I’m going to use AI to tell. Copilot Studio How do I know how to fill in? What is the? This is the variable that I need to fill in to pass to my external system. Now we use AI here and a prompt to tell it how to understand from conversation what that variable is. So it’s going to use the AI to. Powers the conversation, understand intent and allow it to understand the variable that it needs for. Maybe it’s an IT help request versus a password lockout. Password request is a bad one because they shouldn’t be in here if the passwords are locked out. But it can actually. Prompt the user for certain types of input and do some entity validation without having to do this at the top level. So it does give us that limited. We have the ability now to automate certain things, kick off different Power Automate flows, kick off different Power Automate actions from the Salve agent child agent. As well. Now from an agent to agent perspective, when we do this, I’m going to go back in to we’re back to this one. You can see here orchestration. We do need this to be enabled to allow how to best respond to users in events, so that does need to be enabled and then in our settings. Connected agents is under generative A I our first setting spot. We have to make sure this is enabled so that other agents can connect to it. So we want that to happen. Just this is where you go to make sure that these agents can see each other and talk to each other. Now the other part, I’m going to go back to our PowerPoint for a little bit and then we’re going to jump back over into the demo. So just. Just a moment here. This always does this for me and I’m going to minimize my window a little bit on the other screen so I can see if anybody has any questions or comments so far as we continue to go through. So again. Will be go to the next. Just a moment. All right, so again, guidelines now for an effective multi-agent implementation. Make sure you define clear roles, very clear roles. Each agent needs a job. We don’t want our agents to overlap. We want to make sure that we reduce the orchestration confusion. Second, write really strong descriptions. You saw that that child agent description was not long. So when we’re using child agents, if we have something more complex, those have to go into the instructions inside that. But our descriptions allow orchestration is going to rely on these descriptions to pick the right agent. And you can, you know, have too many child agents. If you have too many child agents that are too similar, it can create conflicts and it can actually take some time to generate a response depending on how these are all connected. So forth, always plan for a rollback if no agent can handle a query. We have to make sure the parent agent has some kind of topic and safe response ready. Our general fallback and escalation prompts that we use to make sure that our users don’t end up in a dead end somewhere. So this way we have good end user experience, things are reliable. You know, so this is no longer. I forgot to update this slide. This is no longer in preview status, but some other things just to understand. Redirect notes do not directly hand off to child agents. Child agents might lose some citations or responding to the parent. So we have to be sometimes a little bit more direct with some of our prompting to make sure that explicit inclusion is not child agents might invoke model knowledge even if disabled and parents. So that’s something that I’ve seen sporadically. So we have to be sure that we are watching. For that and have the appropriate safeguards in place and agents cannot be connected in multiple places, so you can’t have an agent connected up to 20 different agents. So agent to agent communication, we can’t have an HR agent at the parent level. Connect to the five other agents in the organization so they can’t all keep connecting to each other, to each other, to each other. That would make for everything would be way too complex. So again, child agents for narrow hidden tasks, keeping the parent agents simple and focused. Parent agent can be the coordinator, the orchestrator for our child agents, connected agents for collaboration. Connected agents can serve as entry points. And one example here is you know a lot of organizations that I’ve worked with do not have just copilot studio agents. We have these agents and. Other systems that are connected up and we can very easily have a simplified unified enter point with Copilot Studio and we understand when to transfer people over to the agent that is best suited to do the job. So that’s a really good way of creating a unified user experience, creating different tools and. So the users don’t get confused. I have 75 agents in the organization or 1000 agents. Where am I going to go as a user to find each of these agents? So that helps stack multiple agents behind a single entry point for a better user experience. Combining models for scalability, combining child and connected agents creates more modular flexible systems, and then these are more future-proof and adaptable. This makes it easier to maintain, adapt and expand the business. Again, another department went out, founded different AI technology. They have an agent. Bring that into our Copilot Studio infrastructure and we can at least provide a unified governance, security, UI, UX and end user experience. So any questions so far? I don’t see any, so I guess that’s good. Now we’re going to start talking a little bit about MCP, so Model Context Protocol. So I wanted to talk about this and show this today because it’s a really good way to get some. Complex systems connected up to Copilot Studio and providing some functionality without again having to create very complex topics. So you can spend a lot of time creating topics in Copilot Studio asking questions. Collecting variables, sending responses, and there are times where that’s really, really necessary. But at the same time, MCP servers, child agents, connected agents, understanding intent allows us to bolt on these technologies and increase the velocity to deployment. So the MCP Model Context Protocol really allows AI assistance to connect to these external systems in a really different way. What we’re basically doing is wrapping AI around different API calls and providing a universal communication standard. So at its core, it eliminates this traditional challenge of building out custom integrations for every single AI to service connection. So we have a lot of powerful connectors inside of Copilot Studio. We have a lot with Power Platform, but sometimes with Power Platform those can get very complex when you’re transferring. You’re translating variables, moving things across systems, and there is also a move over here to this model context protocol. So we’re using a standardized Jason RPC 2 message. This MCP protocol is going to act as a universal translator. Gene Copilot’s natural language interface and any MCP compliant server. So what happens then is the MCP server then manages the actual business logic, maintaining our registries of tools, our our resources, authentication, data transformation, things like that. So and finally, this allows the server to connect to our existing external system bases, APIs, third party services without making changes to those systems. So the architecture is really, really powerful and it ensures that Copilot Studio developers can focus on building the conversational experiences. Rather than having to build middleware and integrations and integration code and still maintain enterprise-grade security and performance, there’s a bidirectional arrows that are going to come up on the next tier that really though we have real-time request capability and response for communication, so Copilot’s going to get access to live data. This diagram here we have Copilot Studio with our custom connectors and business logic invoking the JSON RPC 2O protocol. This is transport agnostic and a standardized API. It actually goes out and queries the MCP server to understand what tools are available, what resources. That are available and it can actually use that to execute business logic and then that MCP server handles the connection to the external system. So again, if I have an API where I have maybe 100 different calls, I don’t publish that as 100 different tools. But I break down my tools registry in order to understand those API calls and provide context to the AI on each of these. So we have a for the MCP protocol that’s actually doing this. We have a four layer architecture that kind of separates concerns and ensures flexibility. So we have an application layer that contains our business logic, so that tool performs actions, maybe resources that provide data and prompts that guide in actions. So this is where developers define what their servers can actually do. And this is where we bring real complex math into the LLM, right? So a lot of times if you upload documents or have knowledge that’s out there and you ask Copilot Studio or Copilot for Office 365 question, expect it to perform complex computations. Sometimes it can’t. So this is a way where we are taking very complex business logic that has to be repeatable, it has to be accurate and it has to be somewhat systemic and we’re giving it that tool. We’re giving the AI context to understand this is how you run the tool. These are the 30 variables that we will accept and. How we need these variables rather to be formatted and so this four layer architecture allows that to happen because the copilot is going to go out, establish that session to manage the connection, sending over the handshakes, maintaining its health. And then shutting that connection down, that message layer is going to be that comms protocol that’s giving the standardized format for all requests and responses between the LLM or Compile Studio and that MCP server. So this ensures that every message is properly formatted and trackable. And then of course at the base layer, this is HTTPS. Want to make sure that we are using transport layer security and web sockets for real time streaming. So this approach means that we can develop locally and deploy the exact same code production using HTTPS without changing our application logic. And each of these layers only communicate with adjacent layers. So the application layer will never jump and communicate with the message layer and vice versa. So here’s a diagram of what the handshake and then we’re going to go over though just this last part, the MCP 4 components are why they are. Why they are important? So again, the request handler routes requests. The resource manager manages our data access and enforces authorization. Our tool registry that is a queryable list of tools with metadata descriptions and things the AI can understand that tells it how to use. Is each tool on that MCP server. Then we have a security layer of course to handle authentication and then the response builder is going to make sure that we have protocol compliant responses for better parsing. So these actually do integrate directly now into Copilot Studio. So Copilot Studio can invoke these MCP servers through topics, sections, flows. You can do this as well through a custom connector. That’s really what’s going on behind the scenes. And then that MCP server can connect to different APIs or databases. I did not mean to stop sharing. I meant to stop the slide deck and now we’re going to go back into studio and we’re going to, OK, we’re going to switch monitors and we’re going to go over here and we’re going to take a look at. Adding an MCP server and what that looks like. So I’ve already added the MCP server. I’m going to bring up a screen where you can add one and I want to show you that the MCP is going to show up in two different places and what that looks like. So generally when you want to add an MCP server, you are going to open up the agent and go over to tools and add that. If you come over here to list out tools in the organization, I’m going to show you what happens. This does trip people up sometimes, so this is going to go ahead. It’s going to give me a list of tools that are available and I’m going to start creating a new one here and if I click new tool. And directly go to Model Context Protocol. If I started there, it’s going to bring me over to what’s MCP. So you can’t establish an MCP connection by clicking your tool in your generalized tools and just clicking MCP. You need to be inside of an agent, just so you’re aware. So if you’re inside of an agent. And we go to our tools. As this takes time to. And then we add a tool here. From here then I can go through and get over to MCP servers Model Context Protocol and there are some off the shelf quote. There is a gallery, a library of MCP servers that are available. Some are already deprecated and these are from third party publishers that have been validated with Microsoft. And you can see I have a couple MCP servers that I’ve previously added down here. So to add, maybe you need to add one that’s a new one that’s not on this list. Couple of things with MCP servers is you want to make sure that you’re not just randomly connecting to an MCP that you found on the Internet that’s publicly available. Without making sure that your data is actually going to be protected. So a lot of times what I see with customers is maybe they find an MCP function they really like. It’s available on GitHub as well and they go ahead, they download that GitHub code, bring that into their own organization, make sure it goes through the. Security checks, spin it up in a container with Azure Container services and bring that code in house so that they control the code. Definitely then that way they also control the security and they can make sure they know exactly what information is going in, where it’s going and how it’s being used. So to establish a new MCP server connection, this is the screen that you go to from inside the tool itself. You provide the name, a description, the URL and and then the authentication method. So I’ve already set this up, so I’m not going to go ahead and do that because this is a right now it’s a publicly facing URL on a dev box that is locked behind a firewall, so I’m not going to give everybody that URL on this demo. But right now we can see here that I added a weather P that is actually code that I’ve locally deployed and I have running behind a web server. So there are a lot of weather MCP out there that do different things. I found one I kind of liked. I needed to see about getting historical information a lot of the although so all the way back to 1940 different types of weather data. And So what this did by adding this MCP server that I put together. I have different tools that are available and these tools the user will never type get under score forecast. These tools are meant so that there’s a name for a tool the AI is going to use. There’s a description of how that tool is used. And there’s more information on these here and. I forgot to delete that, but there’s one called Get Taco Recipes that was for testing to make sure it was doing the static responses right for Copilot Studio. And then down here I will have resources that will eventually show up that give the MCP server their additional resources on how to use each one of these tools, what variables are required, how to format different things. So that we can bring this in to a conversation. So if I were to and I bolted this on to our general policy AI here and I can just say what were the soil conditions in Boise, ID? January 1st, 2020 through June 2020. And you’ll also notice as you can see here, it actually brought up the MCP server. It’s actually launching a tool called Get Soil Conditions. It’s translating my conversation and I could have just used more generalized. I didn’t have to get that detailed with my. Chat, but understood it was for Boise. Here’s the start date, here’s the end date, here’s the actual information that came back. And with GBT 4/1, this is how this presents. You will see if you change your model. That you will get some different levels of responses. Right now we’re on 4/15. O chat does work really well and I’m going to see this one’s available in my environment. And you will see that if you do connect to external systems, you’re defaulting to an older model. So that’s one other thing to point out is our default is 4/1. A lot of our users have been using ChatGPT and are used to ChatGPT 5 or 5/1. So we generally do want to make sure that we’re switching our models to provide a better experience. So I’m going to ask the exact same question, going to start a new conversation. There we go. And we’re going to go ahead and let that go. You can see here again, it’s in doking. And now you can see I have a much better response. It actually formatted nicer. It actually gave me kind of a table, and it does a really good job at actually pulling in large sets of data as well. So in your organization, if you have, there’s one additional thing that can make your chat. That’s much better now and I’m gonna go to my settings. It is actually disabled in this tenant that I’m in right now. But if you check code interpreter, if you turn on code interpreter, that’s in preview mode right now. But then it can go out and do things like generating very complex charts for me. It’s going to generate the Python code needed to do complex data analysis on the fly, and it’s going to do things like it’s going to ask me if I want to download that as a CSV or do I need this as an Excel document or different things like that. So it’s much more useful now. This code interpreter works very well. It’s not enabled by default in every environment, and it’s purposely not available right now in this environment that I’m in. But I did want to let you know that that is something that can be used. Just going to minimize that here and I also wanted to see if there are any questions here. I’m actually going to stop sharing and switch back to the monitor. That is not such a massive resolution, so it’s a little bit faster here. Any questions so far from what we’ve covered today? If you do have them, drop them in the chat. We do have. I did drop in some. Let me go back and share my screen. Sure. Sorry, Teams is getting very slow right now. Yes. There we go. Much better. So hopefully you can see the last thing that I’m sharing here. I did put some resources together that do have different items that you can take a look at based on what we’ve discussed today. There are a lot of details in the notes on these different slides as well, so those are all available for everybody here, but there’s some video walkthroughs and. demos on this concept of one agent to control them all, different ways of using these multi-agent scenarios in Copilot Studio, orchestration, just different ways on how to do this, and then of course the official Microsoft documentation. We also do have, you know, the ability for you to complementary 30 minute session with one of our experts to actually, you know, kind of talk about and walk through how we can leverage some of these technologies in your organization. So and we also have a one-on-one executive training program. With Copilot opportunities available and those are some really good executive coaching sessions for Copilot for Office 365 to really get people up to speed and are champions using their tools quicker and gives people some really good insights from people that are actually using Copilot every day in their work. Really good program that was put together so you can get that through our survey. I think Amy dropped that in the link as well. If you could fill that out today, the link is in chat and like I said, Amy will share the deck with everybody after the presentation that will be available. So thank you all for your time today. If there are no questions, I will go ahead and end our call. stopped transcription