What Is New in the Microsoft 365 Copilot Declarative Agent Manifest 1.6

If you have built anything on Microsoft 365 Copilot beyond the out-of-the-box experience, you have met the declarative agent manifest. It is the JSON file that defines what a custom Copilot agent is: what it knows, what instructions guide it, what data it can reach, and what actions it can take. Get the manifest right and you have an agent that genuinely helps a team. Get it wrong and you have a chatbot that confidently makes things up.

The manifest schema is versioned, and each version quietly expands what you can declare without writing custom code. Version 1.6 is the latest step in that progression. For Australian businesses building internal Copilot agents (and there are a lot of you now, this has moved well past the early-adopter phase), it is worth understanding what the current schema gives you and where the genuine value sits.

Quick refresher on declarative agents

A declarative agent is a custom version of Microsoft 365 Copilot that you define, rather than build from scratch. The word "declarative" is the key. You are not writing the AI. You are declaring its configuration: its name, its instructions, the knowledge sources it should draw on, the actions it is allowed to perform. Microsoft's Copilot orchestrator and the underlying model do the heavy lifting. You describe the boundaries and the purpose.

This is genuinely the right model for most business use cases. The vast majority of organisations do not need to build their own agent runtime. They need a focused assistant that knows about their HR policies, or their project documentation, or their customer records, and answers questions grounded in that material rather than the open internet. The manifest is how you set that up.

The manifest is also where a lot of the real engineering judgement lives, which is why we spend so much time on it in our Copilot Studio and broader Copilot extensibility work. A vague manifest produces a vague agent.

What the schema version actually controls

Each version of the manifest schema defines which fields and capabilities you can use. When you write a manifest, you declare which schema version it targets. Pointing it at version 1.6 means you can use everything available up to and including that version. Older versions support fewer capabilities.

The practical effect of newer versions is steady: more of what used to require custom code or workarounds becomes something you can simply declare. The schema keeps absorbing capability. Things like richer knowledge source definitions, more control over behaviour and instructions, better support for actions that call out to external systems, and tighter scoping of what the agent can and cannot do.

I am not going to pretend every field in 1.6 will matter to you. Most teams use a fraction of the schema. But the direction of travel is worth understanding: Microsoft is making declarative agents more capable without making them harder to build, and that is a good trade. The more you can declare, the less custom plumbing you have to maintain.

Where declarative agents earn their keep

Let me be concrete about where we see these working, because the abstract pitch undersells it.

A professional services firm builds an agent grounded in its methodology documents and templates, so consultants can ask "what is our standard approach for a discovery phase" and get an answer drawn from the actual internal material rather than a generic guess. That is a knowledge-source-heavy agent and the manifest is mostly about pointing it at the right SharePoint sites and writing good instructions.

An operations team builds an agent that can not only answer questions but take actions, like logging a ticket or looking up an order status, by declaring actions that call into their existing systems. This is where the manifest's action capabilities matter, and where newer schema versions tend to add the most useful options.

The common thread is grounding. A declarative agent is only as good as the knowledge you connect and the instructions you write. The technology for connecting that knowledge has matured a lot, and the current schema reflects that, but the hard part was never the JSON. It is deciding what the agent should actually do, what data it should see, and how to keep it from drifting into territory where it gives confident wrong answers. That is the judgement work, and it is what we focus on when we help teams build these. Our AI agent builders team spends far more time on scoping and grounding than on the manifest syntax itself.

The honest caveats

Time for the parts the documentation will not stress.

First, schema version is a compatibility question, not a magic upgrade. Targeting 1.6 does not make your agent smarter. It gives you access to newer fields. If you are not using those fields, the version number changes nothing about how your agent behaves. Do not chase the latest version for its own sake. Use the version that supports the capabilities you actually need.

Second, these things move fast, and that cuts both ways. Microsoft ships new schema versions and capabilities at a real pace, which is great for what becomes possible, but it means you are building on a platform that keeps shifting. A manifest you write today may have newer, better options available in six months. That is fine if you accept it and plan to revisit your agents periodically. It is a problem if you build once and assume it is done forever. We tell clients to treat Copilot agents as living things that get reviewed, not set-and-forget projects.

Third, governance is the bit everyone underestimates. The easier it gets to build agents, the more agents appear, and suddenly an organisation has forty of them, half-built by different teams, some pointing at sensitive data nobody reviewed. The manifest makes it easy to declare what data an agent can reach. That same ease means you need real oversight of who is building what and what they are connecting it to. This is a recurring theme in our AI managed services work: the technology is the easy part, keeping it governed and trustworthy across an organisation is the actual challenge.

And fourth, the quality of the result still comes down to instructions and knowledge, not schema features. I have seen teams obsess over the technical manifest while writing two lines of vague instruction and connecting a messy, out-of-date document library. The agent was technically perfect and practically useless. Spend your effort on clear instructions and clean, current knowledge sources. That is what users actually feel.

How to think about adopting it

If you are already building declarative agents, moving to the current schema version is sensible when you want a capability it adds. There is no prize for staying on an old version, but there is also no urgency unless you need something new.

If you have not started, do not begin with the schema. Begin with the use case. Pick a genuine, narrow problem (one team, one clear job to be done), work out what knowledge and actions the agent needs, then build the manifest to match. The schema version follows from the requirements, not the other way around.

If you want a hand working out whether a declarative Copilot agent is the right tool for a particular job, or you have built a few and want them reviewed for grounding and governance before they spread further, get in touch. We do a lot of this, and we are happy to tell you when the honest answer is that you do not need a custom agent at all.

Reference: Declarative agent manifest schema version 1.6, Microsoft 365 Copilot extensibility documentation.