Claw field notebook
● last updated 2026-05-15 edit on GitHub colophon
§ 7 Compare / § 7.3 · 7 min read

M365 extensibility paths — Copilot Studio · Declarative Agents · Custom Engine Agents

Three practical paths to build for Microsoft 365 Copilot. Where each fits, what each costs the builder and the end user, and the canonical taxonomy your readers will see on learn.microsoft.com.

Microsoft’s own taxonomy is two-way (read this first)#

⚠️ The canonical decision-guide page on Microsoft Learn does NOT present a three-way split. It uses two section headings: Declarative agents and Custom engine agents. Copilot Studio is positioned as a builder tool that can produce either type — not as a separate path.

This page presents three rows because that matches how most teams actually scope the work — “should we build this in Copilot Studio, or hand-author a manifest, or write our own orchestrator?” But readers cross-referencing the Microsoft page will see the two-way framing as the primary one.

Bottom line for cross-referencing: if you pick “Copilot Studio” from this page’s matrix, look at the How the three paths overlap section below to find out which Microsoft taxonomy bucket your artefact actually lands in.

What this comparison is#

Three practical ways to ship something useful inside Microsoft 365 Copilot:

  • Copilot Studio — graphical low-code builder, can produce either a standalone agent that runs on Copilot Studio’s own orchestrator (15+ channels, including WhatsApp and Cortana) OR a declarative agent that runs on M365 Copilot’s orchestrator.
  • Declarative Agents — manifest-defined (currently v1.7 schema) agent that runs on Microsoft’s M365 Copilot orchestrator with Microsoft’s foundation models. No hosting required. M365-only channels.
  • Custom Engine Agents — bring-your-own orchestrator + model + hosting. Built with the M365 Agents Toolkit (ATK) or the M365 Agents SDK (C# · JS · Python). Most flexible, most operational cost.
Dimension Copilot Studio Declarative Agents Custom Engine Agents
Microsoft's canonical taxonomy Builder tool for either path Produces a Declarative Agent (M365 orchestrator) or a standalone agent (Copilot Studio orchestrator) depending on mode Declarative agents One of Microsoft's two canonical approaches Custom engine agents The other canonical approach; ATK is the primary pro-code tool
Authoring shape Low-code (graphical SaaS) Also natural-language no-code builder; advanced config for pro users Low-code or pro-code Copilot Studio or M365 Copilot agent builder (low-code); ATK or VS Code (pro-code) Pro-code (primarily) M365 Agents Toolkit + Agents SDK (C# · JS · Python); Copilot Studio is the low-code sub-path
Orchestrator runtime Copilot Studio orchestrator (standalone) or M365 Copilot orchestrator (DA mode) M365 Copilot orchestrator (always) No extra AI hosting needed — Microsoft hosts Bring your own Semantic Kernel · LangChain · Azure Bot Service · Microsoft Foundry — your choice
End-user M365 Copilot licence Not required for standalone agents Standalone agents bill in Copilot Credits to the tenant Required (except web-search-only or instruction-only) Per Microsoft cost-considerations: instruction-only and web-search-only agents are exempt — accessible via Copilot Chat at no extra cost. Other capabilities need M365 Copilot licence or tenant pay-as-you-go for shared tenant data. Not required Custom engine agents in M365 Copilot Chat are free for unlicensed users; Copilot Credits apply if they access shared tenant data
Builder cost / licence Free Copilot Studio user licence + Copilot Credits capacity Per-message billing retired Sep 1 2025; current model is Copilot Credits ATK is free; M365 Copilot tenant needed for testing TAP sandbox or eligible M365 Copilot production tenant ATK is free; hosting billed separately Microsoft Foundry, App Service, Bot Service all billed independently
Channels available 15+ channels Microsoft channels (Teams · M365 Copilot · SharePoint · custom website · mobile) plus Azure Bot Service channels (WhatsApp · Facebook · Slack · Telegram · others). See sourced list. M365 only Copilot Chat · Teams · Word · Excel · Outlook · PowerPoint. No external channels. M365 + external apps + Azure Bot Service channels Also supports proactive (agent-initiated) messaging and agent-to-agent (A2A) collaboration
Tool palette Built-in + 600+ Power Platform connectors + custom REST/OpenAPI + MCP Code interpreter (GA Aug 2025), Computer Use (preview), Work IQ (preview Mar 2026), model picker incl. GPT-5 + Claude Sonnet 4.5/4.6 Capability set defined in v1.7 manifest v1.7: web search · OneDrive/SharePoint · Copilot connectors · code interpreter · embedded knowledge · API plugins (1-10/agent) · worker agents — see manifest docs for full list Any — orchestrator can call any API, tool, or model M365 data via Microsoft Graph; Microsoft Foundry agents integratable via ATK template (foundry-agent-to-m365)
MCP support Client — GA (August 2025) Connect to existing MCP servers via guided UI; Streamable HTTP transport (SSE deprecated after Aug 2025) Via ATK CLI scaffolding — GA in ATK 6.8.0 (Apr 17 2026) `atk add action --api-plugin-type mcp` CLI command added in 6.8.0. MCP integration for DAs was in preview in ATK 6.4.0 (Nov 14 2025) and went GA in ATK 6.6.0 (Mar 9 2026). Client — via your orchestrator Use the open MCP SDKs (github.com/modelcontextprotocol) inside your orchestrator code
AppSource publishing Tenant catalogue only Standalone Copilot Studio agents publish to the tenant catalogue; commercial AppSource path requires DA-mode authoring via ATK Yes Packaged as a Teams app; published via Teams Developer Portal Yes (via Teams SDK · Agents SDK · Foundry-via-ATK) Copilot Studio standalone agents are tenant-catalogue-only; commercial AppSource requires the pro-code paths above
Best for Quick low-code multi-channel agents on managed infra Especially: ISVs and enterprises wanting WhatsApp/Teams/web simultaneously without standing up infrastructure M365-focused agents that inherit MS compliance + foundation models When you don't need external channels or custom orchestration; M365 Copilot does the heavy lifting Custom orchestration · choice of model · external channels · proactive flows When you have specific orchestration, channel, or model requirements that the managed paths can't meet

Where each wins#

Copilot Studio#

  1. The channel reach. WhatsApp, Facebook, Slack, Telegram, Twilio, and others via Azure Bot Service — plus all the Microsoft channels (Teams · M365 Copilot · SharePoint · custom website · mobile). If your scenario is “I want one agent across many channels including non-Microsoft ones,” this is the only path that gets you there without writing channel adapters yourself. ⚠️ Some Azure Bot Service channels (notably Cortana — the consumer surface retired in 2023) are still listed in the docs but not viable production targets — verify each channel’s current status before scoping.
  2. The model picker. Currently GA models include the default GPT-4.1 plus GPT-5, Claude Sonnet 4.5, Claude Sonnet 4.6, and Claude Opus 4.6 (per the March 2026 What’s New). Few low-code platforms let you pick across vendors. Worth knowing if your tenant or org has a model preference.
  3. The connector library. 600+ Power Platform premium connectors (separate licence) plus built-in Microsoft Graph connectors plus custom REST/OpenAPI plus MCP (client GA since August 2025). The “I need to talk to Workday/SAP/Salesforce/ServiceNow” path is shortest here.
  4. Managed infrastructure. Microsoft hosts everything. You don’t stand up Azure App Service or wire Azure Bot Service or pay for Foundry deployments. The trade is Copilot Credits billing.

Declarative Agents#

  1. Zero hosting cost. The M365 Copilot orchestrator runs your agent. Microsoft’s foundation models do the inference. Your only artefacts are a manifest, optional API plugin OpenAPI specs, and a Teams app package. Operationally this is the cheapest path to ship something that uses M365 data + foundation models.
  2. Inherits everything M365 Copilot already does. Data Loss Prevention, sensitivity labels, customer Lockbox, Responsible AI policies, the compliance posture your tenant already trusts — your declarative agent inherits it because it IS the M365 Copilot orchestrator running with your overrides. You don’t reimplement compliance.
  3. The v1.7 manifest is genuinely capable. Web search · OneDrive/SharePoint · Copilot connectors · Graphic art · Code interpreter · Embedded knowledge (local files, since v1.6) · API plugin actions (1-10 per agent) · worker agents (agent-to-agent delegation, also v1.6 onwards). Plus the M365 surface tools — email, people, meetings, scenario models. For “M365 productivity helper” scenarios, this covers most of what you’d want.
  4. AppSource publishing for ISVs. Package the manifest as a Teams app; publish through Teams Developer Portal to the Microsoft commercial store. Discoverable inside Copilot Chat for tenants that allow it.

Custom Engine Agents#

  1. You choose the orchestrator. Semantic Kernel, LangChain, Azure Bot Service, or your own. Useful when the agent shape doesn’t fit M365 Copilot’s orchestrator — for example, agents that need to run in Teams meetings, support proactive messaging (agent-initiated, no user prompt), or use a non-Microsoft model you can’t get through Foundry.
  2. End users don’t need an M365 Copilot licence. Per the cost-considerations page, Custom Engine Agents in M365 Copilot Chat are available to unlicensed users. Copilot Credits apply if the agent touches shared tenant data, but the licence requirement that gates declarative agents doesn’t apply here. This is the under-known fact that often decides “DA or CEA?” for scenarios with a mix of licensed and unlicensed users.
  3. External channels + proactive flows + A2A. Same Azure Bot Service channel surface that Copilot Studio uses (Slack/Twilio/Line/Telegram + others; Cortana is listed but the consumer surface retired in 2023), plus proactive messaging (Azure Bot Service initiates), plus agent-to-agent collaboration. Declarative agents have worker agents (also A2A) but stay inside M365 channels.
  4. Pro-code authoring. If your team writes C# or Python and lives in VS Code, the M365 Agents Toolkit + Agents SDK gives you the same workflow you’d have for any modern web service — git, tests, CI/CD, real source control. Lower lock-in than the SaaS authoring shapes.

Where each lags#

Copilot Studio#

  • Capacity is metered. Copilot Credits replaced the per-message model on September 1, 2025. You buy capacity (prepaid sub, pay-as-you-go via Azure, or prepurchase plan), and standalone agent usage burns credits. If you’re not careful, a popular agent gets expensive. (M365 Copilot–licensed users have zero-rated usage for agents in Teams/SharePoint/Copilot Chat — that takes the edge off if your audience already has M365 Copilot.)
  • Power Platform dependency. Agents are Power Platform solutions, managed in Power Platform environments. If your org doesn’t have a Power Platform governance model, you’ll need to set one up.
  • Authoring lock-in. Standalone Copilot Studio agents don’t trivially port out. If you outgrow the platform, the path forward is rebuilding as a Custom Engine Agent — not a clean migration.

Declarative Agents#

  • End-user licence wall. Per the v1.7 manifest docs: users can only access DAs with capabilities beyond web-search-only IF their tenant allows metered pay-as-you-go OR they have an M365 Copilot licence. If your scenario is for unlicensed users, this is a wall.
  • M365 channels only. No WhatsApp, no website embeds, no custom channels. If your agent needs to live anywhere outside the M365 surface, this isn’t the path.
  • No custom orchestration. You can’t change how planning works, how tool calls are ordered, how memory persists. Microsoft owns the runtime; you own the manifest. Fine for “M365 productivity assistant” jobs, frustrating if your scenario needs specific orchestration behaviour.

Custom Engine Agents#

  • You operate everything. Microsoft Foundry costs (model + orchestration), Azure App Service (or equivalent), Azure Bot Service (channel routing), monitoring, scaling, patches. Of the three, this is the path with the highest operational floor.
  • Compliance is on you. M365 Copilot’s DLP/sensitivity/RAI inheritance doesn’t extend to your custom orchestrator. You implement the data-handling guarantees yourself or via Foundry’s guardrails.
  • Longer ship time. Even the Foundry-agent-to-M365 ATK template, which is the shortest custom-engine path, takes longer than declarative authoring — because you’re shipping a service, not a manifest.

Decision sketch#

Does the scenario need to reach a non-Microsoft channel (WhatsApp · website · Slack · etc.)?
  ├─ Yes → Copilot Studio (or Custom Engine Agent if you need full control)
  └─ No → continue
       │
       Do unlicensed users need to access this agent?
         ├─ Yes → Custom Engine Agent (no end-user M365 Copilot licence required)
         └─ No → continue
              │
              Does the agent need custom orchestration / non-Microsoft model / proactive messaging?
                ├─ Yes → Custom Engine Agent (BYO orchestrator)
                └─ No → continue
                     │
                     Is the team comfortable with a graphical maker portal?
                       ├─ Yes → Copilot Studio (low-code; see overlap section for which runtime)
                       └─ No → Declarative Agent via ATK (pro-code, manifest-shaped)

How the three paths overlap#

The biggest source of confusion is that Copilot Studio can produce either path’s artefacts.

  • “Standalone agent” in Copilot Studio → runs on Copilot Studio’s orchestrator → matches Microsoft’s Custom engine agent taxonomy.
  • “Agent for Microsoft 365 Copilot” in Copilot Studio → produces a declarative-agent-shaped artefact → matches Declarative agent taxonomy.

So when someone says “we built it in Copilot Studio,” ask the follow-up: standalone agent or agent-for-M365-Copilot? The runtime is different even though the authoring tool is the same.

The other overlap: ATK can produce both. ATK has templates for declarative agents (manifest-only) and templates for custom engine agents (a full M365 Agents SDK service with a manifest that wraps it). The same VS Code tool produces both.

What we are NOT claiming#

  • Specific pricing in dollars. Copilot Studio Credits, M365 Copilot licence prices, and Azure Foundry deployment costs all vary by region, agreement type, and tier. Use the billing-licensing page and the Azure pricing calculator for current numbers. We avoid putting specific dollar amounts here because they’ll be stale within a quarter.
  • That one path is “better.” All three exist because the scenarios genuinely differ. The decision sketch above asks the right questions; the answers depend on YOUR scenario.
  • What Microsoft will ship next. ATK ships monthly. Copilot Studio ships features into “What’s new” almost weekly. The manifest schema versions (v1.5 → v1.6 → v1.7) keep moving. Verify against current docs at decision time.

Honest take#

If you’re Sush — Microsoft SE, customer scenarios are typically M365-Copilot-licensed enterprises wanting to add agents to their existing M365 stack — Declarative Agents are the default. Cheapest to ship, inherits all the compliance customers already trust, the v1.7 manifest covers most “M365 productivity helper” jobs without writing a line of code.

When the customer wants Teams + WhatsApp + a customer-facing website all served by the same agent identity — Copilot Studio. The channel breadth is the headline feature. Pay for it in Copilot Credits operational cost; gain it in shipped scope.

When the customer wants something Copilot Studio can’t model — non-Microsoft orchestrator, agents in Teams meetings, proactive messaging, agents available to unlicensed users without buying everyone M365 Copilot — Custom Engine Agent via ATK. Highest operational floor, highest ceiling.

The trap most people fall into: shipping a Custom Engine Agent because “we want full control,” then operating it forever. Most M365 scenarios don’t need that control; the managed orchestrator is genuinely the right shape. Resist the developer instinct to over-engineer when a manifest would do.

Sources

See also

Related entries