Extensibility: Custom Models, M365 Agents & Copilot Studio
Design AI extensibility using custom Foundry models, M365 Copilot declarative agents with instructions, knowledge, and actions, and Copilot Studio plugins and connectors.
Three paths to extend AI capabilities
Think of prebuilt AI as a company car — it gets you where most people need to go.
Custom Foundry models are like building a custom vehicle for a specific job. Need an armoured truck for transporting cash? A refrigerated van for food delivery? You design and build it yourself because no off-the-shelf vehicle fits.
M365 Copilot agents are like adding a specialised GPS to the company car — it still uses the same engine (Microsoft 365 Copilot), but now it has custom instructions, maps (knowledge), and shortcuts (actions) for your specific business.
Copilot Studio extensibility is like adding aftermarket parts to the company car — custom connectors, extra tools, and plugins that make it do things the manufacturer didn’t plan for.
Comparing the three extensibility paths
| Feature | What You're Extending | How It Works | When to Choose It |
|---|---|---|---|
| Custom Foundry models | The AI model itself — custom training, fine-tuning, or deploying specialised models | Deploy from the model catalogue, fine-tune with domain data, or build custom pipelines with prompt flows | When prebuilt models can't handle the domain-specific task — specialised classification, domain reasoning, or unique output formats |
| M365 Copilot agents | Microsoft 365 Copilot's behaviour — adding custom instructions, knowledge, and actions | Create declarative agents with a manifest that defines instructions, knowledge sources (SharePoint, web), and actions (API plugins) | When users work in M365 and need Copilot to understand domain-specific knowledge or perform custom business actions |
| Copilot Studio extensibility | A Copilot Studio agent's capabilities — adding new tools, data sources, and integrations | Add custom connectors, Power Automate actions, plugins, or external API endpoints to agent topics | When the Copilot Studio agent needs to interact with external systems, call APIs, or perform actions beyond its built-in connectors |
Custom Foundry models
Use custom Foundry models when prebuilt AI capabilities don’t meet the requirement. Common scenarios:
| Scenario | Why Custom | Foundry Approach |
|---|---|---|
| Credit risk scoring with proprietary algorithms | Generic models lack domain-specific risk factors | Fine-tune a model on historical credit decisions |
| Medical image analysis | Requires specialised visual understanding | Deploy a custom vision model trained on clinical images |
| Regulatory document classification | Industry-specific taxonomy not covered by general NLU | Train a custom classifier with labelled regulatory documents |
| Multi-language customer intent for a niche industry | Standard NLU models underperform on domain jargon in multiple languages | Fine-tune a multilingual model with domain-specific training data |
Architecture pattern: Deploy the custom model in Foundry → expose via a managed endpoint → consume from Copilot Studio, Power Apps, or D365 via a custom connector or API.
M365 Copilot declarative agents
Declarative agents extend Microsoft 365 Copilot without building a model. You declare:
- Instructions — what the agent does, its persona, rules, and guardrails
- Knowledge — where the agent looks for information (SharePoint sites, web URLs, files)
- Actions — what the agent can do beyond answering questions (call APIs, trigger workflows)
Design decisions for declarative agents:
| Decision | Options | Guidance |
|---|---|---|
| Scope | Personal agent, shared agent, or org-wide | Start narrow (team), expand after validation |
| Knowledge sources | SharePoint, Graph connectors, web, files | Keep focused — too many sources dilute accuracy |
| Action complexity | Simple (read data) or complex (write data, trigger processes) | Start read-only. Add write actions after trust is established |
| Guardrails | Instructions that limit what the agent discusses | Always include “do not answer questions outside of…” instructions |
Copilot Studio extensibility
Extend Copilot Studio agents to interact with the world beyond Microsoft’s built-in connectors:
- Custom connectors — connect to any REST API (internal tools, SaaS platforms, databases)
- Power Automate actions — trigger complex workflows that span multiple systems
- Plugins — reusable capability packages that add skills to an agent
- External API integration — direct HTTP calls to external services from within topics
Scenario: Dev builds a custom credit risk model for Vanguard
Dev Patel (AI Platform Engineer at Vanguard Financial Group) designs a credit risk assessment solution. The prebuilt AI models can’t handle Vanguard’s proprietary risk scoring methodology.
Step 1 — Custom model: Dev fine-tunes a GPT model in Foundry with 10 years of anonymised credit decisions. The model learns Vanguard’s specific risk factors (industry exposure, counterparty relationships, regulatory capital requirements).
Step 2 — Evaluation: Runs the model against 500 known cases. Measures accuracy against human risk analyst decisions — achieves 91% agreement.
Step 3 — Deployment: Deploys the model as a managed endpoint in Foundry with content safety filters.
Step 4 — Copilot Studio integration: Natalie’s team builds a Copilot Studio agent for loan officers. When a loan officer asks “What’s the risk assessment for Application 4521?”, the agent:
- Retrieves the application from D365 Finance (custom connector)
- Calls the Foundry credit risk model (custom connector to the endpoint)
- Returns the risk score with reasoning
Step 5 — M365 Copilot agent: Adrienne wants the same capability in Teams. Dev creates a declarative agent that gives the investment team access to risk assessments directly in their M365 workflow — without leaving Teams.
Marcus Webb (CISO) reviews the architecture: all data stays within Vanguard’s tenant, the model endpoint is secured with managed identity, and every assessment is logged for audit.
Exam tip: don't over-extend
The exam tests judgment on WHEN to use extensibility:
- “Standard Copilot already does this well” → Don’t extend. Use prebuilt capabilities.
- “The AI needs domain-specific knowledge that lives in SharePoint” → M365 declarative agent with knowledge source — no custom model needed.
- “The AI needs to call a third-party API” → Copilot Studio custom connector or action — no custom model needed.
- “The AI’s reasoning accuracy is insufficient for the domain” → Custom Foundry model with fine-tuning.
The simplest extensibility path that meets the requirement is usually the right answer.
Flashcards
Knowledge check
Adrienne wants to give Vanguard's compliance team an AI assistant that answers questions about the company's internal policies. The policies are stored in SharePoint. The assistant should work inside Teams. What is the most appropriate extensibility approach?
Dev needs to extend a Copilot Studio agent to check a customer's credit score from a third-party credit bureau API in real-time during a conversation. The API returns a JSON response with the score and risk factors. What extensibility approach should Dev use?
Next up: MCP, Computer Use & Agent Behaviours — extending agents with Model Context Protocol, automating tasks with Computer Use, and designing reasoning and voice behaviours.