What Changed in the Declarative Agent Manifest 1.7 and Why It Matters

If you build declarative agents for Microsoft 365 Copilot, you have probably felt the low-grade anxiety of the manifest version number ticking up. You shipped an agent against 1.5, it works, and then a new schema version lands and you are not sure whether you are supposed to care. Most of the time the honest answer is that you can keep running on your current version for a while. But you should know what each bump gives you, because occasionally one of them unlocks something you have been wanting, and occasionally one of them quietly deprecates a thing you were relying on.

Version 1.7 of the declarative agent manifest is one of those releases worth reading properly rather than skimming. The declarative agent model is how you describe a Copilot agent without writing a full custom engine: you hand Copilot a JSON manifest that says what the agent is for, what instructions guide it, what knowledge sources it can draw on, and what capabilities and actions it can use. The manifest is the contract. As it evolves, the surface of what your agent can express evolves with it.

Why the manifest version even matters

Let me back up for anyone who has not lived inside this. A declarative agent is Copilot with a personality and a boundary. Instead of building the language model orchestration yourself, you lean on Copilot's existing engine and constrain it: these instructions, this knowledge, these actions, this scope. The manifest file is where all of that gets declared, and its schema version tells Copilot which fields and features it is allowed to understand.

When you set a manifest to a given version, you are telling the runtime which capabilities are on the table. Newer versions add fields for new capabilities, refine how existing ones behave, and sometimes tighten validation so things that used to slide through now get rejected. That last part is where teams get caught. An agent that validated fine on an older schema can throw errors when you bump the version, not because you did anything wrong, but because the newer schema is stricter about something you had been sloppy with.

The manifest 1.7 reference is the authoritative source for the exact schema. What I want to give you here is the judgement around it: when to adopt a new version, how to do it without breaking things, and what the steady march of these releases tells you about where the platform is heading.

The pattern behind the version bumps

Rather than treat 1.7 as an isolated event, it helps to see the direction the manifest has been moving across releases. The trend across recent versions is consistent, and understanding the trend is more useful than memorising any single field.

Richer capabilities. Each version has expanded what an agent can natively do without you bolting on custom code. Capabilities like web search, access to specific SharePoint and OneDrive content, Graph connectors, code interpreter, and image generation have been added and refined over successive versions. The declarative model keeps absorbing things that used to require a custom engine. If you built an agent a year ago and worked around a missing capability with your own plumbing, there is a fair chance the current manifest now supports it natively, and you could delete code.

Tighter scoping of knowledge. A recurring theme is more precise control over exactly which content an agent can see. Early declarative agents were fairly blunt about knowledge sources. The trajectory has been towards letting you pin an agent to specific sites, specific files, specific connectors, so it answers from the right corner of your data and nothing else. For any organisation that cares about who can see what, and that is all of them, this precision is the feature that makes agents deployable rather than dangerous.

Stricter validation. As the schema matures, the platform gets fussier about correctness. This is a good thing even though it occasionally stings. A manifest that is precise about its capabilities and scope is a manifest that behaves predictably, and predictable is exactly what you want from something that reads your company's documents and answers staff questions.

When you adopt 1.7, read the reference against your existing manifest and check three things: whether any capability you hand-rolled is now native, whether your knowledge scoping can be tightened with newer fields, and whether anything in your current manifest trips the newer validation. That is the whole review, and it takes an hour.

How we actually roll a version bump

Upgrading a manifest version is not something to do casually on a production agent that people rely on. The process we use with clients is deliberately unexciting, because unexciting is what you want here.

First, we copy the agent and bump the version on the copy, not the live one. The copy runs as a sideloaded app for the team to test against. This gives us a safe place to see whether the new schema validates and whether behaviour shifts.

Second, we test the actual conversations that matter. Not "does it load" but "does it still answer the fifteen questions the business genuinely asks it". Schema changes can subtly alter how the agent interprets its instructions or which knowledge it prioritises. You only catch that by running the real workload, not by admiring a green validation tick.

Third, once the copy behaves, we update the production manifest and re-publish. Depending on what changed, especially if capabilities or permissions shifted, this can trigger a fresh admin approval and consent, so we treat it like a small release with its own communication rather than a silent swap. This is the same discipline we bring to the whole build through our Copilot Studio consultants practice, because the agents that survive in real organisations are the ones whose updates are boring and controlled.

My honest take on the pace

I will be candid: the version churn is a double-edged thing. On one hand, it is genuinely good that Microsoft is moving fast and folding real capability into the declarative model, because it means you write less custom code and get more from the platform. The declarative agent of today can do things that a year ago needed a proper custom engine, and that lowers the cost of shipping something useful.

On the other hand, the pace creates a maintenance tax that nobody tells you about up front. If you build a fleet of agents across a large organisation, each manifest version bump is a small decision multiplied across every agent you own. Do you upgrade all of them, some of them, none of them? Left alone, you end up with agents scattered across four different schema versions, and when one of the old versions eventually gets deprecated, you have a scramble on your hands. The answer is not to chase every version the day it lands. The answer is to have a deliberate policy: know which version each agent runs, review new versions when they arrive, and upgrade on your schedule rather than in a panic.

The other thing worth watching is that the newest schema features are often the ones with the least real-world mileage. A brand new capability in a fresh manifest version is exciting, but it has been in the wild for weeks, not years. For a low-stakes internal agent, being an early adopter is fine and even fun. For an agent that fronts a regulated process, I would let a new version settle before betting a compliance-sensitive workflow on its newest field.

Where this leaves you

The declarative agent manifest is not a static spec you configure once and forget. It is a living contract that gets richer and stricter over time, and staying current is part of owning an agent rather than just launching one. Version 1.7 continues the trend of more native capability and more precise scoping, which on balance is exactly the direction you want the platform going.

The practical move is to treat manifest versions the way you treat any dependency: know what you are running, understand what each new version offers, and upgrade deliberately with real testing rather than either ignoring the releases or chasing them blindly. Do that and the version number stops being a source of anxiety and becomes just another thing you manage well.

If you are building Copilot agents and want them built to last rather than to demo, that ongoing ownership is the work we care about most. Have a look at what our AI agent builders do beyond the initial build, or if you have got agents drifting across a mix of schema versions and want a plan to bring them current, get in touch and we will talk it through.