Microsoft 365 Copilot Custom Engine Agents - When You Need Full Control

Microsoft 365 Copilot has two paths for building agents. The easy path is declarative agents - you configure prompts and connectors through a UI, and Microsoft handles the orchestration. The hard path is custom engine agents - you build the orchestration yourself, pick your own language models, and manage the full processing pipeline.

Most organisations should start with declarative agents. But some shouldn't. And knowing which camp you're in before you start building will save you months.

We've been helping Australian enterprises figure out this exact decision. The answer usually comes down to one question: do you need to control which model processes which part of the conversation? If yes, you're looking at a custom engine agent. If no, declarative is probably fine.

Microsoft's custom engine agent architecture documentation lays out the technical framework. Here's what that means in practice.

What Custom Engine Agents Actually Are

A custom engine agent is a conversational AI experience that lives in the Microsoft 365 Agent store but doesn't use Microsoft 365 Copilot Chat as its processing backend. You get the Microsoft distribution and client infrastructure - the Teams integration, the catalogue, the security wrapping - but the brain of the agent is yours.

This is a meaningful distinction. With a declarative agent, Microsoft's orchestrator decides how to process the user's message, which tools to call, and how to format the response. With a custom engine agent, your code makes all those decisions.

The architecture diagram Microsoft provides shows this clearly. The user's message enters through Microsoft infrastructure (Teams, M365 apps), hits your custom orchestrator, gets routed to whatever language models and APIs you've configured, and the response flows back through the same Microsoft channel.

Why You'd Want This

Three scenarios keep coming up in our consulting work.

Multi-model routing. Some tasks need a fast, cheap model. Others need the most capable model available. A custom engine agent lets you route different parts of a conversation to different language models. A triage step might use a small model to classify the user's intent, then route the actual processing to a specialised model for that task type.

We've built this pattern for clients in professional services, where the agent needs to handle both simple lookup queries (fast model, low cost) and complex document analysis (capable model, higher cost). The declarative agent approach doesn't give you this control - you get whatever model Microsoft assigns.

Complex orchestration logic. If your agent needs multi-step reasoning with custom logic between steps - checking business rules, calling internal APIs in a specific sequence, handling conditional workflows - the declarative model's tool-calling capabilities might not be enough. Custom engine agents let you write arbitrary code in the orchestration layer.

Non-Microsoft models. Perhaps your organisation has invested in fine-tuned models through Azure OpenAI, or you're using models from other providers for specific tasks. Custom engine agents let you point at whatever model endpoint you want. The Microsoft ecosystem handles the user interface and distribution; you handle the intelligence.

The Architecture in Detail

Microsoft breaks the architecture into six components, and each one has different implications depending on whether you go custom or declarative.

Client - your agent can work across the Microsoft 365 ecosystem (Teams, Outlook, etc.) and also external surfaces like web chat. This is one of the real benefits - you build the agent logic once and it's accessible wherever Microsoft 365 is. The catch is that supporting multiple client surfaces adds complexity. Adaptive cards render differently in Teams versus web, for instance.

Infrastructure - Microsoft provides the hosting infrastructure for the client layer. Your orchestrator runs on your own infrastructure. This split means you're responsible for scaling, monitoring, and securing the processing backend. For most Australian enterprises, that means Azure, which fits naturally.

Catalogue - your agent appears in the Microsoft 365 app ecosystem catalogue alongside declarative agents and other apps. Users discover and install it the same way. This is genuinely useful for enterprise distribution - you don't need to build your own discovery mechanism.

Security and compliance - this is where it gets interesting. Microsoft handles identity and access management for the client layer, but your orchestrator needs its own security implementation. You need to think carefully about data residency, especially for Australian organisations with sovereignty requirements. The data flows through Microsoft infrastructure to reach your backend, so you need to understand exactly where processing happens.

