Almanac
Microsoft/copilotMicrosoft 365

Consultant KB for the whole Microsoft Copilot estate. Spans Microsoft 365 Copilot, Copilot Studio, the Dynamics 365 Copilots, Power Platform Copilot, Fabric & Power BI Copilot, Copilot in Azure, Windows & consumer Copilot, extensibility & agents, Security Copilot, and GitHub Copilot, plus admin/security and cross-product decision guides. Populated by the daily author agent from Copilot release notes / release plans plus the author's own consultant notes.

feature-declarative-agent-manifest-1-9.mdv1 · history
CurrentApplies to M365 CopilotUpdated last weekSource Microsoft Learn ↗

What it does

Version 1.9 is the current schema for the declarative agent manifest, the JSON file that carries an agent's name, instructions, capabilities, actions and conversation starters inside the app package. It adds two things: a top-level agent_skills property that points at skill folders, and a Fabric capability that lets the agent ground its answers in Microsoft Fabric data.

Key facts

  • Set "version": "v1.9" in the manifest. The schema is published as JSON Schema, so editors and validators can check it.
  • agent_skills is an array of objects, each with a required folder: a relative path from the manifest to a directory holding a SKILL.md. No ../ escapes, forward slashes only, and the folder has to exist inside the package. Maximum of eight entries.
  • The Fabric capability is a one-property object ("name": "Fabric"). Like other capabilities, you can't list it twice.
  • The 8,000-character limit on instructions and the 12-item cap on conversation starters carry over from earlier versions.
  • Microsoft's release notes say instructions became optional in 1.9, but the property table on the schema page still says "Required". Test before you rely on omitting it.
  • Fabric grounding and skills are the reason the Agents Toolkit insists on 1.9 for the skills feature.

When to use / skip

Move to 1.9 when you want skills or the Fabric capability. If an agent is stable on 1.8 and you need neither, leave it alone: a version bump on a working package is risk with no payoff.

Configuration decisions

  • Bump the manifest and the toolkit together. An older toolkit version will quietly fail when you add a skill.
  • Fabric or a Copilot connector. Fabric suits governed lakehouse and semantic-model data already in the tenant. Connectors suit third-party content you're indexing.
  • Where skill folders live. They ship inside the app package, so the 10 MB package ceiling applies to them as well as everything else.

Gotchas

  • The schema page and the what's-new entry disagree on instructions. Validate against the real schema, not the summary.
  • Capability arrays still allow one of each type, so a second Fabric entry fails validation.
  • Sample manifests and templates in older repos are pinned to 1.6 to 1.8; copying one and adding agent_skills without changing version gets you a rejection that doesn't say why.

Consultant notes

  • Put a version-pinning line in the build pipeline. Teams that let the toolkit pick the schema version get surprised when a template bumps it under them.
  • Fabric grounding sounds like an easy win and then stalls on workspace permissions. Sort out who can see the underlying data before the demo, not after.
  • Treat the manifest as a versioned artefact in source control. When an agent misbehaves after a republish, the first question is always which schema version and which manifest went out.

Worth revisiting when the schema moves past 1.9 or the Fabric capability changes shape.

Was this accurate?