Conditional Conversation Starters for Declarative Agents

Conversation starters should not advertise buttons your agent cannot back up. Tiny sentence, big UX problem. If a declarative agent shows “Analyze this spreadsheet” but the current manifest does not include Code Interpreter, the user learns something immediately: the starter list is more hopeful than honest.

Manifest schema v1.7 fixes that with a new depends_on property on conversation starters. Each starter can declare the capabilities it actually needs, and Copilot only shows it when those capabilities are present in the manifest.

The Static Starter Problem

Conversation starters are one of my favorite parts of declarative agents because they solve the blank-chat problem. Users should not have to guess what an agent can do. A starter is a little signpost that says, “Try this first.”

The trouble starts when the agent’s capabilities change across environments.

Maybe dev has CodeInterpreter, but production does not yet. Maybe one customer package includes Email, while another is scoped to SharePoint and OneDrive. Maybe your template supports web search only when the tenant allows it. Static starters do not know any of that. They just sit there, smiling, promising things.

Here is a perfectly valid v1.7 starter list with the same problem:

{
  "$schema": "https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.7/schema.json",
  "version": "v1.7",
  "name": "Sales Planning Assistant",
  "description": "Helps sales teams prepare for customer planning conversations.",
  "instructions": "$[file('instructions.txt')]",
  "capabilities": [
    {
      "name": "WebSearch",
      "sites": [
        {
          "url": "https://contoso.com"
        }
      ]
    }
  ],
  "conversation_starters": [
    {
      "title": "Summarize Contoso news",
      "text": "Summarize the latest Contoso news I should know before my planning meeting."
    },
    {
      "title": "Analyze my pipeline",
      "text": "Analyze my pipeline spreadsheet and identify risky opportunities."
    }
  ]
}

The first starter matches the manifest. The second one does not. There is no CodeInterpreter capability in that manifest, so the agent may not be able to do the spreadsheet analysis the starter implies.

That is not a schema error. It is a product experience error, and now we have a property to fix it.

What depends_on Adds in v1.7

Each entry in conversation_starters can now include an optional depends_on array. Each item in that array points at a capability the starter needs:

{
  "title": "Analyze my pipeline",
  "text": "Analyze my pipeline spreadsheet and identify risky opportunities.",
  "depends_on": [
    {
      "name": "capabilities",
      "id": "CodeInterpreter"
    }
  ]
}

Two required fields per dependency:

• name must be set to "capabilities". Today, capabilities are the only manifest element you can depend on.
• id is the capability name value used inside capabilities, like WebSearch, CodeInterpreter, Email, TeamsMessages, OneDriveAndSharePoint, GraphConnectors, People, Meetings, Dataverse, GraphicArt, or ScenarioModels. v1.7 also defines EmbeddedKnowledge, though that capability is not yet enabled.

The visibility rule is strict: a starter with a depends_on array is only displayed when all referenced capabilities are present in the manifest. Miss one capability, lose the starter.

Map your starters to the capabilities they imply, and you have a complete plan:

Starter	depends_on capability id
”Summarize Contoso news”	WebSearch
”Analyze my pipeline”	CodeInterpreter
”Find customer context in email”	Email
”Search the account team chat”	TeamsMessages
”Summarize this SharePoint folder”	OneDriveAndSharePoint

This is the kind of small manifest feature that can make an agent feel smarter without changing the model at all. The agent is not suddenly better at reasoning. The UI simply stops making promises the manifest cannot keep.

A Working v1.7 Manifest

Here is the same Sales Planning Assistant, rewritten with depends_on so every starter declares the capabilities it actually needs:

{
  "$schema": "https://developer.microsoft.com/json-schemas/copilot/declarative-agent/v1.7/schema.json",
  "version": "v1.7",
  "name": "Sales Planning Assistant",
  "description": "Helps sales teams prepare for customer planning conversations.",
  "instructions": "$[file('instructions.txt')]",
  "capabilities": [
    {
      "name": "WebSearch",
      "sites": [{ "url": "https://contoso.com" }]
    },
    { "name": "Email" }
  ],
  "conversation_starters": [
    {
      "title": "Summarize Contoso news",
      "text": "Summarize the latest Contoso news I should know before my planning meeting.",
      "depends_on": [
        { "name": "capabilities", "id": "WebSearch" } 
      ]
    },
    {
      "title": "Find customer context in email",
      "text": "Find the latest email thread with this customer and summarize open asks.",
      "depends_on": [
        { "name": "capabilities", "id": "Email" } 
      ]
    },
    {
      "title": "Analyze my pipeline",
      "text": "Analyze the attached pipeline spreadsheet and call out the top three risks.",
      "depends_on": [
        { "name": "capabilities", "id": "CodeInterpreter" } 
      ]
    }
  ]
}

