Microsoft 365 Copilot is moving far beyond prompt engineering. As organizations adopt AI more seriously, the challenge becomes connecting Copilot and AI agents to business applications, Microsoft Graph, organizational knowledge, APIs, workflows, and enterprise data while maintaining security and governance. In this episode of the M365 FM Podcast, Mirko Peters talks with Microsoft MVP and AI Tech Lead Yves Habersaat about Microsoft 365 Copilot extensibility, Copilot Studio, Microsoft Foundry, Model Context Protocol (MCP), RAG, multi-agent architectures, enterprise search, permissions, governance, AI readiness, and what it takes to build production-grade AI solutions.
FROM PROMPT ENGINEERING TO AI ARCHITECTURE
Prompt engineering can help employees get more value from generative AI, but enterprise AI requires much more than better prompts. Organizations need people who understand the underlying technologies, customer requirements, architecture, security, business applications, data, and implementation decisions. Yves argues that human architects and engineers remain important because AI can generate technical material and provide guidance, but organizations still need people capable of validating whether a solution actually addresses the business requirement.
WHERE COPILOT EXTENSIBILITY BEGINS
Microsoft 365 Copilot has evolved considerably since its earliest versions. Many capabilities that previously required extensions are now available directly within the platform. Extensibility becomes particularly relevant when organizations need greater control. This could mean customizing orchestration, creating specialized agent experiences, integrating an agent into a website rather than only Microsoft 365 Copilot Chat, or building capabilities that aren't available through the standard experience. The more specialized the requirement becomes, the more important extensibility and custom development become.
WHY ONE GIANT COPILOT ISN'T THE ANSWER
Instead of building one enormous Copilot containing every instruction, tool, knowledge source, and responsibility, Yves recommends thinking in terms of multi-agent architectures. Individual agents can have clearly defined scopes and responsibilities. An IT support architecture, for example, could contain a front-facing agent responsible for understanding the user's request and routing it to specialized agents for Microsoft 365, Salesforce, or other platforms. Each specialized agent can then maintain its own instructions, knowledge, and tools.
THE ANATOMY OF AN ENTERPRISE AI AGENT
A typical enterprise agent starts with a clearly defined objective. The agent then requires instructions defining its responsibilities and boundaries, knowledge sources containing relevant organizational information, tools allowing it to perform actions, and an orchestration layer deciding how requests should be processed. In a multi-agent architecture, a front agent can delegate tasks to specialized agents. Those agents can then access internal knowledge sources, external systems, APIs, and MCP servers depending on the task they need to perform.
COPILOT STUDIO VS CUSTOM DEVELOPMENT
Copilot Studio provides a low-code approach to building agents. Organizations can define instructions, connect tools, integrate knowledge sources, and use MCP servers without building every component themselves. Custom development provides significantly greater control but also introduces more architectural responsibility. Developers may need to manage authentication, security, hosting, orchestration, external services, and integration patterns themselves. The decision therefore isn't simply low-code versus code. It depends on how much control the solution actually requires.
WHEN COPILOT STUDIO REACHES ITS LIMITS
One of the major questions is whether the organization needs to customize orchestration. If standard orchestration satisfies the requirement, Copilot Studio can provide a fast route to building an agent. If developers need deeper control over how plans are created, tasks are prioritized, workflows are executed, or models are selected, custom development becomes more relevant. Custom solutions can also integrate models hosted outside Microsoft's ecosystem, giving organizations additional flexibility over their AI infrastructure.
MICROSOFT FOUNDRY AND THE CHANGING AI STACK
Microsoft Foundry has evolved from its earlier role around model deployment into a broader AI development platform. Yves describes a platform increasingly supporting agent creation, governance, model management, MCP integration, and other capabilities. This creates some overlap with Copilot Studio, while custom development continues to provide greater flexibility around models, orchestration, hosting, and architecture. The Microsoft AI development landscape is therefore evolving rapidly, making architectural decisions increasingly dependent on the specific use case.
WHAT IS MODEL CONTEXT PROTOCOL?
Model Context Protocol, or MCP, addresses one of the major challenges in agent development: providing a standardized way for AI systems to discover and interact with external tools and services. Historically, developers integrated individual APIs using different authentication mechanisms, protocols, documentation, and implementation approaches. MCP provides a more standardized interface through which agents can understand which tools are available and how those tools can help accomplish a task. Yves describes it as an increasingly important part of modern AI architecture.
MCP VS TRADITIONAL API INTEGRATION
MCP doesn't eliminate APIs. Instead, an MCP server can sit in front of existing APIs, databases, and internal services and expose those capabilities in a way AI systems can understand. A company might already have APIs for finance, HR, CRM, or operational systems. An MCP server can expose appropriate tools around those services while the existing APIs continue performing the underlying operations. This makes MCP an AI-oriented integration layer rather than a replacement for the systems underneath it.
HOW AGENTS CHOOSE TOOLS
An enterprise agent might eventually have access to dozens or hundreds of tools. The agent's orchestration layer, working with the language model, can inspect the available capabilities and determine which tools are relevant to the user's request. It can then create a plan containing the actions required to complete the task and potentially invoke several tools in sequence. This ability to discover and select tools dynamically is one reason MCP has become important in agentic architectures.
MICROSOFT GRAPH REMAINS CENTRAL
MCP doesn't make Microsoft Graph irrelevant. Yves explains that Microsoft 365 MCP capabilities can rely on Microsoft Graph behind the scenes. An agent interacts with the MCP capability while Graph provides access to Microsoft 365 information and services underneath it. Graph also remains important to Microsoft 365 Copilot because organizational context across Microsoft 365 can be accessed through Microsoft's underlying graph and search capabilities. The integration layer is evolving, but Graph remains a major foundation of the Microsoft 365 ecosystem.
SECURING ORGANIZATIONAL KNOWLEDGE
Microsoft 365 contains enormous amounts of organizational context: documents, meetings, emails, people, Teams conversations, OneDrive files, and SharePoint content. Connecting AI to that information without proper governance creates obvious risks. Yves recommends beginning by understanding the organization's data. Companies need to know where confidential information exists, who should have access, and what information requires additional protection. Microsoft Purview capabilities such as sensitivity labels and Data Loss Prevention can then become part of the governance architecture.
DATA QUALITY IS AN AI PROBLEM
AI governance isn't only about preventing unauthorized access. Poorly organized SharePoint sites, duplicated files, outdated documents, inconsistent Teams environments, and unclear information ownership can reduce the quality of AI responses. Connecting an agent to organizational knowledge doesn't automatically make that knowledge useful. Organizations therefore need to consider data cleanup, information architecture, permissions, classification, and governance as part of AI readiness.
DELEGATED VS APPLICATION PERMISSIONS
Permissions become especially important when agents can take actions. Yves recommends delegated user permissions as the general starting point. This means an agent operates according to the permissions of the person using it. If the user doesn't have access to particular information or functionality, the agent shouldn't automatically gain that access on their behalf. Where application permissions are genuinely necessary, Yves suggests isolating them behind a controlled service or MCP layer rather than exposing broad application permissions directly to the user-facing agent.
RAG IN ENTERPRISE AI ARCHITECTURE
Retrieval-Augmented Generation, or RAG, allows AI systems to retrieve relevant organizational information before generating an answer. Instead of expecting the language model itself to contain current company-specific information, the system retrieves appropriate content from organizational knowledge sources. That information can come from documents, knowledge bases, Microsoft 365 content, or other enterprise systems. For many users, this happens invisibly because platforms such as Copilot Studio abstract the underlying retrieval architecture. ㅤ
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
