Building Agents for Microsoft 365 Copilot - Declarative vs Custom Engine

Microsoft 365 Copilot does a lot out of the box. It can summarise emails, draft documents, pull data from across your Microsoft 365 environment. But the moment you need it to connect to your CRM, pull information from your custom line-of-business app, or automate a workflow that spans multiple systems, you hit the edges of what built-in Copilot can do.

That's where agents come in. Agents extend Copilot by acting as specialised AI assistants that can access external data, take actions across systems, and automate business processes. Microsoft offers two distinct approaches to building them, and choosing the right one matters more than most organisations realise.

We've been building Copilot extensions and agents for Australian businesses for a while now, and the declarative vs custom engine decision comes up in almost every engagement. Let me break down what each approach actually involves and when each one makes sense.

What Agents Actually Are

Before getting into the two types, it helps to understand what an agent consists of at a high level. Microsoft's agents overview documentation lays out the technical details, but the core is straightforward.

Every agent has two main components:

Knowledge - the instructions and data sources that shape how the agent responds. This might be SharePoint documents, data from a third-party system via a connector, or custom instructions that tell the agent how to behave in specific scenarios.

Actions - the things the agent can actually do. Send an email, update a record in Dynamics, create a support ticket in your ITSM platform, trigger a Power Automate flow. Actions are what turn an agent from a chatbot into something that gets work done.

On top of these, there's an orchestrator (the engine that coordinates everything), the foundation models (the AI doing the reasoning), and the user experience layer (where agents show up - Teams, Outlook, Copilot Chat, Word, etc.).

Declarative Agents - The Microsoft-Hosted Approach

Declarative agents are the simpler option. You configure them rather than code them from scratch. You provide custom instructions, connect knowledge sources, and define actions - and Microsoft's infrastructure handles the rest. The orchestration, the model, the hosting - all of that runs on Microsoft's side.

Think of it like configuring a specialised version of Copilot rather than building a separate AI application. You're telling Copilot "when someone asks about X, look here for data, follow these rules, and use these APIs."

When Declarative Agents Work Well

Internal knowledge assistants. The most common pattern we build is an agent that answers questions about company-specific information. Connect it to SharePoint document libraries, set up a Microsoft Graph connector to your intranet or wiki, add instructions about your company's terminology and processes. Users ask questions in Copilot Chat and get answers grounded in your organisation's actual data.

Process helpers with simple integrations. If you need an agent that can look up customer information in Dynamics, check order status via a REST API, or update a field in a database, declarative agents handle this well. You define the API actions using OpenAPI specs, and Copilot's orchestrator decides when to call them based on the conversation context.

Quick wins for business teams. Because you can build declarative agents using the agent builder in Microsoft 365 Copilot or Copilot Studio, business teams can create their own agents without writing code. IT can set guardrails, but the actual agent configuration can be owned by the people who understand the business process best.

The Limitations

Declarative agents inherit the capabilities and constraints of Copilot's orchestrator. You can't customise how the model reasons about problems. You can't swap in a different language model. You can't implement complex multi-step workflows that require custom orchestration logic. And you're limited to the channels Microsoft supports - Teams, Outlook, Word, Excel, and Copilot Chat.

For many use cases, these limitations don't matter. But when they do, you need the second approach.

Custom Engine Agents - Bring Your Own Everything

Custom engine agents give you full control. You provide your own orchestrator, your own language models, and your own hosting infrastructure. Microsoft provides the distribution channel - your agent still surfaces in Teams, Outlook, and other Microsoft 365 apps - but the brains of the operation run on your infrastructure.

This is where things get interesting from a development perspective, and also where things get more complicated.

When Custom Engine Agents Are the Right Call

Complex reasoning requirements. If your agent needs to follow sophisticated logic - breaking down problems into subtasks, calling multiple APIs in sequence based on intermediate results, maintaining state across a long conversation - you'll want custom orchestration. Frameworks like Semantic Kernel or LangChain give you the control to build these workflows properly.

Specific model requirements. Maybe you need a fine-tuned model for your industry. Maybe you want to use a smaller, faster model for simple queries and a larger model for complex ones. Maybe you have compliance requirements that dictate which model provider you can use. Custom engine agents let you plug in whatever models make sense.

Multi-channel distribution. Declarative agents only run in Microsoft 365 apps. Custom engine agents can also run in your own web applications, customer service portals, mobile apps, and anywhere else you need them. If you're building an agent that needs to serve both internal users via Teams and external customers via your website, custom engine is the way to go.

Agent-to-agent communication. This is a newer capability that I think will become increasingly important. Custom engine agents can delegate tasks to other agents and coordinate workflows across multiple specialised agents. If your organisation is building a network of agents rather than a single one, custom engine gives you the architecture to support that.

The Trade-offs

Custom engine agents require real engineering effort. You need to host the orchestrator and models somewhere (typically Azure), manage scaling, handle security and compliance yourself, and maintain the infrastructure over time. The development cost is higher, and the ongoing operational cost is higher too.

You also take on responsibility for responsible AI compliance. Microsoft's declarative agents inherit the RAI guardrails built into Copilot's infrastructure. With custom engine agents, you need to implement those controls yourself.

How to Decide

Here's the framework I use with clients:

Start with declarative unless you have a specific reason not to. Declarative agents are faster to build, cheaper to run, and easier to maintain. If your use case fits within their capabilities, there's no advantage to going custom.

Go custom engine when you need something declarative can't provide. Specific model requirements, complex orchestration, multi-channel distribution, or agent-to-agent collaboration. These are legitimate reasons to take on the additional complexity.

Consider a hybrid approach. This is what we end up recommending most often. Build declarative agents for the straightforward use cases - internal Q&A, simple process automation, knowledge assistants. Build custom engine agents for the complex workflows that need specialised logic. Both types coexist in the same Microsoft 365 environment, and users interact with them through the same interfaces.

The Tooling Landscape

Microsoft offers multiple paths depending on your team's skills:

For declarative agents, you can use the agent builder directly in Microsoft 365 Copilot (no code required), Copilot Studio (low code), or the Microsoft 365 Agents Toolkit with Visual Studio Code (pro code).

For custom engine agents, you have more flexibility. Build with .NET, Python, or JavaScript using frameworks like Semantic Kernel or LangChain. Use the Microsoft 365 Agents Toolkit for scaffolding and deployment. Or use Copilot Studio if you prefer a more visual approach.

The Agents Toolkit is worth looking at regardless of which approach you choose. It provides templates, debugging tools, and deployment workflows that take a lot of the boilerplate out of agent development.

What We're Seeing in Practice

Most Australian organisations we work with are starting with declarative agents. The typical first project is a knowledge assistant that sits in front of SharePoint content - policy documents, process guides, training materials. Users ask questions in Teams and get answers with citations back to the source documents. It's not glamorous, but it saves people real time.

The custom engine projects tend to come later, once organisations have a better understanding of what's possible and have identified workflows that genuinely need the additional control. We're building several right now that connect Microsoft 365 with external systems using custom AI agent architectures - things like multi-step approval workflows, automated document processing pipelines, and customer interaction agents that span Teams and web channels.

Getting Started

If you're thinking about building agents for Microsoft 365 Copilot, the best advice I can give is to start with a concrete use case rather than the technology. What's the specific problem you're trying to solve? What data does the agent need to access? What actions does it need to take? Once you've answered those questions, the declarative vs custom engine decision usually makes itself.

And if you want help working through that decision or building the agents themselves, reach out to us. We've been doing this long enough to know where the potholes are, and we can help you avoid the expensive mistakes.