Even though three starters are defined, only the first two will render. There is no CodeInterpreter capability in this manifest, so the “Analyze my pipeline” starter is filtered out automatically. Add { "name": "CodeInterpreter" } to capabilities and it appears.

You can also depend on multiple capabilities in a single starter. The starter only shows when every capability is present, which is great for prompts that genuinely need to combine signals:

{
  "title": "Brief me before my next meeting",
  "text": "Pull recent Contoso news and the latest email thread so I am ready for my next meeting.",
  "depends_on": [
    { "name": "capabilities", "id": "WebSearch" },
    { "name": "capabilities", "id": "Email" }
  ]
}

Drop either capability and the combined starter quietly disappears. That is exactly the behavior you want.

The review question is finally enforceable: if the user clicked this starter today, does the manifest give the agent what it needs? If the answer is no, depends_on makes sure the user never sees it.

A Better Before and After

Before depends_on, the user could click a starter that the manifest could not actually back up:

That response is not terrible, but the user clicked a starter that implied spreadsheet analysis. Now they have to do manual work because the starter overpromised.

With depends_on in v1.7, the starter list changes with the manifest:

• WebSearch capability present? “Summarize Contoso news” appears.
• CodeInterpreter capability present? “Analyze my pipeline” appears.
• Email capability present? “Find customer context in email” appears.
• TeamsMessages capability present? “Search the account team chat” appears.
• Strip a capability out? The matching starters quietly disappear.

The user sees fewer starters, but the starters are more truthful. That is a trade I will take every time.

The Same Rule Respects Admin and User Choices

The “present in the manifest” rule is the headline, but it is not the whole story. A capability can also disappear at runtime because of choices the agent author did not make.

Two forces can take a capability away after the manifest ships:

• Tenant admins can disable capabilities at the tenant level through Microsoft 365 controls. If your tenant turns off web search, the WebSearch capability stops being usable for everyone in that tenant, even if the manifest still declares it.
• Users can toggle capabilities on or off in the agent’s UI when the manifest author exposes them through user_overrides. Someone who turns Email off in their agent should not still see a starter that promises an email lookup.

depends_on honors those choices. The starter list does not just match what is in the manifest. It matches the manifest as the current user can actually use it. If the manifest declares WebSearch, the admin allows WebSearch, and the user has not toggled WebSearch off, the “Summarize Contoso news” starter appears. Take any of those three away and the starter quietly disappears.

That is what makes conditional starters worth shipping. Static starter lists cannot react to tenant policy or user preferences. Conditional starters can.

How I Use This in Templates

Conditional starters matter most for reusable agent templates.

A single template might support multiple packages:

1. Starter package: Instructions plus web search.
2. Knowledge package: Web search plus SharePoint and OneDrive.
3. Productivity package: Knowledge plus email, Teams messages, and Code Interpreter.

Without depends_on, you either maintain separate starter lists or ship generic prompts that avoid mentioning advanced capabilities. Both options are annoying. Separate lists drift. Generic starters are safe but boring.

With depends_on, the template keeps one richer starter catalog, and each package’s capabilities array decides what actually appears. Same conversation_starters block, different visible UX per package.

The Value: Honest Starter UX

• Capability-aware onboarding: Users see prompts that match the agent they actually have.
• Less disappointment: Starters stop sending users into flows the manifest cannot support.
• Cleaner templates: Builders can think in reusable starter catalogs instead of copy-pasted starter lists.
• Respects admin and user toggles: Starters disappear when a tenant admin disables a capability or when a user turns one off through user_overrides.
• Better governance reviews: Reviewers can map each starter to the capability that makes it true, and the manifest makes that dependency explicit.

Conversation starters are tiny, but they set expectations before the first user message. depends_on makes those expectations honest.

Resources

• Declarative agents overview
• Declarative agent manifest schema
• Declarative agent manifest v1.7. Full v1.7 reference, including the depends_on object on conversation starters.
• v1.7 JSON Schema. Drop into your $schema URL.
• Set a Default Response Mode for Your Declarative Agent. Another v1.7 property worth picking up at the same time.

---

The Manifest is where small manifest details get treated like product design, because that is exactly what they are.