The Teams AI Library - Where It Fits in Microsoft 365 Copilot Extensibility

Most Australian organisations we talk to are somewhere on the same journey with Microsoft 365 Copilot. They rolled out the licences, usage settled into email drafting and meeting summaries, and now someone in leadership is asking the obvious next question: can we make it do things that are specific to us? Our policies, our systems, our processes. That question is what Microsoft calls Copilot extensibility, and the answer depends heavily on which of the available paths you pick.

At the far end of those paths sits the Teams AI Library, the pro-code option for building what Microsoft calls custom engine agents. Microsoft's extensibility documentation gives the overview from their side. This post is the view from ours, having built on it and, just as importantly, having talked several clients out of using it when something simpler would do.

The extensibility spectrum in one minute

Before the library makes sense, you need the map. Broadly, extending Copilot comes in three flavours.

Declarative agents are the lightweight option: you describe an agent with instructions, point it at knowledge sources like SharePoint, give it some actions, and it runs on Copilot's own orchestrator and model. No infrastructure, no model choice, fast to ship. For "answer questions about our HR policies" this is usually the right call, and it's cheaper than everyone expects.

Copilot Studio sits in the middle: a low-code maker experience where business users and makers build agents with topics, knowledge, and connectors. Enormously capable for its target use cases, and the licensing conversation is its own adventure.

Custom engine agents are the third flavour, and they're a different animal entirely. You bring the engine: your code, your orchestration, your choice of model, hosted on infrastructure you control. The agent surfaces in Teams and Microsoft 365 Copilot like any other, but everything behind the chat window is yours. The Teams AI Library is Microsoft's SDK for building exactly this.

The single most valuable thing a consultant can do at this stage is place your use case correctly on that spectrum. Getting it wrong in either direction is expensive - pro-code for a FAQ bot wastes months, and low-code for genuinely complex orchestration ends in a rebuild.

What the library actually gives you

Strip the branding away and the Teams AI Library is an SDK that handles the plumbing between your code and the Microsoft 365 world. Messages, events and card interactions arrive as clean objects; you register handlers; you reply. Under the hood it deals with the Bot Framework protocol so you mostly don't have to, and anyone who built bots on the raw framework years ago will understand what a mercy that is.

On top of that conversational layer it gives you the AI-shaped pieces: prompt management, a way to wire in your model of choice (Azure OpenAI is the default pick among our enterprise clients, but it's your call), function calling so the model can invoke your APIs, and the hooks for building proper multi-turn behaviour with state. Version 2 of the library cleaned up a lot - the developer experience is genuinely decent now, with a CLI for scaffolding and local DevTools that let you chat with your agent on localhost before anything touches a tenant.

TypeScript is the first-class citizen. C# and Python support exist and keep improving, which matters for the many .NET-heavy Australian shops we work with, but the samples and docs land in TypeScript first. Plan for that rather than being surprised by it.

The part I'd emphasise to any architect evaluating this: the library is deliberately unopinionated about the AI itself. It gets messages to your code and responses back to the user. What happens in between - which model, what orchestration, what guardrails, whether there's a RAG pipeline or an agent framework or three of them chained together - is entirely up to you. That's the whole appeal and the whole burden in one sentence.

When custom engine agents are the right call

Having watched this decision play out across a good number of engagements, the legitimate triggers are fairly consistent.

You need control over the model. Regulated industries wanting specific models in specific regions, teams with fine-tuned models, or anyone who needs to swap models as pricing and capability shift. Declarative agents run on Copilot's model, full stop. Custom engine agents run on whatever you say.

Your orchestration is genuinely code-shaped. Multi-step workflows with branching, calls into half a dozen internal systems with real error handling, business logic that would be torture to express in a maker canvas. If your whiteboard diagram of the agent looks like software architecture, build it as software.

You need to reach users beyond Copilot licences. This one is underrated. A custom engine agent runs in Teams for anyone in the tenant; it doesn't require every user to hold a Microsoft 365 Copilot licence the way declarative agents do. For an organisation of thousands where only a slice has Copilot seats, the economics of a custom agent that everyone can use are worth doing properly. Run the numbers both ways; sometimes they surprise people.

You already have engineering capability. This path assumes developers, CI/CD, Azure, monitoring, and someone on the hook when it misbehaves at 2am. It's ordinary software delivery. That's not a criticism - ordinary software delivery is a solved problem - but it's a different cost profile from a maker building in Copilot Studio, and the build is maybe half the lifetime cost. The rest is operating it.

If none of those triggers apply, genuinely, use the simpler path. Our Copilot Studio consultants spend a healthy portion of their time delivering agents in days that clients had assumed needed a development team, and a portion of the remainder gently talking engineers out of custom builds they'd enjoy but the business doesn't need. We build on both sides of the line, so the only agenda is not doing the rebuild later.

The honest assessment

What works well: the local development loop in v2 is the best part of the toolkit, and the separation between conversational plumbing and AI logic means you can test the skeleton before a model call exists. The path from "runs on my laptop" to "appears in Teams and Copilot for the pilot group" is well trodden. And because it's just code, everything your organisation already knows about testing, code review and deployment applies without translation.

What's still rough: the pace of change. Microsoft's agent story has been reorganising itself for a couple of years - libraries renamed, docs restructured, samples from different eras mixed together across the internet. It's stabilising, v2 was a real improvement, but expect the occasional tutorial that doesn't match the current SDK, and pin your versions. The first production deployment is also slower than anyone budgets: app registrations, bot resources, manifest packaging, admin consent, and at least one conversation with tenant admins that should have happened three weeks earlier. Schedule that conversation in week one. I mean it.

The other honest note: the library gets you a working agent, not a good one. Prompt quality, retrieval design, evaluation, guardrails, knowing what the agent should refuse to do - that discipline comes from your team, because the SDK has no opinions. That layer is where our AI agent development engagements concentrate, and it's consistently harder than the integration work. The model call is one line. Everything defensible around it is the actual job.

Where to start

If you think you're in custom engine territory, do three cheap things before committing budget. Write down the two or three triggers from above that apply to you, and be suspicious if none do. Scaffold the TypeScript sample and have a developer run it against the local DevTools for a day - the shape of the thing becomes obvious fast, and it's a far better evaluation than any slide deck. And map who in your organisation will own it in production, because an agent without an owner becomes shelfware with an Azure bill.

Then build the thinnest possible slice end to end - one useful behaviour, deployed to a test tenant, in front of five real users. The deployment pipeline and the tenant politics are where the surprises live, so surface them while the agent is still trivial. If you want help placing your use case on the spectrum, or a second opinion before the build starts, that's precisely the conversation our Microsoft AI consulting team has most weeks. It's a much cheaper conversation before the architecture is chosen than after.

The Teams AI Library is a solid piece of engineering for the cases that genuinely need it. Just make sure you're choosing it because you hit the ceiling of the simpler options, not because the ceiling looked more interesting from below.