What it does

Sets out the ways you can extend Microsoft 365 Copilot: give it new knowledge, new skills, or build a purpose-built agent that sits inside Copilot Chat and the app catalogue.

Key facts

• Three broad routes: declarative agents (Copilot's own model, your instructions/knowledge/actions), custom engine agents (your own model and orchestration), and Copilot connectors to ground Copilot in external data.
• Actions come via API plugins (OpenAPI), Copilot connectors, or MCP servers.
• Declarative agents are packaged as Teams/M365 app packages and distributed through the same app pipeline.
• Building needs a Microsoft 365 Copilot licence in the target tenant to test end to end; makers need Teams Toolkit, Copilot Studio, or Agent Builder.

When to use / skip

Start here before you commit to a build path. If you only need to answer questions over your own content, a connector plus a declarative agent is usually enough. Reach for a custom engine agent only when you genuinely need your own model or orchestration logic.

Configuration decisions

• Declarative vs custom engine — the single biggest fork.
• Where knowledge lives: SharePoint/Graph, a connector, or an external API.
• Whether actions are read-only or write-back, which changes your governance burden.

Gotchas

• "Extensibility" spans several docs and product teams; terminology drifts between Copilot Studio and the developer docs. Confirm which surface a feature actually lands in.
• A licence gap in the test tenant will block validation late in the day.

Consultant notes

• Default to declarative. Custom engine is a real engineering commitment — model hosting, evals, the lot — and most business asks don't need it.
• Connector and grounding costs are per-item and per-query; price the data volume before you promise anything.
• Publishing runs through admin approval, so factor governance friction into the timeline from day one.

---

*Review if Microsoft restructures the extensibility landing page or adds a new build