Custom engine agents: pick them only when Copilot's orchestrator cannot run the workflow
Custom engine agents for Microsoft 365 Copilot are the path where you bring your own orchestrator and models. Declarative agents inherit Copilot's model and security with no extra hosting. Pick custom engine when the workflow needs proactive actions, a domain model, or channels outside Microsoft 365 — and accept that RAI and hosting become yours.
The answer first
Declarative agent or custom engine agent — five criteria
| Criterion | Declarative agent | Custom engine agent |
|---|---|---|
| Who runs the model | Microsoft 365 Copilot's orchestrator and foundation models | You bring the orchestrator and choose the models |
| Hosting | Hosted in Microsoft 365 — no separate engine bill | Often Azure or another cloud outside Microsoft 365, unless you stay on managed Copilot Studio |
| Compliance and RAI | Inherits Microsoft 365 standards | You must ensure your own compliance, RAI and security for what you bring |
| Proactive behaviour | Not supported — user-initiated only | Can trigger actions without a user prompt |
| Best fit | Focused work inside Microsoft 365 apps | Complex workflows, domain models, group work in Teams, or channels outside Microsoft 365 |
Every cell is from Microsoft's Agents for Microsoft 365 Copilot overview, read 25 September 2026. Custom engine agents need app manifest 1.21 or later.
The word agent is doing three jobs in Microsoft's docs
Microsoft uses agent for everything from a SharePoint FAQ bot to a loan-approval system with three credit bureaux. The useful split is not the word. It is who owns the engine. A declarative agent configures Copilot: instructions, knowledge, actions — Copilot still decides the path. A custom engine agent replaces that engine with yours.
That is why the hosting and RAI rows in the table matter more than the feature list. Declarative keeps you inside a stack your CISO already accepted. Custom engine puts the reasoning loop, and often the model bill, on your side of the contract. Copilot Studio can still be the low-code shell for a custom engine agent; the Agents SDK and Foundry are the pro-code paths. The shell is not the decision. The engine is.
Microsoft is explicit that one app package cannot be both. The manifest holds either a declarative node or a customEngineAgents node. Converting later is possible; starting without the fork costs a second consent round for every user who already installed the declarative version.
Each path has a real strength
Three ways to ship a custom engine agent
Copilot Studio
Managed SaaS: templates, connectors, Power Platform compliance, no infrastructure project for the first agent.
Will the agent still fit when you need a model Studio does not host, or a channel Studio does not publish to?
Microsoft 365 Agents SDK
Full control of orchestration — Semantic Kernel, LangChain, any model — across Copilot, Teams and other channels.
Who owns the RAI evaluation, the hosting bill, and the store submission if you publish beyond the tenant?
Microsoft Foundry agent
Reuse an agent you already run in Foundry and surface it in Copilot and Teams via portal publish or Agents Toolkit.
Is the Foundry agent already governed, or are you about to expose a lab prototype to every licensed user?
Microsoft's own fork, stated as rules
One question decides the type
Start here
Does this workflow need Copilot's built-in orchestrator, or does it need a reasoning loop you control?
- Knowledge and actions stay inside Microsoft 365, user starts every turn
- Stay declarative. You inherit Copilot security and skip a second hosting line.
- You need proactive triggers, a domain model, or multi-system decision rules
- Custom engine agent. Budget hosting and your own RAI paperwork before the first Sprint.
- The assistant must run primarily outside Microsoft 365, or across Claude and open-weight models under one gateway
- Owned platform, not a Copilot agent type. Custom engine still ties the surface to Microsoft's channels.
- You only need a Teams channel bot for meetings and group chat
- Teams SDK path inside custom engine. Microsoft flags it for multi-user collaboration, not for every enterprise workflow.
What this costs us to say
We sell Claude and private-AI platforms as well as blueprints on the Microsoft path. That means the third branch above is a real product we build, not a rhetorical exit. If Copilot seats plus Studio credits are cheaper for your headcount, stay there — the three-year seat maths is on Copilot versus own AI platform. Custom engine agents are the middle: more control than declarative, still a Microsoft surface.
From the engine choice to the rollout
- Copilot Studio implementation: credits, layers, stop rules — the production checklist once you pick Studio or custom engine
- Service desk automation on your own knowledge — the money page when the agent must answer from tickets and runbooks
- Copilot vs own AI platform — three-year cost math — when the third branch above is the cheaper estate
- AI workflows vs AI agents: who decides — the control-loop question underneath Microsoft's taxonomy
What architects ask before they open Agents Toolkit
What are custom engine agents in Microsoft 365 Copilot?
They are fully customised assistants that run inside Microsoft 365 Copilot and Teams while you control the orchestration and the models. Microsoft's agents overview contrasts them with declarative agents, which stay on Copilot's own orchestrator and foundation models. Custom engine agents can be built in Copilot Studio, with the Microsoft 365 Agents SDK, the Teams SDK, or by publishing a Microsoft Foundry agent.
When should I stay on a declarative agent instead?
When the work stays inside Microsoft 365 apps, the knowledge is already in Graph, SharePoint or connectors, and you want Copilot's security and Responsible AI stack unchanged. Microsoft's own guidance is to use declarative agents for focused scenarios and faster low-code builds. You do not pay a separate hosting bill for the engine.
Do custom engine agents need extra hosting?
Often yes. Microsoft states that custom engine agents typically need hosting outside Microsoft 365 — for example Azure — at additional cost, unless you stay on the managed Copilot Studio path. Declarative agents are hosted in Microsoft 365. That hosting line is the first cost difference a CFO will see after the Copilot seat count.
Can one app package be both declarative and custom engine?
No. Microsoft's conversion documentation is explicit: an app manifest may include either a declarative agent node or a customEngineAgents node, but not both. Custom engine agents also require app manifest version 1.21 or later.
Who owns compliance for a custom engine agent?
You do, for the parts you bring. Declarative agents inherit Microsoft 365 compliance, RAI and security standards. Custom engine agents must ensure their own compliance, RAI practices and security measures. Prompts and responses in Copilot Chat and Teams are still stored under Microsoft 365 terms and can be reviewed with Content Search or Purview — that does not replace your own model-governance paperwork.
What does Pexon do with this decision?
A two-week Readiness Blueprint at €4,900 net. We map one real workflow onto declarative, Copilot Studio custom engine, Agents SDK, or an owned platform outside Copilot, and write the hosting and RAI gaps next to each option. The note is yours whether or not we build.
Next step
Map one workflow onto declarative, Studio, or owned
Two weeks, €4,900 net. We take one process, write which agent type Microsoft's own decision tree selects, and list the hosting and RAI gaps that stay yours. The note is yours whether or not we build.