Module 6 of 11
Design extensibility of AI solutions
Extend Microsoft 365 Copilot and Copilot Studio with connectors, MCP, Computer Use, and Foundry custom models.
Exam questions Q51–Q60 10 units on Learn
Open module 6 on Microsoft Learn ↗ Watch the episode (49 min)
Why this module matters
Extensibility is about meeting users where they already work. Rather than building a separate destination, you extend Microsoft 365 Copilot so the agent inherits its orchestration, identity model, and grounding — and users need learn nothing new.
The key architectural distinction, tested repeatedly, is declarative agent versus custom engine agent. Learn what each gives you and what each costs you.
The one big ideaExtend the host when you can; own the engine only when you must. Every capability you take over — orchestration, model hosting, identity — becomes yours to secure, monitor, and maintain.
What Microsoft Learn covers
Units in this module, as published on Microsoft Learn:
- Introduction
- Design AI solutions with custom models in Microsoft Foundry
- Design agents in Microsoft 365 Copilot
- Design extensible agents in Microsoft Copilot Studio
- Design extensible agents using MCP in Copilot Studio
- Design agents to automate tasks in apps and websites with Computer Use in Copilot Studio
- Design agent behaviors in Copilot Studio
- Optimize solution design for agents in Microsoft 365
- Module assessment
- Summary
Watch this module
Microsoft Learn publishes a free video course for AB-100 on YouTube. This module is covered by one 49 min episode. An instructor walking through the module is often faster than reading it twice.
Key concepts and definitions
| Declarative agent | Runs on the host Copilot's orchestrator and model. You supply instructions, knowledge, and actions declaratively. Fast, governed, and the default choice. |
| Custom engine agent | You provide your own model and orchestration logic. Choose only for a specific model requirement, bespoke orchestration, or hosting constraints. |
| Graph connector | Indexes external content into Microsoft Graph so Microsoft 365 Copilot can ground on it with permissions honoured. |
| Model Context Protocol (MCP) | A standard way for agents to discover and call external tools and data sources, so integrations are reusable rather than bespoke per agent. |
| Computer Use | Copilot Studio capability that drives applications and websites through their user interface — for systems with no usable API. |
| Agent behaviours | Configurable characteristics such as reasoning depth and voice mode that shape how the agent operates. |
| Microsoft Foundry custom model | A model you select, tune, or host yourself when platform defaults genuinely cannot meet the requirement. |
| Loose coupling | Components interact through well-defined, versioned contracts, so they can be reused across agents and changed independently. |
| Token exchange / on-behalf-of | Passing the user's identity to a downstream API so least-privilege scopes and per-user authorisation are enforced. |
| Contract versioning | Publishing /v1, /v2 style versions with a deprecation window and consumer communication, rather than changing an endpoint in place. |
Design guidance
Choosing an extensibility route
- External content that should be searchable and grounded in Microsoft 365 Copilot → Graph connector.
- Reusable tool or data integration consumed by several agents → expose it over MCP.
- Legacy system with an API → put a governed API layer in front (gateway or connector, authentication, throttling) and call it.
- Legacy system with no usable API → Computer Use as a pragmatic last resort, accepting its fragility.
- Requirement pins a specific model or bespoke orchestration → custom engine agent in Foundry.
Security of extensions
- When calling downstream on a user's behalf, design token exchange, consent, least-privilege scopes, and per-user authorisation — not just the request format.
- Never widen access to make an integration simpler. An extension must not become a permissions bypass.
- Treat anything retrieved from an external system as untrusted data, never as instructions.
Designing for reuse and change
- Aim for loose coupling with explicit contracts so one component serves many agents.
- Version contracts and run a deprecation window; do not overwrite endpoints in place.
- Design within host limits: response size, latency budgets, supported authentication types, throttling, and capability caps.
Good practice vs. anti-pattern
Do
- Default to declarative agents on the host platform.
- Standardise integrations behind MCP or governed connectors.
- Enforce per-user authorisation on every downstream call.
- Version contracts and communicate deprecations.
Avoid
- Own an engine you do not need to own.
- Expose a database directly to an agent.
- Assume the host has unlimited response size or no throttling.
- Duplicate the same integration logic inside every agent.
Exam traps to watch for
TrapDeclarative agent = host's orchestrator and model. If an option says it requires you to host your own model, that is a *custom engine* agent.
TrapGraph connectors are the answer for grounding Microsoft 365 Copilot in external data — not Power Automate, not Dataverse plug-ins.
TrapMCP is a tool and data-source integration standard, not a model training framework, billing meter, or UI library.
TrapExtensions do not bypass permissions. Host limits — latency, response size, auth types, throttling — always exist and must be designed around.
Readiness checklist
You are ready to move on when you can do all of these without notes.
- State the difference between a declarative and a custom engine agent, and when each is justified.
- Choose the right extensibility mechanism for four different integration scenarios.
- Explain what MCP standardises and why that reduces long-term cost.
- Describe the auth design for a downstream call made on a user's behalf.
- Name four host limits an extension must respect.