Declarative Agent Manifest Version 1.3 - What Changed and Why It Matters

If you're building declarative agents for Microsoft 365 Copilot, the manifest is the file that decides what your agent can and can't do. It's a JSON document, it's not exciting to look at, and the version number at the top of it quietly controls which capabilities you're allowed to use. Version 1.3 is one of the meaningful checkpoints in that history, and understanding what the manifest version actually governs will save you a fair bit of "why won't this feature turn on" frustration.

We build these agents for Australian organisations across finance, professional services, and government, and the single most common cause of a broken or underpowered agent is a manifest version mismatch. Someone copies a capability out of newer documentation, pastes it into a manifest declared as an older version, and the agent silently ignores it. No error, no warning, just a feature that isn't there. So let me walk through what the version number does and where 1.3 sits.

What a Declarative Agent Manifest Is

A declarative agent is the lightweight way to extend Copilot. Instead of writing your own orchestration and hosting your own model, you describe an agent to the Copilot platform: give it a name and description, write its instructions, point it at some knowledge sources, and switch on a few capabilities. Copilot's own model and orchestrator do the heavy lifting. Your manifest is the whole definition.

That manifest has a schema, and the schema is versioned. The schema_version field near the top (values like v1.0, v1.2, v1.3, and the later releases) tells the platform which shape of manifest you're using. Each version adds fields and capabilities. Declare an older version and the newer fields aren't available to you. Declare a version the platform doesn't recognise and validation fails. It's a contract, and the version number is which edition of the contract you've signed.

Where 1.3 Fits

The manifest schema has moved quickly. Microsoft shipped a steady run of versions (1.0, 1.2, 1.3, and on through the later 1.x releases), each one broadening what a declarative agent can declare. Version 1.3 was one of the steps in that progression that expanded the capabilities you could attach to an agent, particularly around knowledge sources and the ways an agent can reach into Microsoft 365 content and beyond.

I'll be honest about a limitation here: Microsoft treats these manifest reference pages as living technical specs, and the precise field-by-field delta between 1.2 and 1.3 is the kind of thing that shifts, so the authoritative list of what 1.3 added lives in Microsoft's own reference (linked at the end). What matters for anyone planning a build is the principle, not the changelog trivia: pick a version that supports the capabilities you need, and don't reach for a version newer than your tooling and tenant actually support.

Here's the practical reality. If you're starting a new agent today, you generally don't want 1.3. You want the newest version your environment supports, because each release adds headroom. Version 1.3 matters mostly in two situations: you're maintaining an agent that was authored against it and you need to understand what it can do, or you're deliberately targeting an older schema because something in your deployment path (a validation tool, a tenant configuration, a governance policy) hasn't caught up to the newest release yet.

The Capabilities Question

The reason the version number matters so much is that capabilities are where declarative agents get their power. A capability is a switch that grants the agent access to something: web search, code interpretation, image generation, specific Microsoft 365 content, connected knowledge sources. Each manifest version defines which capabilities you can declare and how you configure them.

When we scope an agent build, the capabilities list is the first conversation, and it's usually a governance conversation as much as a technical one. An agent that can search the open web behaves very differently from one locked to a curated SharePoint library. An agent with code interpreter can do genuinely useful data work, and it can also do things a risk officer will want to understand before it ships. The manifest version determines which of these switches you even have access to, so version selection and capability planning are the same decision made twice.

This is the part I'd push back on when teams rush. There's a tendency to grab the newest manifest version and switch on every capability because more is better. It isn't. Every capability you enable is something you now have to reason about, test, and defend to whoever owns risk in your organisation. We tend to start narrow (one or two knowledge sources, tightly scoped instructions) and add capabilities only when there's a clear reason. A smaller agent that does one thing reliably beats a sprawling one that does five things unpredictably. We wrote more about that discipline in our guide to customising declarative agent behaviour, and the same instinct applies to version and capability choices.

Instructions Do More Than the Version Does

Something worth saying plainly: the manifest version sets your ceiling, but the instructions field is where most agents actually succeed or fail. You can be on the latest schema with every capability enabled and still ship an agent that gives vague, unhelpful answers because the instructions were an afterthought.

The instructions are natural language, they can run to a fair length, and they're where you tell the agent how to behave, what tone to use, what to do when it doesn't know something, and how to use its knowledge sources. In our experience the effort split is roughly a quarter on getting the manifest and capabilities right and three quarters on the instructions and the knowledge sources behind them. Teams that invert that ratio, obsessing over the schema and rushing the instructions, end up with technically valid agents nobody wants to use.

How to Choose Your Version in Practice

Here's the approach we use with clients, stripped down to something you can act on.

Start by listing the capabilities the agent genuinely needs. Not the ones that sound good, the ones that map to what the agent is for. If it's answering policy questions from a document library, you need knowledge sources and probably not much else. If it's doing data analysis, you're looking at code interpreter. That list tells you the minimum schema version that supports what you need.

Then check what your environment supports. Your authoring tools, your tenant, and any validation or governance gates in your deployment pipeline all have to accept the version you declare. There's no point targeting the newest schema if the pipeline that publishes your agent rejects it. This is exactly where a version like 1.3 stays relevant longer than you'd expect: real-world enterprise environments often run a version or two behind the absolute latest because change control moves deliberately.

Then declare the lowest version that covers your capability list and is accepted by your environment, and plan to move up over time. Manifests are not a set-and-forget artifact. As Microsoft ships new versions and your governance catches up, revisiting the version to pick up new capabilities is a normal part of maintaining an agent, not a sign something went wrong.

Where the Rough Edges Are

A few honest warnings from doing this work. The silent-failure behaviour is the big one: declare a capability your schema version doesn't support and you often get nothing rather than an error, so test every capability actually fires rather than assuming a clean publish means it works. Documentation and reality can drift, because this platform moves fast and the reference pages sometimes describe a version slightly ahead of or behind what your specific tenant has rolled out. And version upgrades aren't always free, because moving from one schema version to a newer one can change how existing fields are interpreted, so re-test after any upgrade rather than assuming it's a drop-in.

None of this is a reason to avoid declarative agents. They're the fastest way to get useful Copilot extensibility into an organisation, and for most business use cases they're the right starting point before anyone reaches for a full custom engine agent. The manifest version is just one of those details that's boring right up until it costs you a day, and then you never forget it again.

Getting It Right the First Time

If your organisation is building Copilot agents and you'd rather not learn the manifest quirks the hard way, this is squarely the work we do. Our Copilot Studio and Microsoft 365 Copilot consultants help Australian teams scope agents properly, pick the right schema version and capabilities for their governance posture, and write instructions that actually produce good answers. We also run Copilot training for teams who want to build this capability in-house rather than outsource it.

For the authoritative field-level detail, Microsoft's reference for the declarative agent manifest version 1.3 is the source of truth, and it's worth bookmarking alongside the newer version pages so you can compare what each one supports.