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

If you have built a declarative agent for Microsoft 365 Copilot in the last year, you have written a manifest. It is the JSON file that tells Copilot what your agent is called, what it knows, what actions it can take, and how it should behave. Most people treat it as boilerplate you fill in once and forget. Then a manifest schema version bumps, a feature you have been waiting for turns up, and suddenly that file is the thing standing between you and a capability you want. Version 1.2 of the declarative agent manifest is one of those bumps worth paying attention to. Microsoft's reference is the declarative agent manifest 1.2 schema, and this post is the view from actually shipping these things for Australian clients.

Why a manifest version even matters

Here is the thing people miss about the manifest. It is not documentation. It is the contract. Copilot reads that file and decides what your agent is allowed to do based purely on what the schema version supports and what you have declared. If a capability was added in 1.2 and your manifest still declares 1.1, that capability does not exist for your agent, no matter how much code you wrote around it. The version string near the top of the file is a gate, not a label.

This trips teams up constantly. Someone reads a Microsoft blog post about a shiny new grounding source or a new action type, wires it in, and it silently does nothing. Nine times out of ten the manifest is pinned to an older schema and the new field is being ignored. So the first practical habit I push on every team we work with: when you want a new capability, check which manifest version introduced it before you write a single line. The schema version is the first thing to get right, not the last.

What version 1.2 brings to the table

The general direction of each manifest revision has been the same. Give declarative agents more of the reach that used to require a full custom engine build, without making people leave the low-code comfort zone. Version 1.2 continues that. The headline areas are richer knowledge grounding, more expressive capabilities, and tighter control over how the agent presents and behaves.

On grounding, the trend has been to broaden what a declarative agent can treat as a knowledge source and to give you finer control over scoping. Being able to point an agent at specific SharePoint sites, specific document libraries, or a curated set of sources rather than the whole tenant is the difference between an agent that answers from the right 200 documents and one that confidently quotes a policy from 2019 that nobody has followed since. Scoping is not a nice-to-have. It is the single biggest lever on answer quality for a knowledge agent, and each manifest version has been sharpening it.

On capabilities, 1.2 expands the set of built-in things an agent can do without you building the plumbing. Think of capabilities as the pre-wired skills Copilot offers: web search, access to specified Microsoft 365 content types, image handling, code interpretation, and so on. The value of a new capability in the schema is that you get behaviour Microsoft hosts and maintains, rather than an action you have to build, host, secure, and keep alive yourself. Every capability that moves into the declarative manifest is one less thing your team operates at 2am.

There are also refinements to how you declare instructions, conversation starters, and the general behavioural framing of the agent. These sound cosmetic and they are not. The instructions block is where an agent's personality and guardrails live, and more expressive control there means fewer cases where you have to escape to custom code just to say "never do this" or "always answer in this format".

I am deliberately not reciting the full field list, because Microsoft's schema page is authoritative and it changes. The point is the shape of the release: more grounding control, more hosted capability, more behavioural precision. That is the direction, and 1.2 moves meaningfully along it.

What this looks like in a real project

Let me make it concrete. A professional services client we worked with had a declarative agent answering internal questions about their engagement processes. Built on an older manifest, it grounded against a broad slice of SharePoint and the answers were, politely, hit and miss. It would surface superseded templates and old rate cards because everything lived in the same content estate and the agent could not tell current from archived.

The fix was not more code. It was tighter scoping in the manifest, pointing the agent at the specific libraries that held the live, governed content and excluding the archive. Answer quality jumped. No orchestration, no hosting, no custom retrieval pipeline. Just declaring the right sources in the right schema. That is the kind of win a manifest upgrade actually delivers, and it is why we treat the manifest as a first-class design artefact rather than config to rush through. This sort of scoping and grounding work is a core part of what our Microsoft AI consultants do before anyone starts talking about custom builds.

The other pattern worth naming: teams reaching for a custom engine agent when a current declarative manifest would have done the job. I have lost count of the conversations that start with "we need custom because Copilot cannot do X" where X shipped in a recent manifest version months ago. Before you commit to the operational weight of a custom engine agent, it is worth having someone who tracks these schema releases confirm you have actually hit the ceiling. Often you have not.

What to watch out for

Now the honest part, because a version bump is never as clean as the changelog implies.

Upgrading the manifest version is not automatic and it is not risk-free. When you move a live agent to 1.2, you are asking Copilot to reinterpret your whole declaration under a newer schema. Fields behave slightly differently between versions, defaults shift, and something that was implicit before can become explicit. Test the upgraded agent in a non-production environment before you touch the one people rely on. I have seen an agent's tone and answer style drift noticeably after a version bump simply because the instructions were being interpreted under new rules. Nothing broke, but the behaviour moved, and users notice behaviour changes faster than they notice new features.

Tooling lag is the other one. The manifest schema, the Agents Toolkit, the various portals, and the documentation do not always move in lockstep. You can find yourself with a schema that supports a capability while your local toolkit validation complains about it, or a portal that has not caught up. Pin your versions, keep a note of exactly which toolkit build you validated against, and do not assume a red squiggle means the schema is wrong. Sometimes the tooling is just behind.

And the eternal caution with Microsoft's agent stack: it moves fast and it renames things. Capabilities get promoted, previews graduate or vanish, and a tutorial written six months ago may reference fields that have shifted. Treat the official schema page as the source of truth and treat everything else, including older blog posts, as a hint. This churn is real, and it is one of the reasons clients bring us in rather than chasing the moving target themselves. Keeping up with it is genuinely a part-time job, which is exactly what our managed AI service exists to absorb.

Should you upgrade

My default advice is yes, but on your terms. If your current agent works and you have no need for anything 1.2 adds, there is no medal for being on the latest schema. Stability has value, and a manifest that is doing its job is not a problem to solve. Upgrade when you want a specific capability that 1.2 unlocks, or when you are already in the file doing other work and it makes sense to move forward while you are there.

If you are building something new, start on the current version. There is no reason to author a fresh agent against an older schema and inherit a future upgrade you could have skipped. Begin where the platform is now.

The broader read on version 1.2 is that declarative agents keep eating into territory that used to demand a custom build. That is genuinely good news for most organisations, because the declarative path is cheaper to build, far cheaper to operate, and does not need a developer on call. Every capability Microsoft folds into the manifest is capability you get without owning the infrastructure behind it. For Australian teams trying to get real value out of their Copilot licences without standing up a bespoke engineering effort, that trend is the one to bet on.

If you want a hand deciding whether a manifest upgrade unlocks what you need, or whether you have genuinely outgrown the declarative model, that is a short, cheap conversation to have early. Get in touch and we can look at your agent and your manifest together. The version string at the top of that file decides more than most people realise, and getting it right is a lot less painful than discovering the hard way that the feature you built around was never turned on.

Reference: Declarative agent manifest schema 1.2, Microsoft Learn.