Orchestrator and language model - fully in your control. This is the whole point. You decide how messages are processed, which models handle which tasks, how context is managed, and how responses are generated. The flip side is that you're responsible for prompt engineering, token management, rate limiting, and all the operational concerns that the declarative model handles for you.

Tool calling - here's an honest limitation. Custom engine agents have limited access to Microsoft's built-in tools. If you need the graphic art generator or some of Microsoft's proprietary capabilities, you'll need to work around this. For most business use cases, this isn't a problem - your agent's value comes from calling your own APIs and systems, not Microsoft's built-in tools.

The Tradeoff Is Real

Microsoft's documentation frames it diplomatically, but the message is clear: custom engine agents are more capable and more expensive to build. The development effort is significantly higher.

With a declarative agent, you write configuration. With a custom engine agent, you write code - orchestration logic, model integration, error handling, response formatting, logging, monitoring, all of it.

I've seen organisations underestimate this. They see the flexibility and jump straight to custom engine agents when a declarative agent with a few plugins would have done the job. The result is a six-month project instead of a two-week configuration.

The decision framework I use with clients is simple. Can you describe your agent's behaviour as "when the user asks X, look up Y and respond with Z"? That's declarative. Does your agent need to make decisions about how to process each message based on complex rules? That's custom engine.

When to Choose Custom Engine

Based on what we've built for clients through our Microsoft AI consulting work, here are the patterns where custom engine agents make sense:

Enterprise workflow agents that need to orchestrate across multiple internal systems with business logic between each step. A procurement agent that checks budget, validates supplier, creates PO, and routes for approval - where each step has conditional logic - is a good fit.

Domain-specific AI where you've fine-tuned models or have proprietary inference logic. If you've trained a model on your company's engineering specifications or legal precedents, you want that model doing the work, not a general-purpose one.

Cost-sensitive high-volume agents where routing to cheaper models for simple queries and expensive models for complex ones makes a real difference to your monthly bill.

Multi-tenant agents where different customers get different model configurations, data access, or processing pipelines.

Building One in Practice

If you've decided custom engine is the right path, here's what the build looks like.

You'll use the Teams AI Library or Bot Framework as the foundation. Your agent registers as a Teams app, receives messages through the Bot Framework pipeline, and sends responses back. The orchestration layer sits between the incoming message and your model calls.

For the orchestration itself, you have options. If you're on Azure, Azure AI Foundry gives you a managed way to deploy and call models. Our Azure AI Foundry consulting work has shown this to be the most straightforward path for organisations already in the Microsoft ecosystem.

The key architectural decision is how to structure your routing logic. Some teams build a simple if-else classifier. Others use a small model to classify intent before routing to specialised models. The right approach depends on the diversity of queries your agent handles.

A Few Warnings

Don't build a custom engine agent just because you can. The maintenance burden is ongoing - model versions change, APIs evolve, token pricing shifts. Every moving part you control is a moving part you maintain.

Test extensively with real users before deploying. The orchestration logic that seems clean in development gets messy when users ask unexpected things. Budget time for prompt engineering - it's the difference between an agent that handles 80% of queries well and one that handles 95%.

And document your architecture. Custom engine agents are complex enough that the person who built it might not be the person who maintains it. If your orchestration logic lives only in someone's head, you've got a bus factor problem.

The Bigger Picture

Custom engine agents represent Microsoft meeting developers where they are. Not every AI agent fits neatly into a declarative template, and Microsoft is acknowledging that by providing the infrastructure without dictating the intelligence.

For Australian enterprises building sophisticated AI experiences, this is a good development. You get Microsoft's distribution, identity, and compliance infrastructure without being locked into their models or orchestration logic. If you're planning an agentic automation strategy that spans multiple platforms and models, custom engine agents give you a way to stay within the Microsoft 365 ecosystem while keeping your options open.

The documentation is worth reading in full. But the real learning comes from building one and hitting the edge cases that no documentation covers.