What it does

Sets out the ways to extend Microsoft 365 Copilot. The first decision is now where people will use the result: inside Microsoft 365 Copilot experiences, or in your own apps and custom agents built on APIs and SDKs. A single solution can use both.

Key facts

• Inside Copilot: build or configure supported agents, connectors, skills and MCP-based tools, usually brought together as a plugin, then follow the package, distribution and governance route for that object.
• In your own apps and agents: use the Work IQ APIs for Microsoft 365 work context and the Microsoft 365 Copilot APIs for search, retrieval, chat, export, meeting, reporting or administration capabilities.
• Declarative agents use Copilot's orchestrator and models. Custom engine agents bring their own orchestration, models, hosting and runtime.
• Using an API doesn't select a package or distribution route. Each part of a combined solution keeps its own identity, authentication, deployment, distribution and governance requirements.
• Microsoft now splits the guidance by audience: builders, administrators, and ISVs or software publishers each have their own entry point.
• Teams message extensions are listed as something to maintain or evaluate, not as the default new build.

When to use / skip

Start here before you commit to a build path. If you only need answers over your own content, a connector plus a declarative agent is usually enough. Reach for a custom engine agent, or an app calling the APIs, only when you need your own runtime, model or user interface.

Configuration decisions

• Experience inside Copilot, or one you host and operate. This decides who runs it and who supports it.
• Declarative versus custom engine, the biggest build fork.
• Where knowledge lives: SharePoint and Graph, a connector, or an external API.
• Read-only or write-back actions, which sets the governance burden.
• Whether you're building for your own tenant or for customers, which puts you on the ISV route.

Gotchas

• The old "three routes" mental model (declarative, custom engine, connectors) misses the apps-and-APIs path entirely. Check older internal decks.
• A plugin, its package, any app package, a marketplace offer and a hosted runtime are separate objects, each with its own process.
• Terminology drifts between Copilot Studio and the developer docs. Confirm which surface a capability lands in.
• A licence gap in the test tenant will block validation late in the day.

Consultant notes

• Ask "where do people sit when they use this?" first. It settles half the architecture before anyone mentions a model.
• Default to declarative. Custom engine means model hosting, evals and an operations commitment most business asks don't justify.
• Connector and grounding costs are per-item and per-query; price the data volume before you promise anything.
• Publishing runs through admin approval, so put governance friction in the plan from day one.

---

Review when Microsoft next restructures the extensibility landing page or adds a build path.