The Declarative Agent Manifest Version 1.4 - Why the Version Number Matters More Than You Think

If you've started building declarative agents for Microsoft 365 Copilot, you've run into the manifest. It's the JSON file that defines what your agent is: its name, its instructions, the knowledge it can reach, the capabilities it's allowed to use. And right at the top of that file sits a small field that most people copy without thinking about, the schema version. Version 1.0, 1.2, 1.3, 1.4, and onwards.

It looks like boilerplate. It isn't. That version number decides which features your manifest is even allowed to describe. Pick an older one and you've quietly locked yourself out of capabilities you might need. Pick the newest the day it drops and you can run into tenants that haven't caught up. So this post is about version 1.4 specifically, what the manifest version controls, and how I'd think about choosing one for a real deployment in an Australian business.

What a declarative agent actually is

Quick grounding, because the terminology trips people up. A declarative agent is the lightweight way to build a custom agent on top of Microsoft 365 Copilot. You're not writing your own AI model or orchestration. You're taking the Copilot that's already there, the same one that reads your email and your SharePoint, and giving it a focused personality and a defined scope. You declare what it should do and what it can see. Microsoft's orchestrator and the underlying model do the actual work.

That's the appeal. You can stand up something genuinely useful, an agent that answers HR policy questions from your intranet, or one that helps the sales team find the right case study, without standing up infrastructure. The whole agent is described in a manifest file plus its knowledge sources. No servers, no model hosting, no MLOps.

The manifest is the contract. And like any contract, the version it's written against determines what clauses are valid. This is the model we lean on heavily in our Copilot Studio and declarative agent work, because for a lot of businesses it's the fastest honest route to a working AI agent that respects their existing permissions.

Why the schema version is doing real work

Here's the thing people miss. The manifest version isn't a label you stamp on for documentation. It's a declaration of which schema your manifest conforms to, and each new version of the schema unlocks new fields, new capability types, and new behaviours.

When Microsoft adds a capability to declarative agents, say a new kind of knowledge source, a new way to scope what the agent retrieves, or richer control over how it behaves, that new capability shows up as a new field or a new option in a later manifest version. If your manifest declares an older version, the platform validates it against the older schema, and the new fields either aren't recognised or aren't permitted. You can't use a 1.4 feature in a manifest that says it's 1.0. The version gate is real.

So the practical question for every agent you build is: what's the lowest manifest version that supports everything this agent needs? Go lower than that and you can't express what you want. Go to the bleeding edge unnecessarily and you take on compatibility risk for features you're not using.

What version 1.4 brings to the table

Version 1.4 sits in the middle of the lineage, with 1.5, 1.6 and 1.7 having arrived since. By the 1.x line reaching 1.4, the manifest had matured well past the bare-bones original. The early versions let you define an agent with instructions and basic knowledge. The later versions, 1.4 among them, expanded the range of capabilities an agent could declare and gave you finer control over how the agent draws on knowledge and behaves in conversation.

Practically, the value of moving up to a version like 1.4 is access to a broader and richer set of capabilities than the earliest schemas offered: more knowledge source types you can wire in, more control over scoping and behaviour, and refinements that make agents feel less like a constrained demo and more like a tool people will actually use day to day. If you're building anything beyond the simplest "answer from one SharePoint site" agent, you'll generally want a manifest version in this range or newer rather than starting at 1.0.

I'm going to be honest about the limits of what I can tell you precisely here. Microsoft iterates these schema versions quickly, and the exact field-level differences between, say, 1.3 and 1.4 are the kind of detail you should confirm against the current reference rather than trust from memory or a blog post. What doesn't change is the principle: read the version reference for the features you need, and pick accordingly.

How I'd choose a version for a real deployment

The instinct is to grab the newest version available. I'd push back on that slightly, and here's the reasoning I use with clients.

Start from the features, not the number. List what your agent genuinely needs. Which knowledge sources, which capabilities, which behaviours. Then find the lowest manifest version that supports all of it. That's usually your answer. Targeting the lowest sufficient version maximises compatibility across tenants and tooling.

Account for tenant rollout. Microsoft 365 features don't land in every tenant on the same day. A brand new manifest version and the capabilities it unlocks may be fully available in one tenant and still rolling out in another. If you're building for a specific client's tenant, the safe move is to confirm what that tenant actually supports today, not what the documentation says exists in general. I've watched teams build against the newest schema, demo it on their own dev tenant where everything's enabled, then deploy to a customer tenant where a capability hadn't rolled out yet. Avoidable pain.

Don't chase versions for the sake of it. If 1.4 does everything your agent needs, you don't need to rush to a newer version just because it exists. Upgrade when you have a reason, a feature you actually want. Stability has value. Every version bump is a small retest.

But don't get stranded on something ancient either. The flip side is that staying on a very old version locks you out of improvements and, eventually, out of support. If you built an agent on 1.0 two years ago and it's load-bearing, it's worth a periodic review to see whether moving up buys you anything worthwhile.

This balancing act, new enough to do the job, conservative enough to be reliable, is exactly the kind of judgement we bring to client work. Building agents that survive contact with a real corporate tenant is most of the job, and it's the difference between a slick demo and something that's still running in six months. Our AI agent builders spend a lot of their time on precisely these unglamorous compatibility decisions.

The bigger picture for Australian businesses

Step back from the manifest for a second. The reason any of this matters is that declarative agents are one of the lowest-friction ways for an Australian business already paying for Microsoft 365 Copilot to get real, scoped value out of it. You're not buying new platforms. You're shaping a capability you already own around your actual content and your actual processes, with your existing permissions and data boundaries respected automatically.

The manifest version is a small but real part of getting that right. It's the kind of detail that doesn't matter until it does, when a feature you assumed you had isn't available, or when an agent built on the wrong version won't validate in a customer's tenant. Getting it right up front is cheap. Discovering it in a production rollout is not.

If you want the authoritative, current detail, Microsoft's reference for the declarative agent manifest version 1.4 is where to confirm the exact schema, and it sits alongside references for the other versions so you can compare.

And if you're weighing up whether declarative agents are the right shape for what you're trying to build, or whether you've outgrown them and need something with more under the bonnet, that's a conversation worth having before you write the manifest, not after. We help Australian teams make that call most weeks. Get in touch and we'll give you a straight answer on which path fits.