Microsoft’s Copilot ecosystem offers two paths to build your own AI assistant (agent): declarative agents and custom engine agents. In this post, I’ll explain what these things are, how they differ, and when to use each. If you’ve heard of “Copilot agents” but aren’t sure about the details, this guide is for you. What Are Copilot Agents? Just to back up a bit…In the context of Microsoft 365 Copilot, an agent is essentially a customized AI assistant. It’s like having your own version of Microsoft’s Copilot that you tailor to specific tasks or scenarios. These agents live within the Copilot ecosystem – meaning they can interact with users through Microsoft 365 experiences (like the Copilot chat in Teams, Word, Outlook, etc.) and leverage Microsoft’s AI stack under the hood. Think of a Copilot agent as a smart chatbot or assistant that understands natural language and can perform actions or retrieve information. For example, an organization might want an AI helper for their HR team or a troubleshooting bot for IT support. Copilot provides the foundation (the AI brain, conversational interface, and connection to your data), and an agent is a layer you build on top of that foundation to specialize it for your needs. Microsoft has introduced two primary ways to create these custom assistants:
- Declarative Agents – A configuration-driven approach where you declare what the agent should know and do, using the built-in Copilot provided LLM and orchestration. This is the no-code method to customize Copilot. If you’ve built an SharePoint agent or an agent in the M365 Copilot app (like the one in Teams), you’ve built a declarative agent. Copilot Studio also has a method to create declarative agents, but it’s fairly hidden in the interface.
- Custom Engine Agents – A development-driven approach where you build the agent’s logic and “brain” more or less from scratch (though with SDKs and tools to help). This is the low-code/pro-code method, giving you full control over the agent’s behavior and technology stack. This is usually what you’re creating in Copilot Studio, but also what you’re creating using the M365 Agents Toolkit (formerly called the Teams Toolkit).
Both types still fall under the Copilot umbrella – meaning they are considered Copilot extensions or custom Copilots – but they differ in how they are built and how much freedom you have. Let’s dive into each. What is a Declarative Agent? A declarative agent is a customized version of Microsoft 365 Copilot tailored for a specific scenario You create it by providing high-level instructions, defining what actions it can take, and specifying what knowledge it has access to. In other words, you declare the agent’s capabilities and scope, and Microsoft’s Copilot platform handles the rest. Key points about declarative agents:
- Powered by Copilot’s Brain: Declarative agents run on the same orchestrator, AI models, and services that power Microsoft 365 Copilot
- Easiest method to create a custom agent, by far. This is something even end-users can create.
That means you don’t worry about choosing or hosting the language model – it uses Microsoft’s AI (like GPT-4 in Azure OpenAI) behind the scenes. The agent uses Copilot’s built-in intelligence and follows the normal Copilot way of conversing.
- Configuration, Not Code: You don’t write traditional code to create a declarative agent. Instead, you configure it (typically using a tool called Copilot Studio, which provides a visual interface). When building a declarative agent, you supply:
- Instructions – a description of what the agent should do and how it should behave (in natural language, up to a certain length, e.g. a few thousand characters). This guides the AI’s behavior, kind of like the agent’s “personality and role” definition.
- Knowledge – the data or content sources the agent can draw from. For example, you might link it to specific SharePoint sites, documents, or even external websites that contain information the agent needs. You can also use Microsoft Graph connectors (now called Copilot connectors) to let the agent search enterprise data, just like the normal Copilot can.
-
- Actions – the things the agent can do for the user. In Copilot terms, actions often come from plugins. Declarative agents can be equipped with one or multiple plugins to perform tasks like looking up a CRM record, creating a ticket in an external system, sending an email, etc.
You essentially declare which plugins (and thus which actions) the agent has available. For instance, an agent might have a plugin to query a database or trigger a workflow.
- Runs Inside M365 Copilot UI: A declarative agent is experienced through the familiar Copilot interface. In fact, to the end user, it looks and feels like using Microsoft 365 Copilot, just specialized. Users might go to the Microsoft 365 Chat (also known as Business Chat) or open Copilot in an app and then select your custom agent from a menu. The UI and chat experience is the same as Copilot’s, which is great for adoption because it’s already friendly and known. The difference is that behind the scenes, Copilot knows to route the queries to your agent’s context/instructions.
- Security & Compliance: Because it’s built on Copilot’s infrastructure, a declarative agent inherits Microsoft’s security, privacy, and compliance features
Data access is governed by the same permissions (the agent can only see what the user is allowed to see). Admins also have control over agent distribution – for example, an admin can manage who in the organization has access to use a particular agent via the Microsoft 365 admin center So from an IT perspective, it’s fairly safe and manageable – it’s just another Copilot, subject to organizational controls. Example: Imagine an internal IT Helpdesk Copilot. Using a declarative agent, you could build an assistant that employees can ask tech support questions. You’d provide it with instructions to help with common IT issues, give it knowledge sources (like SharePoint pages or PDFs of FAQ, troubleshooting guides), and perhaps an action plugin to create a ticket in the helpdesk system. When an employee asks “My VPN isn’t working, what can I do?”, the agent (using Copilot’s AI) will reference the internal knowledge base and provide a solution or even offer to log a support ticket if needed. All of this happens in the Microsoft 365 Chat interface. The benefit: employees get quick answers 24/7, and the IT team’s workload is reduced. Microsoft’s documentation notes this scenario – employees resolving tech issues via a specialized agent that pulls info from SharePoint as a prime example of a declarative agent in action In summary, declarative agents are Copilot out-of-the-box, with your custom flavor added. You leverage Microsoft’s AI capabilities and simply tell it “focus on this domain, with these tools.” It’s really faster and easier to build, but within the bounds of what Copilot’s platform provides. Benefits of Declarative Agents
- Easy to Build: You don’t need to be a software developer. Using Copilot Studio’s visual canvas, Microsoft Teams, or even SharePoint, you configure the agent with text and settings. This no-code approach means faster development cycles and the ability to iterate without writing complex code. It’s ideal for power users or IT pros who understand the business needs but aren’t hardcore programmers.
- Uses Proven AI & UI: Your declarative agent uses Microsoft’s top-notch AI models (like GPT-4) and the Copilot orchestrator without you having to manage any of it
And users get the same Copilot chat interface they may already be using. This means you get a high-quality AI experience with minimal effort and a consistent user experience. No need to design a UI or host an AI model – it’s all handled for you. What is a Custom Engine Agent? A custom engine agent is a Copilot-based AI assistant where the developer has full control over the orchestration, logic, and even the AI models used It’s called “custom engine” because you are essentially building or choosing the engine that powers the agent, rather than using the standard Copilot engine. This approach is for scenarios that require more flexibility than the declarative model allows. Key points about custom engine agents:
- Bring Your Own Orchestration & AI: Unlike declarative agents, which rely on Microsoft’s built-in orchestrator, a custom engine agent lets you implement your own orchestration and even plug in different AI services or models. If you’ve heard about “Semantic Kernel” or “Langchain”, those are orchestrators you can choose from when building your custom engine agent. If you use Copilot Studio, it has its own (called Flux, I believe), and cannot be changed.
That means you could use alternative large language models (maybe a fine-tuned model specific to your industry, or an open-source model) or add additional logic on how to handle a conversation. You could even orchestrate multiple models together. Essentially, you are not limited to the one-size Copilot brain – you can customize the “brain” itself.
- Full Code Flexibility: Building a custom engine agent is a pro-code development task. You (or your dev team) will write code to define how the agent processes input, calls AI models, and interacts with systems. Microsoft provides tools and SDKs to support this (for instance, the Microsoft 365 Agents SDK and the Teams AI Library are available to help structure your agent and connect it to Copilot and Teams interfaces
You can think of it as building a chatbot from the ground up, but with the option to hook into Copilot’s entry points.
- Custom Workflows and Actions: With code, a custom agent can do things beyond the scope of what a plugin can define. For instance, you can create proactive behaviors – an agent that, say, watches a database and notifies a user or initiates a conversation on its own when certain conditions are met. The documentation notes “proactive automation” as a characteristic: the agent can be programmed to trigger workflows or actions across your apps without waiting for the user to ask
This is huge for scenarios like monitoring or alerting, where the agent might start the dialogue (“I noticed an anomaly in the system, let’s address it”) rather than just respond.
- Broader Integration and Channels: Custom engine agents aren’t confined to the Copilot chat in Office apps. Because you manage its deployment, you can make it available in various channels – such as in Microsoft Teams (as a bot), on your company’s website, a mobile app, or even in a custom interface. Microsoft’s tooling allows publishing these agents in multiple places. For example, an agent built with the Microsoft 365 Agents SDK can operate in Teams, Outlook, a web chat, or even be embedded in a custom app or website
This multi-channel ability is important if your use case isn’t just for internal employees on Microsoft 365 – e.g., if it’s customer-facing or needs to integrate with external platforms.
- Choice of AI Models: With a custom engine, you are not limited to the AI model Microsoft provides. You could use Azure OpenAI with a specific model or even multiple models, or incorporate an entirely different AI service. In fact, you could use smaller domain-specific models for certain tasks and a large GPT-4 for others. You have flexibility to choose or even fine-tune models that best suit your scenario
For example, maybe you want an agent that understands legal documents – you might incorporate a fine-tuned legal language model to improve accuracy. Or you might have sensitive data and choose to use an on-premises model for those queries.
- More Development Overhead: The flip side of freedom is you are responsible for the heavy lifting. You will need a place to run your agent’s code (which could be Azure if you follow Microsoft’s guidance, or your own servers). You will handle the lifecycle: development, testing, deployment, monitoring, updating. Microsoft’s ecosystem does offer helpful tools, like the Copilot Agents Toolkit (which is an extension for Visual Studio Code/Visual Studio to scaffold and deploy agents)
Ultimately the logic and maintenance are on you. This is more similar to a traditional software project, and usually requires a software developer. To put it simply, a custom engine agent is you building your own Copilot from scratch, using Microsoft’s hooks to plug it into the Copilot world. You’re not just configuring Microsoft’s AI; you’re crafting the AI behavior itself. Example: Suppose your company wants an AI assistant for complex financial trading decisions. You have proprietary models and algorithms that analyze market data. A declarative agent wouldn’t cut it because you need to integrate these custom algorithms and maybe even your own AI model that predicts trends. With a custom engine approach, you can build an agent that:
- Uses your in-house predictive model (alongside or instead of a GPT-style model).
- Orchestrates a conversation where it asks the user key questions (like risk tolerance) and then performs computed decisions, not just regurgitating content.
- Connects to various external APIs (maybe your trading platform, news feeds, etc.) in a finely controlled sequence.
- Possibly even proactively alerts a user: “The market dipped 5%, shall I reallocate your portfolio?”.
This agent could run as a bot in Teams for your analysts, and you might also surface it in a custom dashboard app. The custom engine route would allow this level of advanced interaction and multi-step logic which you just couldn’t declaratively describe. Benefits of Custom Engine Agents
- Maximum Flexibility: You can tailor almost every aspect of the agent. From the conversation flow, to how it processes each user turn, to which AI model it calls – it’s all up to you. This means complex or niche scenarios can be handled. If you need to implement specialized logic or integrate with systems in a non-standard way, you can. You’re not constrained by Copilot’s built-in capabilities.
- Integration with Anything: Because you’re writing the code, you can integrate with any system or data source that you can code against. There might not be a Copilot plugin for your old legacy database – no problem, you can write the integration directly in your agent. You can also mix multiple data sources and logic in ways that a single plugin or connector might not handle. It’s truly a “sky’s the limit” integration story – if there’s an API or method to get the data, you can plug it in. This also includes using different AI services (for example, using a vision AI to analyze an image as part of the workflow, or calling a knowledge graph). A custom agent could coordinate multiple AI calls in one conversation turn, which declarative cannot explicitly orchestrate.
- Multi-Channel and White-Labeling: You can deploy the agent beyond just the Microsoft 365 Copilot interface. For instance, if you want the same agent to be available in your company’s internal Teams and also on your public website for customers (with some differences in behavior maybe), a custom engine agent can allow that. You essentially own the agent as an app that you can host wherever needed. This is great for companies who want a unified assistant experience across platforms, or want to offer their agent to customers or partners who aren’t on their M365 tenant. Also, you can brand the experience more fully if needed when you control the interface (though even inside Teams, you can have a custom name and icon for the bot).
- Choice of AI Models and Tech Stack: If you have concerns about data residency or want to use an open-source model for certain data, you can do that. You’re not forced into only Microsoft’s AI. You could even run an AI model offline or on-premises (for extreme cases) and have your agent call it. This freedom to choose can also help manage costs – for example, maybe for very long documents you use a smaller (cheaper) model to summarize them, but for critical user questions you use GPT-4. Custom logic can handle such decisions to optimize cost and performance, which a declarative agent wouldn’t do on its own.
- Advanced Workflows (If/Then/Memory): With code, you can manage the agent’s memory and context however you want. You could implement complex if/then logic, looping, or multi-turn strategies that go beyond the basic prompt-based approach. If your scenario requires an interview style interaction (ask a series of questions, then provide an output), you can code that sequence. Essentially, you can guide the conversation in a deterministic way when needed, rather than always relying on the AI to figure out the best approach. This can increase reliability for tasks that require structured interaction.
Key Differences Between Declarative and Custom Engine Agents Now that we’ve outlined each type, let’s compare them side by side on key aspects:
| Aspect | Declarative Agent | Custom Engine Agent |
| Approach to Building | No-code / Configurable – Built by declaring instructions, knowledge sources, and actions (no traditional coding). Typically done via browser or a simple manifest editing | Pro-code / Programmable – Built by or using Copilot Studio or writing code (C#, JavaScript/TypeScript, etc.) using the M365 Agents SDK or other SDKs. You design the conversation logic and integrate APIs in code |
| Orchestration Logic | Microsoft-defined – Uses the built-in Copilot orchestrator to manage how the conversation flows and how AI is invoked. The logic of answering or solving tasks is handled by Copilot’s algorithms, guided by your instructions. | Developer-defined – You have full control. You can incorporate custom decision trees, use external orchestrators, or frameworks like Semantic Kernel to manage the conversation flow |
| AI Model | Fixed (Copilot’s model) – Uses Microsoft’s chosen foundation model (as of now, likely GPT-4 for text) and any future updates they include. You cannot change the core AI model (though you can influence it via prompts/instructions). | Flexible – You choose the AI model or models. Could be Azure OpenAI’s GPT-4, GPT-3.5, or any other model/service. Can mix and match (e.g., use a fine-tuned model for one part, another model for a different part) |
| Data & Knowledge | Enterprise data via connectors; limited external sources – Can directly use Microsoft Graph-connected data (SharePoint, OneDrive, emails, etc.) easily, just like Copilot Can also target specific SharePoint sites or up to a few websites for domain-specific info For anything else, needs a plugin (which someone must provide). No direct database queries unless a plugin exists. | Any data source you can code – You can connect to databases, call web services, read files, or use Graph/API calls as needed. You aren’t limited to the connector catalog or a set number of sources. If you need to pull info from an internal on-prem system or a third-party API, you can build that into the agent’s code. |
| Actions & Integrations | Plugins (pre-built actions) – Declarative agents rely on the plugin system for taking actions (e.g., write back to a system) You declare which plugins (out of those available) are included. If a needed integration doesn’t have a plugin, you can’t directly do that action (until a plugin is made). | Custom integrations – You can directly integrate with any system. Call APIs or run operations as part of your code. This means you can implement actions that no pre-made plugin exists for. It might use plugins too if convenient, but it’s not limited to them – your code can do whatever, including complex multi-step transactions. |
| User Experience | Microsoft 365 Copilot UI – Appears as part of the Copilot Chat interface in Microsoft 365 apps (like a specialized Copilot). Users invoke it similarly to how they use Copilot normally The branding is minimal (you can name it and have an icon, but it sits within the Copilot panel). Great for internal use by employees in the tenant. | Flexible UI and Channels – Often surfaced as a bot (e.g., in Teams with a custom name/icon) or via a custom app/Web chat. Can be deployed to multiple channels (Teams, Outlook, web, mobile) including external-facing contexts. So you have more control over how and where users interact with it. |
| Development Skill Required | Basic (End User/Power User level) – If you can write clear instructions and understand your data, you can create a declarative agent. Knowledge of the business is the main requirement; technical skills needed are relatively light (familiarity with the admin centers or Studio tool). | Advanced (Developer level) – Requires software development capabilities. Understanding of AI prompting, APIs, and deploying applications is needed. Likely a team effort with developers, especially for large-scale agents. |
| Maintenance | Managed by Microsoft – Microsoft handles model updates, performance tuning, uptime, etc. You mainly maintain the content of instructions or update knowledge sources occasionally. If Microsoft improves Copilot, your agent benefits automatically. | Managed by You – You need to monitor the agent’s performance, update code for improvements or bug fixes, and keep integrations up-to-date. If a service it depends on changes, you must adapt. You also decide when to upgrade the AI model or libraries you use. |
| Examples | Use Cases: Internal support bots, Q&A assistants, onboarding guides, simple workflow helpers that fit within known data/actions. E.g.: an HR policy Q&A agent, a sales info lookup assistant, an FAQ bot for field technicians that pulls from manuals, etc. These are often achieved with just instructions + company data + maybe a plugin or two. | Use Cases: Complex and bespoke scenarios, or customer-facing bots at enterprise scale. E.g.: an agent that orchestrates a loan application process across multiple systems, a customer service bot with custom troubleshooting logic, an AI that assists in medical diagnosis using proprietary models, or any scenario where you need to deeply customize behavior. Often chosen by enterprises or software vendors who want to create a unique AI solution. |
Choosing Between Declarative and Custom Engine Agents Both approaches have their place. The decision comes down to the specifics of your project – its complexity, your resources, and your goals. Here are some guidelines to help you choose:
- Use Declarative Agents if…
- Your scenario is fairly straightforward or well-bounded. If you primarily need an assistant to answer questions or perform simple tasks using existing Microsoft 365 data and services, declarative will usually suffice. For example, an internal FAQ bot or a meeting summary helper can likely be done declaratively.
- You want speed and simplicity. You can spin up a declarative agent relatively quickly. If time-to-market is important and you don’t have a lot of dev resources, this is a big factor. Maybe you want to pilot an idea – declarative is great for prototyping too, since you can always switch to custom later if needed.
- There’s a Copilot plugin or connector for the actions you need. If everything you want the agent to do is covered by existing integrations (e.g., it just needs to fetch info from SharePoint and maybe create a task in Planner via a plugin), then no need to reinvent the wheel with custom code.
- You prefer Microsoft to handle the AI heavy lifting. If you don’t want to manage AI models, worry about hosting, or continuously tweak the conversation logic, declarative keeps you on the rails with less maintenance. You trust that Microsoft’s Copilot core will do a good job in general, and you just focus on feeding it the right info.
- Consistency and compliance are paramount. In highly regulated environments, using the managed Copilot service might simplify compliance since Microsoft provides a lot of guarantees. Also, if you want the user experience to be uniform (all within Office apps), declarative ensures that.
- Use Custom Engine Agents if…
- Your scenario is complex or unique. If the agent needs to do multi-step processes, work with unusual data sources, or enforce custom logic (like a specific decision tree), going custom is likely necessary. For example, an agent that helps diagnose equipment issues might need to reference an internal diagnostic model and then perform a series of checks – custom code can handle that.
- You need integration beyond what’s available. Perhaps you have a proprietary database or third-party system with no existing Copilot plugin. With a custom agent, you can directly integrate it. Also, if you need the agent in a customer-facing app or on a website (outside of the M365 ecosystem), custom is the way to deploy it there.
- Flexibility in AI choice is important. Some organizations might have their own AI investments – say you trained a language model on your own data, and you want the agent to use that. Or you might be cost-conscious and want to use a smaller model for certain tasks. Custom agents allow these choices. Declarative will always use Microsoft’s provided AI, for better or worse.
- You have the developer resources. If you’ve got a team of skilled developers (or you’re partnering with a firm) and the project justifies it, custom agents unlock possibilities at the expense of more work. It’s like deciding to build a custom app instead of using an off-the-shelf solution – you’d do it if the off-the-shelf doesn’t meet your needs and you can afford to build bespoke.
- You plan to reuse or productize the agent. If the agent is not just a one-off for your org, but something you might resell or provide to others (like an ISV building a Copilot to offer to many clients), a custom engine agent gives you full ownership and the ability to publish in various ways (even app stores or marketplaces). Declarative agents, at least currently, are more for in-tenant use and not something you’d distribute externally.
Conclusion Declarative agents vs custom engine agents – they are two sides of the same coin: enabling organizations to create AI assistants that go beyond the generic Copilot. To recap:
- A declarative agent is like telling Copilot, “Here’s exactly what my users need – please handle it.” It’s configuration over code. Ideal for many standard business scenarios, it leverages the Copilot infrastructure fully. You trade some flexibility for ease-of-use and speed. The keyword is declarative: you declare your agent’s intent and scope, and Copilot does the heavy lifting
- A custom engine agent is like saying, “I’ll handle this my way, using Copilot as a base.” It’s about control and customization. You essentially build your own AI app that can tie into Copilot or work alongside it. It’s suited for advanced or very specific scenarios where you need that control
If you’d like to learn more about how to leverage no-code/low-code Copilot agents to automate your business, or you’d like me to train your users on how to create no-code/low-code agents, contact me!
