4.5.3. Agents in Microsoft 365 Copilot
Microsoft Copilot can be extended with custom agents through three mechanisms: declarative agents, API plugins, and Copilot connectors. The architect selects the right extensibility approach based on the scenario's complexity, data source requirements, and user experience goals.
💡 First Principle: Microsoft Copilot extensibility is additive — each mechanism layers capability onto the base Copilot experience. Declarative agents add instructions and knowledge. API plugins add actions. Copilot connectors add data. The architectural decision is which combination delivers the required capability at minimum complexity.
Extensibility Mechanisms:
| Mechanism | What It Adds | Complexity | Use Case |
|---|---|---|---|
| Declarative agents | Custom instructions, tone, knowledge scope | Low | Department-specific Copilot with constrained knowledge base |
| API plugins | External actions (CRUD operations on external systems) | Medium | Copilot that can create Jira tickets, update Salesforce records, check inventory |
| Copilot connectors | External data indexed into Microsoft Graph | Medium-High | Copilot that can search and reference content from ServiceNow, Confluence, or custom databases |
Declarative Agents:
Declarative agents are the simplest extensibility model. You define a manifest that specifies the agent's name, instructions (system prompt), knowledge sources, and capabilities. No code required — it's a configuration-based approach. The limitation: declarative agents can only access data that's already in Microsoft Graph or specified knowledge sources.
API Plugins:
When Copilot needs to take actions in external systems (not just read data), API plugins provide the bridge. The plugin exposes OpenAPI-described endpoints that Copilot can invoke based on user intent. Example: a user says "Create a support ticket for customer ABC with priority high" and Copilot calls the ticketing system's API through the plugin.
Microsoft 365 Copilot Connectors (formerly Graph connectors):
Copilot connectors come in two types. Synced connectors (the type this section means) ingest external data into Microsoft Graph's search index, making it available to Copilot's grounding. Unlike API plugins (which make real-time calls), Copilot connectors pre-index data — so Copilot can search it like native M365 content. The trade-off is freshness: indexed data may lag behind the source system.
Federated Copilot connectors instead fetch data live through the Model Context Protocol (MCP) without indexing it, and are read-only. Choose them for sensitive or fast-changing sources that shouldn't be indexed.
Decision Framework:
⚠️ Exam Trap: A scenario asks about making Copilot search a company's internal wiki hosted on Confluence. A distractor suggests building an API plugin. The correct answer is a Copilot connector — the use case is search/retrieval, not action execution. API plugins are for doing things in external systems, not for making their content searchable.
Reflection Question: A consulting firm wants Microsoft Copilot to (1) search their project management tool for project status, (2) create time entries in their billing system, and (3) follow firm-specific tone and confidentiality guidelines. Map each requirement to the correct extensibility mechanism.
