Microsoft 365 Copilot: Connected Agents

Key insights

• Connected Declarative Agents: A demo shows how Microsoft 365 Copilot can let one declarative agent call or hand off work to another so a single conversation can solve complex tasks.
  Paolo Pialorsi demonstrated an orchestrator agent delegating to specialized worker agents to combine tools and knowledge.
• Declarative agents: Agents are defined by simple instructions, embedded knowledge, and actions you configure with low-code or developer tools.
  They run on Copilot infrastructure, so you do not need extra hosting.
• worker_agents: The manifest property that links agents is part of declarative agent schema version 1.6 and tells the active agent which worker agents it can call.
  The active agent chooses workers using name, description, and conversation starters in the manifest.
• title ID: Each connected agent must be identified by a title ID and installed by the user before use.
  Agent-to-agent exchanges are text-only, and API plugin calls require explicit user confirmation.
• Modularity: Connected agents let each agent focus on a single domain, enable reuse of specialized logic, and provide a seamless Copilot conversation while routing happens behind the scenes.
  They inherit Microsoft 365 security, compliance, and Responsible AI controls.
• MCP: For scenarios that go beyond declarative-to-declarative links, use MCP or API plugins to connect to external systems or agent-like services.
  Developers should get the worker title IDs, upgrade manifests to schema 1.6, and test API prompts and adaptive card handling in the active agent flow.

Overview of the demo

The Microsoft-led demo, presented by Paolo Pialorsi during a community call, showcases how Connected Declarative Agents extend Microsoft 365 Copilot with a modular agent architecture. In the video, an orchestrator agent delegates tasks to specialized worker agents, combining platform tools and embedded knowledge to answer complex business queries. Consequently, the user sees a single conversational flow even when multiple agents collaborate behind the scenes.

The presentation emphasizes practical examples drawn from Microsoft 365 and Power Platform scenarios, and it highlights how the active agent can automatically route work to other agents. Moreover, the demo clarifies that these connected agents are strictly other declarative agents, defined by manifest metadata and governed by specific properties. As a result, the capability is both a usability enhancement and a framework-level change for Copilot extensibility.

How connected declarative agents work

At the core of the approach are declarative agents, which combine instructions, knowledge, and actions to extend Copilot without additional hosting. The new feature allows one declarative agent to call or hand off to another through the worker_agents property in the agent manifest, and the exchange appears to the user as an agent-to-agent interaction. Furthermore, agents identify each other by a title ID, and users must install each connected agent before use.

Communication between agents is text-only, so files and images do not pass directly between agents; when a connected agent needs to call an external API, the user must confirm the action. Additionally, adaptive card responses from a worker agent are surfaced by the active agent rather than shown directly, which helps maintain a coherent user experience. Thus, the system balances modular delegation with a controlled surface for user interactions.

Key capabilities and tradeoffs

The key benefits include increased modularity and reuse: specialized agents can focus on domain-specific logic while a general agent maintains the conversational flow. This modular design reduces duplication and lets organizations compose capabilities more cleanly, but it also introduces coordination complexity between manifests, agent identities, and installation management. Consequently, teams will need to weigh the long-term maintainability gains against the upfront effort to design and register multiple cooperating agents.

Security and compliance remain platform-native advantages because declarative agents run on Microsoft 365 Copilot infrastructure and inherit existing controls. However, the requirement that users explicitly install connected agents and confirm API calls can add friction to adoption and create usability tradeoffs. Therefore, organizations must balance the desire for tighter control and visibility with a smooth user experience, choosing where to accept deliberate prompts for confirmation versus where to optimize for seamless automation.

Developer considerations and implementation challenges

From a developer perspective, the new manifest support and the declarative agent schema version 1.6 introduce clear steps for defining connections, but they also raise practical questions about lifecycle and discovery. Developers must manage title IDs, craft conversation starters and descriptions so the active agent can select an appropriate worker, and ensure knowledge and actions align across agents. As a result, good documentation and consistent naming become important to prevent misrouting or unexpected behavior.

Moreover, the text-only channel between agents limits some integration patterns, and teams that need richer data exchange must consider alternative approaches such as MCP or API plugins. While those alternatives can connect to external systems or agent-like services, they require additional safeguards and a different integration model. Therefore, developers will need to evaluate whether the declarative-to-declarative approach fits their scenario or if hybrid solutions better balance capability and complexity.

Implications for organizations and next steps

For organizations, the feature offers a path to scale Copilot capabilities through a library of specialized agents that remain consistent with Microsoft 365 governance. Yet, adopting connected agents means investing in agent design, installation management, and user education about permissions and confirmations. In short, the approach creates a more modular future for Copilot but requires careful planning to avoid friction in deployment and use.

Looking ahead, teams should prototype small end-to-end scenarios to validate how orchestrator and worker agents interact, and then iterate to refine manifests, conversation starters, and confirmation flows. By doing so, organizations can measure the tradeoffs between modularity and operational overhead and decide whether to adopt the declarative agent pattern, the plugin model, or a hybrid of both. Ultimately, this demo signals a significant step toward more composable Copilot experiences while highlighting real-world tradeoffs that decision makers must manage.

Keywords

Connected Declarative Agents for Microsoft 365 Copilot, Microsoft 365 Copilot agents, Declarative agents Copilot, Connected agents Microsoft 365, Copilot agent development, Copilot Microsoft Graph integration, Copilot extensibility and connectors, Enterprise AI assistants Microsoft 365