Microsoft 365 Copilot Agents Toolkit - An Honest Overview for Australian Teams

If you have spent any time around Microsoft 365 Copilot in the last twelve months, you have probably heard someone mention the Agents Toolkit. The marketing positioning is that it is the developer experience for building agents that extend Copilot inside Microsoft 365. The reality is a little more interesting and a lot more useful than the surface pitch suggests.

I have been building extensibility projects on top of Microsoft 365 Copilot for Australian clients across financial services, professional services and mining for the better part of a year. The Agents Toolkit has moved from "developer preview that almost works" to "the right way to do this if you are serious about it". This post is the conversation I have when a client asks me where to start and what they are actually getting into.

What the Agents Toolkit actually is

At its simplest, the Agents Toolkit is a development environment for building Copilot agents and Teams apps that extend Microsoft 365. It runs as an extension inside Visual Studio Code and Visual Studio. It gives you scaffolding, local debugging, provisioning to Azure, packaging for distribution, and lifecycle commands for the artefacts you have to produce.

Under the hood it is also the thing that knows how to translate your declarative agent manifests, plugin manifests, and Teams app packages into something that the Microsoft 365 admin centre and Teams Admin Centre will accept. That second part matters more than people realise. Producing a valid .zip package for an organisation-wide rollout of a declarative agent is genuinely fiddly the first time, and the Toolkit handles a lot of it for you.

So in plain language, the Agents Toolkit is the tool you use to:

• Scaffold a declarative agent project with the right manifest structure
• Build custom engine agents using Teams AI Library
• Wire up custom plugins (API actions, MCP actions)
• Provision Azure resources for the parts of your agent that run in your tenant
• Package the whole thing into a deployable app artefact
• Sideload it for testing and push it to admin centres for production

If you ignore the toolkit and try to do this with manifest files and Postman, you can technically get there, but you will spend two days learning where the schema validators live and another day chasing why your icon dimensions are rejected. I have done that. Use the toolkit.

The difference between declarative agents and custom engine agents

This is the most important distinction in the whole Copilot extensibility story, and the documentation could be clearer about it. The toolkit supports both.

A declarative agent runs on the Microsoft 365 Copilot orchestrator. You provide a manifest that describes the agent's behaviour, the data sources it can access through Microsoft Graph connectors, the actions it can take through plugins, and the tone of its responses. The model is Microsoft's hosted model. You are not running inference. You are configuring how Microsoft's orchestrator should behave when this agent is invoked.

A custom engine agent is different. You are running your own model and your own orchestrator, and Teams (or Copilot Chat) is just the front-end. You are responsible for the conversation state, the tool calls, the tracing, and the cost.

For 80% of the Australian clients I work with, declarative agents are the right starting point. They are faster to build, easier to govern, and they get the benefit of Microsoft 365 Copilot's grounding in tenant data. The remaining 20% are organisations who already have a strong reason to run their own model, often because they are integrating into an existing AI workspace or because the use case needs a model that Microsoft does not host. We do a lot of that work too, but it is a different conversation.

If you are not sure which one you need, that is exactly the question we work through at the start of a business AI strategy engagement.

What it is actually like to use

The first project takes longer than you expect. There is a m365agents.yml lifecycle file, an appPackage folder, a devTools folder, environment configuration in env/, and a teamsapp pattern that is borrowed from the older Teams Toolkit. Once you have built one of these projects you have built them all, but the first time around there is a fair bit of "what does this folder do" reading.

The good parts:

• F5 in Visual Studio Code does what you expect. It packages, sideloads into your dev tenant, and lets you debug with breakpoints in your action code
• The manifest schema validation is genuinely helpful. It catches things like missing icon files, malformed plugin descriptors, and conversation starter strings that are too long
• The Azure provisioning step uses Bicep templates that you can read and modify. That makes it less of a black box than the older Teams Toolkit was at the equivalent stage
• The packaging step produces a .zip that you can hand straight to a Microsoft 365 admin to upload

The rough parts:

• The provisioning step assumes a level of Azure permissions that not every developer in an Australian enterprise has access to. Expect to negotiate with your platform team for the right RBAC scope
• The local debugging experience for declarative agents (as opposed to custom engine agents) is limited. You are still uploading to Copilot and testing in the chat surface
• The documentation jumps between "Teams developer" and "Copilot developer" framing in ways that get confusing. The two are related but the toolkit serves both audiences
• Some of the more interesting features (like Work IQ skills and Knowledge Sources) are still in preview and the project structure for them changes between toolkit releases

None of this is a deal-breaker. It is the normal pattern for a Microsoft developer tool that is moving quickly. Expect to upgrade the toolkit every couple of months and re-validate that your project still scaffolds correctly.

Where Australian organisations get tripped up

Three patterns come up consistently when we work with clients on Copilot extensibility projects.

The first is permissions. The Agents Toolkit assumes the developer has rights to provision Azure resources, register applications in Microsoft Entra ID, and sideload custom apps in a test tenant. In most large Australian organisations, no single person has all three of those rights. You end up with the developer running the toolkit, a platform engineer running the Azure parts, and an identity admin running the Entra parts. That is workable, but you need to plan for it. We typically recommend a shared developer tenant for the build phase and a structured promotion path into the production tenant.

The second is governance. The toolkit will happily let you build an agent that connects to data sources, calls external APIs, and surfaces information in Copilot Chat. Whether your organisation is comfortable with that agent being made available is a separate question. The data classification, the third-party plugin approval process, and the rollout governance are organisational decisions that the toolkit does not solve for you. This is one of the reasons we run a governance workshop early in any Copilot extensibility project, especially for our financial services clients.

The third is testing. Copilot is non-deterministic. The same prompt against the same agent definition can return different answers run-to-run, and that makes regression testing genuinely hard. The toolkit does not have a great answer for this yet. The pattern we use is a combination of golden-prompt test suites run manually, plus telemetry from a small group of business pilot users, plus stricter prompts in the manifest itself to constrain the response style. This is one of the things you have to design for if you are deploying broadly.

When the toolkit is the wrong choice

If your use case is really "I want a chatbot on my website", the Agents Toolkit is overkill. Build that with Copilot Studio or with a direct integration into Azure AI Foundry, depending on the requirements.

If you want an agent that does not live inside Microsoft 365 surfaces at all (no Teams, no Copilot Chat, no Word side-panel), the toolkit is not helping you. You are building a different kind of product.

And if your organisation has not yet rolled out Microsoft 365 Copilot licences broadly, you are building extensions for a product that almost nobody can use. Start with the Copilot licensing decision first.

The bottom line

The Agents Toolkit is the right starting point if you are serious about extending Microsoft 365 Copilot for your organisation. It is not a magic wand. It is a developer tool with the usual rough edges of a fast-moving Microsoft product. But the alternative (hand-crafting manifests, manually building app packages, fighting the admin upload flow) is genuinely worse.

What I would tell anyone starting today is this: build a small declarative agent first. Pick a real use case that one team actually wants. Get it through your governance process end to end. You will learn more from that one cycle than from six months of strategy decks.

For Australian organisations that want help working through the build, governance, and rollout of Copilot extensibility, this is the kind of work my team at Team 400 does most weeks. We are happy to walk you through what your first project might look like - get in touch via our contact page.

Reference: Microsoft 365 Copilot Extensibility - Agents Toolkit Overview.