The Citadel · 18 min mission
Microsoft Copilot Technology Map: Surfaces, Grounding, Tools, and Runtime Choices
Pick the right Microsoft Copilot lane before building: app Copilot, Copilot Studio, declarative agent, API plugin, MCP, connector, flow, or custom engine.
Orientation
This guide is the map you use before building anything. It is for product owners, makers, developers, and platform teams who need to decide whether a request belongs in app Copilot, Microsoft 365 Copilot Chat, Agent Builder, Copilot Studio, a declarative agent, an API plugin, MCP, a connector, Power Automate, Microsoft Graph, or a custom backend.
The Microsoft Copilot stack is easier to reason about when you separate surfaces, grounding, actions, orchestration, and governance. The names overlap, but the responsibilities do not.
Use Microsoft 365 Copilot Chat and app Copilots for user-led work over the user's Microsoft 365 context. Use Copilot Studio for governed low-code agents. Use declarative agents when you need a Microsoft 365 Copilot agent package with instructions, knowledge, and actions. Use API plugins or MCP plugins when the agent needs live external tools. Use Microsoft 365 Copilot connectors when external content should become searchable and citeable. Use Power Automate or a backend when the business process needs deterministic execution, retries, approvals, and audit.
How to use this interactive section
Copilot Pathfinder is an intake exercise. Start with the business request, not the technology name someone suggested.
- Choose the scenario that best matches the actual job.
- Compare the recommended lane with the "do not confuse it with" warning in the table below.
- If the request includes both grounding and writes, split the architecture into a read layer and an action layer.
- Write down the owner, auth model, source system, channel, audit need, and rollout group before implementation.
- If more than one lane still looks plausible, choose the lowest-risk lane that satisfies the user task.
Copilot Pathfinder
Copilot pathfinder
Pick the Microsoft lane before you build
Select the work signals that matter. The result separates grounding from live execution and rejects lanes that are a poor fit.
| Need | Best starting point | Why | Do not confuse it with |
|---|---|---|---|
| User wants help inside work apps | Microsoft 365 Copilot or Copilot Chat | Grounded in app context, Microsoft Graph, selected files, and allowed web context | A workflow engine or an external API integration layer |
| Business wants a governed agent | Copilot Studio | Low-code topics, generative orchestration, knowledge, tools, channels, analytics, and Power Platform ALM | A custom model runtime with full orchestration ownership |
| Microsoft 365 Copilot needs a packaged agent | Declarative agent | Instructions, conversation starters, knowledge, capabilities, and action references in an app package | Copilot Studio topics or Power Automate flows |
| Agent needs live REST operations | API plugin over a backend facade | OpenAPI operation metadata and response semantics guide tool use and citations | Raw Jira or Confluence REST paths exposed directly to the model |
| Agent needs task-level live tools | Remote MCP plugin | Curated MCP tools can combine Jira, Confluence, policy, widgets, and prepare/commit write contracts | Graph connector indexing |
| External content must be searchable | Microsoft 365 Copilot connector, backed by Microsoft Graph connector APIs for custom synced connectors | External items become permission-trimmed search and Copilot grounding content | Write-back automation |
| External data must be read live but not indexed | Federated Copilot connector where available, or a read-only MCP/API action | Live retrieval avoids copying the content into the Microsoft 365 index | A synced connector or write-capable action |
| Process needs retries, approvals, schedule, and audit | Power Automate, agent flow, or backend worker | Deterministic workflow engines own durable state, retries, approval records, and notifications | A free-form chat prompt |
| Developer needs custom runtime or model orchestration | Custom engine agent with Microsoft 365 Agents SDK or another backend architecture | The team controls runtime, model stack, state, and external channels | A declarative agent that runs on Microsoft 365 Copilot orchestration |
Use This When / Avoid This When
Use the map when
A request mentions an agent, connector, MCP server, workflow, live API, source-system write, tenant rollout, or admin approval. The map keeps the team from building the wrong layer.
Avoid building when
The team cannot name the user task, source owner, action owner, auth model, permission boundary, audit record, or success test. That is not an implementation brief yet.
How to use this interactive section
The Agent Architecture Planner shows what changes when you move from a daily Copilot workflow to a governed agent architecture.
- Select the architecture closest to your scenario.
- Read the runtime, knowledge, action, auth, and failure-mode fields.
- Compare those fields with your own rollout environment.
- Use the missing controls as your backlog before pilot.
- Do not copy the architecture if the failure modes are not acceptable for your data class.
Agent Architecture Planner
Agent architecture planner
Connector grounding + live action layer
Broad Jira/Confluence search plus current-state writes
Flow
1. Synced Microsoft 365 Copilot connector indexes external items 2. Schema maps title, URL, source type, status, labels, and modified date 3. ACLs and external groups trim search results 4. API/MCP tool re-reads live Jira or Confluence before any write 5. Power Automate or backend records approval and audit
Knowledge
Indexed or federated read-only connector results with citations.
Action
Separate API, MCP, flow, or backend layer. Connectors do not write back.
Auth
Connector indexing uses admin/app setup; live action uses delegated/OBO or scoped service account.
Failure cases to test
- - ACL changes need full crawl
- - Index freshness lag
- - Everyone grant overexposure
- - Graph API confused with connector
| Term | What it is | What it is not |
|---|---|---|
| Microsoft 365 Copilot Chat | A work/school chat surface whose capabilities depend on license, tenant policy, and grounding configuration | A place where every user automatically gets all Microsoft Graph and external-system actions |
| Agent Builder | A no-code path for straightforward agents, knowledge sources, sharing, and org catalog submission | The same thing as Copilot Studio ALM or a pro-code package pipeline |
| Copilot Studio agent | A low-code governed agent with topics, tools, knowledge, channels, analytics, and Power Platform controls | A custom runtime where the team owns every model and orchestration detail |
| Declarative agent | A Microsoft 365 app package that instructs Microsoft 365 Copilot and can reference capabilities and actions | A bot server or Power Automate flow |
| Microsoft 365 Copilot connector | A synced or federated path for external knowledge grounding and source citations | A publish, transition, update, or notification mechanism |
| Microsoft Graph API | A live API for Microsoft cloud data and connector ingestion resources | The same thing as Copilot grounding or the semantic index |
Architecture intake checklist
Write the user job in one sentence
Example: "A program lead needs a source-linked weekly risk draft and approved Confluence publish." Do not start with "build an MCP server."
Classify read versus write
Read-only knowledge can use Copilot Chat, app Copilot, Agent Builder, Copilot Studio knowledge, or connectors. Writes need an action layer with preview, approval, idempotency, and audit.
Choose the orchestration owner
Microsoft 365 Copilot owns declarative-agent orchestration. Copilot Studio owns low-code orchestration. A custom engine or backend owns custom runtime behavior.
Choose the identity model
Prefer end-user credentials for user-specific data. Use maker credentials, app-only permissions, or service accounts only when deliberately governed and documented.
Prove the failure path
Before pilot, test missing source access, stale connector data, DLP block, auth denied, rate limit, approval expired, and changed target record.
flowchart LR
User[User in Microsoft 365 Copilot] --> Agent[Declarative agent]
Agent --> Connector[Copilot connector: read-only citations]
Agent --> Tool[API or MCP tool facade]
Tool --> Policy[Auth, allowlist, rate limits]
Policy --> Jira[Jira read]
Policy --> Preview[Confluence preview]
Preview --> Approval[Explicit approval]
Approval --> Reread[Live Confluence re-read]
Reread --> Write[Create or update page]
Write --> Audit[Durable audit record]| Symptom | Wrong assumption | Better lane |
|---|---|---|
| Connector answer is stale before a write | Connector grounding was treated as live execution state | Use connector for citations, then re-read live state through API/MCP/backend before writing |
| Agent has too many overlapping tools | The orchestrator was expected to compose brittle low-level actions perfectly | Collapse related calls behind a task-level facade or agent flow |
| One-off user task became a platform project | A normal app-Copilot workflow was overbuilt as a governed agent | Keep it in Teams, Outlook, Word, Excel, PowerPoint, OneDrive, or Copilot Chat |
| MCP server chosen for one stable operation | MCP was selected because it sounded current | Use an API plugin or Power Platform connector when one bounded REST operation is enough |
| Production publish depends on a maker account | Personal connection setup was accepted as governance | Move to solutions, connection references, environment variables, and reviewed credentials |
Knowledge check
What should you choose when external content needs citations but no write-back?
Reach the end and this star joins your charted sky.