Microsoft 365 Copilot agent types compared (declarative, Studio, Toolkit, and SDK)
A practical map of Microsoft 365 Copilot agent types, how you deploy them (including across customer tenants if you are an MSP), and when to pick each one, as of August 2026. Spoiler from my own delivery work: Copilot Studio declarative agents (agents for Microsoft 365 Copilot) are the path I enjoy building most for customers. The Studio tool and knowledge surface is wide enough for real work, and you still stay on Copilot’s orchestrator.
Microsoft documents two approaches (declarative vs custom engine). Everything else is a builder, runtime, or legacy name. Confusing those three is why “classic agent,” “Copilot Studio declarative,” and “Agents Toolkit” feel like four different products fighting in a trench coat.
Freshness warning. Licensing meters, model catalogues, and admin blades move monthly. Treat list prices and GA badges as “as of August 2026” and re-check Microsoft Learn before you buy capacity. Full research notes (with citations) live in the repo under
research/.Hover tip: dotted underlined terms (for example DA, CEA, GA, MCP) show a short definition on hover.
The only split that matters
| Declarative agents | Custom engine agents | |
|---|---|---|
| Orchestrator and models | Microsoft 365 Copilot’s | Yours, or Copilot Studio’s |
| Hosting | Microsoft 365 (no extra host) | Studio-managed or Azure / Foundry / your service |
| Proactive / triggers | No (user-initiated) | Yes |
| Best for | Scoped M365 Q&A and actions | Complex workflows, multi-channel, custom models |
Test question: whose orchestrator is running?
- If the answer is Microsoft 365 Copilot’s, it is a declarative agent (SharePoint agents, Agent Builder, Agents Toolkit declarative packages, or Copilot Studio’s “agent for Microsoft 365 Copilot”).
- If the answer is Copilot Studio’s (generative or classic custom agent), it is a custom engine agent, even when you only configure topics and tools in a low-code UI.
- If the answer is yours (Agents SDK / Foundry / Agent Framework), that is also a custom engine agent.
That is why a normal “Copilot Studio generative/classic custom agent” is not a declarative agent. Generative orchestration means Studio’s planner picks topics and tools. It does not mean the agent was loaded as configuration into Copilot’s orchestrator. Low-code is not the same as declarative in Microsoft’s taxonomy.
Copilot Studio also has a separate entry point (Agents → Microsoft 365 Copilot → Add) that creates an agent for Microsoft 365 Copilot. Learn explicitly calls that a declarative agent. Same portal, different starting point, different runtime class.
Builders for declarative: SharePoint agents, Agent Builder, Agents Toolkit, Copilot Studio (declarative / M365 Copilot agent).
Builders for custom engines: Copilot Studio (custom agent, generative or classic), Agents Toolkit + Agents SDK, Teams SDK, Foundry Agent Service.
“Classic agent” means at least three things
- Classic PVA bots (clone into Copilot Studio).
- Classic orchestration in Studio (trigger phrases) versus generative orchestration (default for new agents), and separately the classic versus new authoring experience (preview; no migration either way).
- The old standalone plugin path. Plugins are now only actions inside declarative agents.
If someone says “don’t use a classic agent,” ask which of those they mean. For large MCP tool surfaces (for example CIPP), prefer a declarative path (Agent Builder, Agents Toolkit, or Copilot Studio declarative) over a Studio custom-agent import that hits tool ceilings. See CIPP with Copilot Studio as a declarative agent (MCP).
Headline comparison
| Type | Build skill | Orchestrator | Extra host? | Marketplace | Reach for it when… |
|---|---|---|---|---|---|
| SharePoint agent | End user | Copilot | No | No | Site/library Q&A in minutes |
| Agent Builder | Maker | Copilot | No | No | Personal / small-team knowledge bots |
| Declarative + Agents Toolkit | Pro-code | Copilot (DA) | No | Yes | APIs/MCP, source control, AppSource |
| Copilot Studio (declarative) | Low-code | Copilot (DA) | No extra host | No Marketplace; org catalogue / share | Studio-authored DA with connectors/tools; makers already in Studio |
| Copilot Studio (generative custom) | Low-code | Studio generative (CEA) | Managed | Custom agents yes; multi-tenant preview | Connectors, workflows, autonomy, WhatsApp/web |
| Copilot Studio (classic custom) | Low-code | Studio classic (CEA) | Managed | Same Studio publish paths | Scripted / regulated dialogs; PVA migration |
| Agents SDK + Toolkit | Pro-code | BYO | Yes (Azure) | Yes | Full control, multi-channel, custom models |
| Foundry Agent Service | Pro / platform | Foundry / BYO | Foundry | Via Toolkit | Azure-native RAG and multi-model |
| Cowork | End user + | Microsoft | No | N/A | Multi-step M365 work with approvals (GA Jun 2026) |
Not greenfield defaults: classic PVA, classic Studio orchestration (unless you need hard scripts), and the Bot Framework SDK (support tickets ended 31 Dec 2025; migrate new work to Agents SDK / Teams SDK / Studio).
Feature matrices
Legend: Yes · No · Limited · Partial (works with caveats). Columns are the specialist build and deploy paths most people actually choose.
Head-to-head: three declarative and Studio paths
The comparison that matters once you leave Agent Builder. Same Copilot orchestrator for the first two columns; Studio custom is a different runtime class.
| Feature | Agents Toolkit declarative | Studio declarative (M365 Copilot agent) | Studio custom agent |
|---|---|---|---|
| Orchestrator | Copilot (DA) | Copilot (DA) | Studio (CEA) |
| Authoring | Manifest / VS Code | Studio portal (M365 Copilot page) | Studio portal (custom agent) |
| Power Platform connectors | No (OpenAPI / MCP) | Yes | Yes |
| MCP / REST / prompts / flows | Yes (as DA plugins) | Yes (Studio tool picker) | Yes |
| Computer Use (CUA) | No (custom tooling) | Yes (Credits; not in USL inclusion) | Yes (same Credits caveat) |
| Topics / child agents / autonomy | No | No (sequential DA runtime) | Yes |
| External channels (WhatsApp / web bots) | No | No (M365 / Teams hosts) | Yes |
| Source control / CI/CD | Strong (git) | Limited (catalogue / ZIP / share) | Limited (solutions / pipelines) |
| Commercial Marketplace | Yes | No | Custom yes; multi-tenant preview |
| Instruction budget | ≤8k consolidated | ≤8k consolidated | Lower if split topics / children |
| Studio Analytics page | N/A | No (Learn tip) | Yes |
Parity note: Agents Toolkit still unlocks the fullest manifest surface (for example editorial answers, worker agents, some capability flags in schema v1.8). Studio declarative wins on maker-friendly connectors and tool authoring. Studio custom wins when you need Studio’s own planner, channels, or autonomy.
Authoring and orchestration
| Feature | SharePoint | Agent Builder | DA + Toolkit | Studio declarative | Studio custom | Agents SDK + Toolkit | Foundry | Cowork |
|---|---|---|---|---|---|---|---|---|
| Natural-language / no-code create | Yes | Yes | No | Partial | Partial | No | Partial | Yes |
| Visual designer / topic canvas | No | Limited | No | Limited (overview / tools) | Yes | No | Limited | No |
| Instructions / system prompt | Limited | Yes | Yes | Yes | Yes | Yes (your code) | Yes | Custom skills + chat |
| Topics / scripted conversation flows | No | No | No | No | Yes | Custom | Custom | No |
| Generative / LLM orchestration | Copilot | Copilot | Copilot (DA) | Copilot (DA) | Studio generative (default) | BYO | Foundry / BYO | Microsoft agentic runtime |
| Classic trigger-phrase routing | No | No | No | No | Yes (toggle) | Custom | Custom | No |
| Model picker (Claude / GPT-5.x / …) | No | No | No | No (Copilot models) | Yes (admin-gated) | Yes | Yes | Yes |
| Proactive / event triggers | No | No | No | No | Yes | Yes | Yes | Scheduled / event |
| Multi-agent / child agents / A2A | No | No | No | No | Child Yes; external A2A preview | Yes | A2A preview | Skills composition |
Tools, knowledge, and extensibility
| Feature | SharePoint | Agent Builder | DA + Toolkit | Studio declarative | Studio custom | Agents SDK | Foundry | Cowork |
|---|---|---|---|---|---|---|---|---|
| SharePoint / OneDrive knowledge | Scoped (≤20) | Yes | Yes | Yes | Yes | Via Graph / Retrieval API (preview) | Via connectors | Yes |
| Copilot / Graph connectors | No | Limited | Yes | Yes | Yes | Via APIs | Via connectors | Plugins |
| Public web / scoped web | Limited | Yes (≤4 sites) | Yes | Yes | Yes | Custom | Custom | Yes |
| Code interpreter / image gen | No | Capability flags | Capability flags | Limited | Partial / tools | Custom | Yes | Built-in skills |
| OpenAPI / REST actions | No | Limited | Yes (≤10 plugins) | Yes | Yes | Custom | Yes | Plugins |
| MCP tools | No | No | Yes | Yes | Yes | Custom | Partial / Yes | N/A |
| Power Platform connectors | No | No | No | Yes | Yes | No (custom) | No | No |
| Computer Use (CUA) | No | No | No | Yes (Credits; not in USL inclusion) | Yes (same) | Custom | Custom | No |
Modularity: tools, topics, and instruction packing
This is where Studio custom topics / child agents, Cowork custom skills, and Toolkit declarative agents feel most different. The question is less “who has MCP?” and more how behaviour is chunked. (Here “skills” means Cowork SKILL.md units or legacy Bot Framework skills, not “Studio has lots of tools.”)
| Capability | Studio custom (topics / child agents) | Studio / Agents Toolkit declarative | Cowork custom skills | Agents SDK / Foundry |
|---|---|---|---|---|
| Separate modular units | Yes (topics; Bot Framework skills ≤100; child agents) | Limited: one agent; modularity via plugins + instruction sections | Yes (SKILL.md units, ≤50) | Yes (your modules / agents) |
| Name + description routing metadata | Yes (generative orch. picks by description) | Limited: plugin / tool descriptions; core behaviour in instructions | Yes (skill frontmatter) | Yes (your router) |
| Full instructions loaded only when needed | Partial: topics/tools selected on demand | No: core instructions normally consolidated (≤8k) | Yes: skills discovered / loaded as needed | Yes if you design it |
| Git / source-control friendly | Limited (solutions / export) | Agents Toolkit strong; Studio DA limited (ZIP / catalogue) | Partial (OneDrive SKILL.md folders) | Yes |
| MCP / API actions | Yes | Yes | Via plugins | Custom |
| Single-agent instruction-limit pressure | Lower when split across topics / children | Higher: one instruction surface | Lower: skills on demand | You control |
| Visual authoring / orchestration | Yes | Studio DA: overview UI; Agents Toolkit: code | Limited (UI + chat-built skills) | No (code / Foundry UX) |
| Studio topic canvas / flows | Yes | No | No | No |
Practical takeaway: if you are hitting the 8,000-character instruction wall or a giant MCP tool list on a declarative path, thin the agent and push complexity into well-described plugins (soft quality cliff >10 tools per plugin), or move to Studio custom topics/child agents / Cowork skills when you truly need modular orchestration.
Capability snapshot (surfaces and ops)
| Capability | SharePoint | Agent Builder | DA + Toolkit | Studio declarative | Studio custom | Agents SDK |
|---|---|---|---|---|---|---|
| Teams Chat as primary UX | Limited | No (known limit) | Yes* | Yes* | Yes | Yes |
| M365 Copilot Chat surface | Yes | Yes | Yes | Yes | Yes | Yes |
| External channels (web / WhatsApp / …) | No | No | No | No | Yes | Yes |
| Strong ALM / CI/CD | No | No | Yes | Limited (ZIP / catalogue)* | Solutions* | Yes |
| Org catalogue / Agent Store | Limited | Share / Store path | Yes | Yes (after publish) | Yes | Yes |
| Commercial Marketplace | No | No | Yes | No | Custom Yes; multi-tenant preview | Yes |
| Inherits M365 Copilot compliance | High | High | High | High | High* | You own more |
| Multi-tenant / partner distribute | No | No | Package / store | Per-tenant ZIP / catalogue | Per-tenant solution; host preview | Package + host |
| Studio Analytics page | N/A | N/A | N/A | No | Yes | N/A |
*Power Platform pipelines are same-tenant only. Cross-tenant fleets need Azure DevOps / GitHub Actions (see deployment below).
*DA + Toolkit / Studio declarative Teams Chat: when published / packaged for Teams or Copilot, not the same as Agent Builder.
*Studio custom compliance: high when authenticated; anonymous / no-auth publish is a known risk.
*Agents SDK Graph grounding via Microsoft 365 Copilot Retrieval API is Preview.
Hard limits worth memorising
| Limit | Value | Applies to |
|---|---|---|
| Instructions | ≤ 8,000 chars | Declarative / Studio Copilot agents |
| DA plugins | 1–10 (actions) | Declarative agents |
| Soft quality cliff | >10 tools per plugin | Declarative plugins |
| Grounding / plugin response / timeout | 50 records · 25 items · ~45s | Declarative runtime |
| Studio tools (generative) | Max 128; recommend 25–30 | Copilot Studio |
| SharePoint agent sources | ≤ 20 | SharePoint agents |
Business Central docs also mention a Studio 70-tool MCP client limit; Studio’s own docs say 128. Treat 70 versus 128 as unresolved cross-doc noise, and design under the lower number if you are importing huge MCP surfaces.
Deployment, governance, and multi-tenant reality
Getting an agent into users’ hands is half the product decision. The other half is whether you are shipping into one tenant or repeating that design across many customer tenants.
Government / GCC note. Builder availability differs by cloud (for example some DoD paths are Toolkit-only; Studio multi-tenant preview calls out GCC gaps). Verify the customer’s cloud before promising Studio declarative as the delivery vehicle.
Single-tenant paths
- Share with specific users or the organisation: Agent Builder and Studio (declarative availability options after publish).
- Sideload or download a ZIP: Toolkit packages, and Studio declarative “download as .zip” for admin catalogue upload. Teams “upload custom apps” policy still matters.
- Org catalogue / Agent Store: after admin approval. Store validation SLOs apply; channel agents need app manifest ≥ 1.25 for new Teams Store submissions from July 2026 (already in force for new channel-enabled submissions).
- Commercial Marketplace: Toolkit declarative and custom engine; Studio custom agents (hosted multi-tenant is preview). Agent Builder and Studio declarative listings are not Marketplace paths.
- Governance stack: Copilot Control System (framework), Agent 365 (GA May 2026), Entra Agent ID (platform GA; some create wizards still preview), Purview audit/DLP/eDiscovery matrices. Reach for Agent 365 / Entra Agent ID when agents need first-class identity, Conditional Access, or estate-wide inventory, not only for chatbots inside Copilot.
What you actually ship (ALM artefacts)
| Path | Typical artefact | MSP fleet note |
|---|---|---|
| Studio declarative | Publish → share link / security groups / org catalogue submit / download ZIP | Repeat per customer tenant. This is catalogue/app packaging, not the same as a Power Platform managed-solution promote. |
| Studio custom | Dataverse managed solution ZIP | Per-tenant import; map connections and environment variables. Pipelines stay same-tenant. |
| Agents Toolkit declarative / CEA | M365 app package (git + CI/CD) | Best when you need repeatable product packaging or Marketplace. |
Partners and multi-tenant (MSP) deployment
If you run Microsoft 365 for many customers, treat multi-tenant as a first-class constraint, not a footnote. The agent type you pick often decides whether you can productise once or must land a package in every tenant.
| Pattern | What it is | When it fits | Watch-outs |
|---|---|---|---|
| Per-tenant Studio declarative | Same agent design published (or ZIP-uploaded) into each customer tenant’s catalogue / availability options | Customer M365 Copilot agents with connectors / MCP / Graph knowledge; my usual customer build | Needs Copilot licence + Studio maker access per tenant. No Studio Analytics. Prefer user auth on tools that touch customer data. |
| Per-tenant managed solution (Studio custom) | Managed solution ZIP imported into each customer’s Power Platform environment | Autonomy, external channels, topic canvas, customer-billed Credits for CEA workloads | Pipelines do not cross tenants. Automate with Azure DevOps / GitHub Actions. |
| Hosted Studio multi-tenant (preview) | One agent in the partner host tenant; customers install a package that calls it | FAQ / public-knowledge agents that do not need end-user auth to customer Graph | Host-billed; transcripts off; many features blocked in preview (including several knowledge and MCP scenarios). |
| Toolkit package / Marketplace | One M365 app package distributed via org catalogue or Partner Center | Productised agents; partner-hosted Azure backends for CEAs | Studio declarative and Agent Builder are not Marketplace offerings. |
| Per-tenant licensing economics | Customer pays USL, Credit packs, and/or PAYG in their tenant | Managed-service agents grounded on tenant data | Multiplexing does not reduce licences. Graph grounding alone is 10 Credits. Unused packs do not roll over. |
GDAP helps you administer customer tenants. It does not invent cross-tenant Power Platform pipelines, and it does not replace per-tenant DLP, capacity, or catalogue approval. For Graph-aware customer agents, the practical default remains: design once, land per customer tenant (Studio declarative ZIP/catalogue, managed solution, or Toolkit package), with automation where the fleet justifies it.
Secure by default (customer agents)
- Prefer user authentication on connectors and tools that read or write customer Graph / line-of-business data; maker auth is a multiplexing and over-privilege risk.
- Put connectors in the right DLP groups before wide share; treat prompt injection via email/ticket knowledge as a real threat (Learn calls this out for Copilot-extending agents).
- Avoid anonymous / no-auth publish for Studio custom agents.
- Publish Studio declarative deliberately (availability options), then have an admin approve catalogue installs.
- Bring Entra Agent ID / Agent 365 in when the agent needs governed identity beyond “runs as the chatting user.”
How you measure Studio declarative success
These agents do not feed the Copilot Studio Analytics page. Plan measurement up front: qualitative UAT in real Copilot Chat (not only the Studio test panel), M365 / Agents admin inventory, Purview audit where enabled, and Agent 365 if the estate is on that control plane. Thumbs-down feedback in Copilot goes to Microsoft, not into your Studio dashboards.
Cost in one screen
List prices below are USD marketing figures (Aug 2026). Customer invoices usually land in local currency; re-check Microsoft’s price lists for GBP and other markets before you quote.
| Construct | Rule of thumb (USD, Aug 2026) |
|---|---|
| Copilot Chat | Included; web-grounded free; work/agent often metered |
| Copilot USL (Enterprise) | $30/user/month (yearly) |
| Credit pack | $200/mo → 25,000 credits; no rollover |
| PAYG | $0.01 per Copilot Credit |
| Feature stack (metered) | Classic 1 · Generative 2 · Action 5 · Graph grounding 10 · … |
| USL + internal Studio (B2E) | Often zero-rated for listed features; fair usage; Computer Use not included |
| Studio declarative (M365 Copilot agent) | Needs Copilot licence for makers/users; Graph grounding and actions still follow Credits rules when metered; CUA = 5/step standard or 15/step premium |
| Studio custom external channels | Standalone Studio / Credits (not “included with USL chat only”) |
Budgeting trap: one Graph-grounded generative reply is about 12 credits (10+2), not 1. Prepaid capacity can disable agents around 125% overage. Prefer Microsoft’s June 2026 Copilot Credits / Studio licensing guides over marketing “unlimited” wording.
Each agent type in practice
The tables above are for scanning. This section is the same decision material with more room to breathe: what each path is for, where it shines, and when to leave it.
SharePoint agents
SharePoint agents are the thinnest declarative option. An end user (with the right licence or PAYG) points an agent at up to 20 sites, libraries, folders, or files, and asks questions that stay permission-trimmed to what they can already see.
Where it wins: minutes-to-value document Q&A on a known library; no Studio environment, no pro-code, no packaging ceremony.
Where it falls short: no Lists, no Site Pages library pages as sources, no rich actions or connectors, and almost no ALM. PAYG is easy to misread: a successful interaction is counted as 12 messages at the $0.01 framing.
Reach for it when you only need “ask this site/library.” Move on when you need organisation-wide instructions, APIs, workflows, Marketplace distribution, or Teams Chat as the primary surface.
Agent Builder (in Microsoft 365 Copilot)
Agent Builder is the lightweight maker path inside Copilot Chat. You describe an agent in natural language (or use Configure / templates), attach SharePoint / OneDrive / web knowledge, and share it with yourself, named people, or the organisation. It still runs as a declarative agent on Copilot’s orchestrator.
Where it wins: lowest friction for personal and small-team knowledge bots; inherits Copilot security and compliance; there is an official copy to Copilot Studio path when you outgrow it.
Where it falls short: no Power Platform connectors and only limited external actions; known limitation that these agents cannot be used in Teams Chat; weak ALM and no Commercial Marketplace. Mid-project jumps to Studio for CRM write-backs or approvals are a common pain point in the field.
Reach for it when a small team needs Graph-grounded Q&A without standing up Studio. Move on when you need Teams Chat as primary UX, connectors, autonomy, git-based packaging, or AppSource.
Declarative agents via Agents Toolkit
This is the pro-code packaging of the same declarative model: JSON/YAML manifests, API plugins, MCP, Adaptive Cards, sideload or store submit, scaffolded with Agents Toolkit (VS Code / Visual Studio / atk CLI). Hosting stays in Microsoft 365; you do not bring an orchestrator.
Where it wins: real source control and CI/CD; Agents Playground for local testing; full declarative capability surface (manifest v1.8 family); eligible for Commercial Marketplace / AppSource; same Copilot compliance inheritance as Agent Builder. For partners, this is the cleanest path to a productised declarative package across tenants.
Where it falls short: needs developer skills; no drag-and-drop Power Platform connectors (use OpenAPI / MCP instead); runtime envelopes bite large tool surfaces (grounding 50 records, plugin response 25, about 45s timeout, 1–10 plugins, soft quality cliff >10 tools per plugin). Instruction text is normally one consolidated blob (≤8,000 chars), so modularity is weaker than Studio topics or Cowork skills.
Reach for it when you are productising a declarative agent with APIs/MCP, need git, or want AppSource. Move on when you need autonomy, external channels (WhatsApp/web bots), iterative multi-step orchestration you control, or custom models. If you want a declarative agent but prefer the Studio portal over VS Code, use Copilot Studio (declarative) instead.
Copilot Studio (declarative: agent for Microsoft 365 Copilot)
This is the missing middle that causes most of the naming fights, and it is the path I personally like building most for customer work. In Copilot Studio you start from Agents → Microsoft 365 Copilot → Add. Learn’s wording: an “agent for Microsoft 365 Copilot” is equivalent to a declarative agent created in Microsoft 365 Copilot. It extends Copilot with instructions, knowledge (SharePoint, Graph connectors, web browsing), and tools. Learn’s create-new tool list for this path includes prompts, agent flows, Computer Use, custom connectors, MCP, and REST.
It is not the same object as a Studio custom agent (generative or classic). Official differences that matter in practice:
- Different starting point in the portal (Microsoft 365 Copilot page versus create-custom-agent).
- It does not appear in the main Studio agents list with custom agents.
- On publish it is ready for availability options (share link, teammates / groups, org catalogue submit, download ZIP). Unlike a standalone custom agent, it is not automatically deployed to Microsoft 365 Copilot and Teams just because you published.
- Publishing provisions a bot resource in the tenant’s Microsoft Entra ID so users can talk to the agent in Teams.
- Tips from Learn: these Copilot agents do not collect data for the Copilot Studio Analytics page; runtime answers in Copilot can differ from the Studio test panel.
Where it wins: the broadest low-code tool and knowledge surface I still trust on Copilot’s orchestrator. In one Studio authoring experience you can combine instructions, SharePoint / Graph connector / web knowledge, and connectors / REST / MCP / prompts / flows / Computer Use, then land the agent in Microsoft 365 Copilot and Teams. That mix is why it is my favourite customer-delivery path: maker-friendly authoring, tenant Graph and connector reach, and Copilot compliance inheritance, without jumping straight to a custom-engine host. It is also the Studio path that matches guides such as the CIPP MCP declarative wiring.
What still bites (same declarative runtime): sequential Copilot orchestration is a poor fit for long multi-step loops you control yourself. You still live with instruction pressure (≤8,000 chars), plugin/tool ceilings on the declarative envelope (1–10 plugins; soft quality cliff >10 tools per plugin), grounding / response / timeout envelopes (50 / 25 / ~45s), and no Studio Analytics. Computer Use is available here per Learn, but it burns Credits (5/step standard, 15/step premium) and is not part of USL fair-usage inclusion. Huge MCP surfaces still need careful packaging (see the CIPP post).
Where it falls short versus other builders: not a substitute for Studio custom agents when you need full multi-channel CEA behaviour, classic topic canvases, or autonomy; not as git-native as Agents Toolkit; Commercial Marketplace is the Toolkit/custom-engine story, not this path; requires Copilot licence plus Studio environment permissions for makers. Agents Toolkit can still expose manifest capabilities the Studio UI does not surface as neatly (editorial answers, worker agents, and other schema v1.8 flags).
Reach for it when you are building agents for customers (or your own tenant) that live in M365 Copilot / Teams and need more than Agent Builder can express. Use Agent Builder instead when you only need a quick personal/small-team Q&A bot. Use Agents Toolkit declarative when you need source control and AppSource. Use Studio generative/classic custom agents when you need Studio’s own orchestrator, external channels, or CEA-class autonomy.
Copilot Studio (generative custom agent)
Full Copilot Studio custom agents on copilotstudio.microsoft.com are the low-code custom engine platform, not a declarative agent. You create them as standalone custom agents (not via the Microsoft 365 Copilot agents card). New agents default to generative orchestration: Studio’s orchestrator (planner) picks topics, tools, knowledge, and child agents from descriptions. You get Power Platform connectors, agent flows, REST, MCP, Computer Use (CUA), multi-channel publish, solutions/DLP, and (for licensed B2E users) often zero-rated listed features under fair usage.
It feels declarative because you mostly configure rather than write C#, but the taxonomy test fails: the runtime is Copilot Studio’s engine (hosted in Power Platform / Dataverse), with Credits, channels, and autonomy that declarative Copilot agents do not have. Microsoft’s own custom-engine overview lists Copilot Studio as a first-class CEA builder alongside Agents SDK and Foundry.
Where it wins: departmental workflows, CRM/ERP actions, approvals, WhatsApp/web channels, autonomy and event triggers, model picker (GPT-family plus admin-gated Claude and others), child agents to split tool budgets (max 128 tools under generative orchestration; Microsoft recommends 25–30). For MSPs, this is usually the per-tenant managed-solution path when customer Graph and connectors matter.
Where it falls short: Copilot Credits are feature-stacked (tenant Graph grounding alone is 10 credits); prepaid capacity can disable agents around 125% overage; external channels need standalone Studio/credits; classic and new authoring experiences have no migration; anonymous publish is a security landmine. Some practitioners report different Graph retrieval depth versus Agent Builder / Toolkit declarative agents. Treat that as community colour, not Learn taxonomy.
Reach for it when you need connectors, multi-step automation, autonomy, or non-M365 channels without writing a hosted bot. Move on when you need a BYO orchestrator, Azure-native multi-model economics, or SDK-level control that Studio cannot express cleanly. Prefer generative over classic for most new Studio work unless you specifically need the classic behaviour below.
Copilot Studio classic custom agent
“Classic” in Studio is easy to misuse. It usually means one of three related things:
- Classic orchestration: topic selection by trigger phrases (NLU match) instead of the LLM picking topics/tools by description.
- Classic authoring experience: the topics / flows / nodes canvas (still GA), as opposed to the new agent experience (production-ready preview, instruction-first, enhanced orchestration for all agents, no migration either way).
- Classic PVA lineage: older Power Virtual Agents bots cloned into Copilot Studio unified authoring.
In practice, when people say “Copilot Studio classic agent” they mean a Studio agent on classic orchestration (often still on the classic topic canvas): tools run only when a topic explicitly calls them; knowledge is mainly a fallback; the agent tries to stay in a single matched topic rather than chaining many generative steps. Like generative Studio agents, this is still a custom engine agent. Classic versus generative is an orchestration mode inside Studio, not a flip into the declarative/Copilot-orchestrator family.
Where it wins: deterministic, auditable conversation paths for regulated or scripted processes; familiar to makers who built PVA bots; still supports Power Platform connectors, channels, and solutions ALM when you author those explicitly in topics; admins can force classic-only per environment if generative orchestration is disabled.
Where it falls short: not the greenfield default (new agents start on generative orchestration); weaker at open-ended “figure out which tools to call” behaviour; easy to confuse with declarative agents or with the separate “classic versus new authoring experience” split; creating new classic chatbots from the old Copilot Studio for Teams app path was redirected to the web app (June 2026), though existing agents keep working. Large MCP tool imports are a poor fit here compared with a declarative or generative path (see the CIPP note above).
Reach for it when you are migrating a classic PVA bot, need hard-scripted branching with predictable topic routing, or compliance prefers trigger-phrase determinism over generative tool choice. Move on when you want the LLM to select and chain tools/topics from descriptions, need autonomy/event-driven generative patterns as the primary design, or you are starting a net-new agent with no scripted-dialog requirement. Use Copilot Studio (generative custom) instead, or Studio declarative / Agents Toolkit if you mainly need M365 Copilot’s orchestrator.
Agents SDK + Agents Toolkit (custom engine)
Here you leave Copilot’s orchestrator. Agents SDK is the channel/conversation plumbing (C# / JS / Python). Pair it with Agent Framework, LangChain, or your own planner; scaffold and package with Agents Toolkit. App manifest ≥ 1.21. This is the clear successor path for new work that used to land on Bot Framework (support tickets ended 31 Dec 2025).
Where it wins: full control of models, tool loops, proactive messaging, and channels (Teams, web, SMS, email, and so on); Marketplace-eligible; fits Agent 365 / Entra Agent ID governance stories when you treat the agent as a first-class identity. Partners can ship one package and host Azure backends centrally where that model fits.
Where it falls short: you own hosting, responsible AI, security, and Azure cost; highest skill and ops floor. If a declarative or Studio agent would meet the need, this path is overkill.
Reach for it when you need complex multi-step loops, custom models, non-M365 channels, or to modernise an existing bot estate. Prefer Teams SDK only when the experience is Teams-collaborative and you do not need multi-channel agent plumbing.
Foundry Agent Service
Foundry Agent Service is the Azure-managed agent platform (prompt agents and hosted agents) with a path to publish/share into Teams and M365 Copilot. Strong when the centre of gravity is already Azure RAG, model routing, or Foundry tooling. A2A and some hosted features remain preview.
Where it wins: managed runtime, Foundry model catalogue, and prepaid Agent Commit plans that can span Studio + Foundry spend.
Where it falls short: Azure TCO (tokens, search, compute); easy to over-engineer a problem that Agent Builder or Studio would have solved.
Reach for it when you are building Azure-native agents and want M365 as a channel. Stay on Studio/DA when the workload is mostly M365 knowledge and Power Platform connectors.
Cowork (and first-party Microsoft agents)
Cowork is documented as an agentic system, not “another DIY agent type.” It runs multi-step work across mail, calendar, files, and Teams with human approval before sensitive actions, modular SKILL.md custom skills (≤50), and Copilot Credits billing (GA June 2026). Researcher and Analyst are separate first-party agents typically tied to the Copilot USL. They cover deep research and spreadsheet-heavy work, not something you rebuild in Toolkit.
Where it wins: outcome-driven “do the work” scenarios and skill-based modularity without standing up Studio topics.
Where it falls short: it is not a substitute for a custom MCP/connector agent you design and ship; Credits still apply; governance lives under the Cowork / Agents admin surfaces, not your ALM repo.
Reach for it when users need delegated multi-step M365 work with approvals. Use Researcher/Analyst when you want Microsoft’s deep-research or spreadsheet specialists (usually needs USL). Build your own agent when the differentiator is your tools, data, or packaging.
Quick chooser
| Need | Prefer |
|---|---|
| Customer M365 agent I would build first | Copilot Studio (declarative / M365 Copilot agent) |
| Customer has Copilot Chat only / no USL | SharePoint agent PAYG, or web-grounded Agent Builder; budget Credits before Graph tools |
| Minutes-to-value on a library | SharePoint agent |
| Small-team knowledge bot | Agent Builder |
| APIs, MCP, git, AppSource | Declarative + Agents Toolkit |
| Modular behaviour without one giant instruction blob | Studio custom topics/child agents, or Cowork custom skills |
| Connectors, approvals, WhatsApp/web, autonomy | Copilot Studio (generative custom agent) |
| Scripted / regulated topic flows; classic PVA migration | Copilot Studio (classic custom agent) |
| Graph-aware agent across many customer tenants | Per-tenant Studio declarative ZIP/catalogue or Toolkit package (not host multi-tenant preview alone) |
| Custom models / complex loops / non-M365 channels | Agents SDK (± Agent Framework / Foundry) |
| First-party deep research / spreadsheets | Researcher / Analyst (needs USL) — do not rebuild |
| Multi-step delegated M365 work with approvals | Cowork — do not rebuild as a DIY agent type |
Before you hand a Studio declarative agent to a customer
- Test in Microsoft 365 Copilot Chat (and Teams if that is the target), not only the Studio test panel.
- Exercise each tool with user auth; confirm connection consent and DLP allow the connectors.
- Check instruction length, tool count, and timeout behaviour under realistic prompts.
- Publish, set availability, and complete catalogue / admin approval in the customer tenant.
- Agree how you will measure success without Studio Analytics.
- Document Credits exposure (especially Graph grounding and Computer Use).
My recommendation for customer work
Copilot Studio declarative agents are my favourite path for customer delivery, and they are what I reach for first unless a hard requirement forces something else.
That preference comes from lived delivery, not from Microsoft ranking the builders. For most MSP and customer tenants, this path hits the sweet spot I care about: Copilot’s orchestrator and compliance model, plus Studio’s wide tool and knowledge authoring (connectors, MCP, REST, prompts, flows, Computer Use, Graph-aware knowledge). You can ship useful agents without standing up a custom engine, WhatsApp/web channels, or an Azure-hosted bot.
Be honest about the ceiling: you are still on the declarative runtime. If you need long autonomous loops, external channels, or git-native AppSource packaging, switch deliberately to Studio custom, Agents Toolkit, or the Agents SDK. Agent Builder remains fine for throwaway personal bots; first-party Researcher, Analyst, and Cowork should be reused rather than rebuilt.
The rest of this post is the map for those exceptions. The first place I still open for customer work is Agents → Microsoft 365 Copilot → Add in Copilot Studio.
Naming landmines (last 12 months)
- Teams Toolkit → Microsoft 365 Agents Toolkit; Teams AI Library → Teams SDK
- Studio “messages” → Copilot Credits (1 Sep 2025)
- “Copilot Studio lite” briefly → back to Agent Builder
- Inside Studio: agent for Microsoft 365 Copilot (declarative) is not the same as a custom agent (generative/classic CEA)
- Agent Framework 1.0 (orchestration) is not Agents SDK (channels) and not Agent 365 (governance licence)
- Field talk of “Sydney versus Samba” orchestrators is community, not Learn: useful colour, not official taxonomy
Further reading
- Agents for Microsoft 365 Copilot
- Choose Agent Builder vs Copilot Studio
- Extend Microsoft 365 Copilot with agents (Studio declarative vs custom)
- Licensing and cost considerations
- Copilot Studio billing rates
- Computer Use tool
- Copilot Studio multi-tenant overview (preview)
- Earlier post: CIPP with Copilot Studio as a declarative agent (MCP)