What it does

A declarative agent can hand part of a task to other agents. You list their title IDs in the worker_agents property of the agent manifest, and Microsoft 365 Copilot Chat brokers the exchange at runtime: it picks a connected agent from its name, description and example prompts, sends it a text request, and folds the text reply back into the conversation.

Key facts

• worker_agents arrived in declarative agent schema version 1.6.
• A connected agent must be a declarative agent, or an external agent with a registered Agent2Agent (A2A) agent card in the Microsoft Agent 365 agent registry.
• A title ID is a single letter, an underscore and a GUID. For a declarative agent you'll find it in the Provision output in the Microsoft 365 Agents Toolkit, or in developer mode. For a registered external agent it's the id on the agentRegistration object.
• Routing is driven by the connected agent's name, description and example prompts. For a declarative agent the example prompts are the text of its conversation_starters; for a registration they're the examples on the agent card's AgentSkill.
• Authentication to a declarative agent rides on the user's existing Copilot sign-in. For external registered agents the registration points at an existing authentication registration through an authorization object (None or OAuthPluginVault, plus a referenceId from the Teams developer portal Entra SSO registration).
• Authentication and access are separate questions: users still have to acquire the connected agent, or an admin has to deploy it to them.
• The calling agent sends text only. Declarative agents reply with text or Adaptive Cards; A2A agents can also return Base64 images and files.

When to use / skip

Use it when one agent has become unreliable because you've piled knowledge sources and tools onto it, when another team owns a capability you'd rather call than copy, or when one back-end agent should serve several audience-specific front ends. Skip it for a task a single well-scoped agent already handles; you're adding a routing decision and a second thing to govern for no gain.

Configuration decisions

• Which capabilities split out into their own agent, and who owns each one.
• Whether the connected agent is a declarative agent or an A2A registration in Agent 365, which decides the authentication setup.
• How you'll deploy the connected agents to users, since acquisition isn't automatic.
• How each agent's description and conversation starters are worded, because that's the routing logic.

Gotchas

• The user is prompted to confirm API plugin calls made by the connected agent, but any Adaptive Card goes to the calling agent. The user never sees the card or gets to use its dialog; the calling agent just reads the data in it.
• Manifest-declared connected agents are a different mechanism from the Copilot Chat API, which is for your own custom applications. They get conflated in design reviews.
• Several descriptions that overlap will send requests to the wrong agent. Vary the phrasing of conversation starters (matter, case, customer, issue) to match how people actually talk.
• A connected agent works in its own context window and only sees what the caller passes on, so don't rely on it having the wider conversation.

Consultant notes

• Sell the split as a reliability fix, not an architecture flourish. When answer quality falls after you add a fifth knowledge source, a connected agent is usually the cleaner repair than more instructions.
• Test routing with real user phrasing before UAT. Descriptions that read nicely to the build team are often too generic to win routing against a sibling agent.
• Sort ownership early. A chain of agents across teams means a chain of release cycles, and nobody likes finding out which team changed the description that broke routing.
• Check the Adaptive Card behaviour against any journey where users approve or fill in something; it won't surface the way they expect.

---

Worth revisiting when the manifest schema moves past 1.8 or A2A registration leaves its current shape.