What it does
This is the "you host it, you run it" extensibility path: an application you own calls the Work IQ APIs and the Microsoft 365 Copilot APIs to use Microsoft 365 work context and Copilot capabilities. It sits beside the plugin path, which is for agents that run inside Microsoft's own experiences.
Key facts
- Two documented API options. Work IQ APIs expose Microsoft 365 work context through REST, agent-to-agent (A2A) and MCP interfaces. The Microsoft 365 Copilot APIs cover search, retrieval, chat, export, meetings, reporting and administration.
- You can combine them. Microsoft's own example is Copilot APIs for chat and retrieval plus Work IQ APIs for work context.
- You own the user experience, runtime, deployment and application lifecycle. Microsoft doesn't package, host or govern the app for you.
- Calling an API doesn't make something a plugin. A plugin goes through the package, registry, distribution and governance lifecycle; an app can talk to plugins or ship separately packaged capabilities, but each part keeps its own lifecycle requirements.
- An API plugin is an action mechanism used by a declarative agent. It isn't a Microsoft 365 Copilot API and isn't a peer capability in the plugin registry model.
- Building a custom engine agent that you host and package as a plugin is a different route; the page sends you to the plugin build guidance for that.
When to use / skip
Use it when people interact with your application rather than with Copilot Chat, and you need control over the experience, hosting and release cadence. Skip it if what you want is an agent users invoke inside Microsoft 365 Copilot; that is a declarative agent or plugin, with the lifecycle that comes with it.
Configuration decisions
- Which API surface: Work IQ for work context, Copilot APIs for chat/retrieval/reporting, or both.
- Identity model: user, application and service identities, and the permissions, consent and authentication each needs.
- Hosting model, deployment environments, monitoring, support, versioning and incident response.
- Data access, storage, retention, privacy, security and responsible AI posture.
- Whether any part of the solution also needs a plugin or Microsoft 365 app package. If so, plan that separately.
Gotchas
- "We call the Copilot APIs" doesn't put the thing in the plugin registry, the admin catalogue or any of the plugin governance controls. Administrators won't see it there.
- A mixed solution has two lifecycles. The app's release process and the plugin's package-and-publish process don't move together unless you make them.
- Retirement is yours too: identities, permissions and service accounts outlive the app unless someone removes them.
Consultant notes
- Settle early whether the requirement is an app or an agent. Teams routinely scope a custom web app because "we want Copilot in it", when a declarative agent in Copilot Chat would have done the job with far less to operate.
- Own the support model before the build. An app on these APIs is a product you run, with on-call, versioning and a deprecation plan, not a configuration item.
- In a mixed solution, write down which lifecycle owns which artefact at design stage. At go-live it's always the plugin half that nobody scheduled a review for.
- Treat identity and consent as the long pole. Permissions that look fine in a dev tenant tend to meet a very different admin consent process in production.
Review when the Work IQ or Microsoft 365 Copilot API surfaces change status, or when this page's guidance on app versus plugin lifecycles is revised.