Catalogue › Copilot Studio › multi-agent-design

Multi-agent design

Designs Copilot Studio solutions in which agents work together - child agents, connected agents reused across teams and calls to agents on other Microsoft platforms - deciding when to split, how the parent routes and passes context, which identity each uses, who owns each and how failures are contained. Use when one agent has grown too broad, when teams want to reuse each other's agents, or when an agent must hand work to another.

Department

Copilot Studio

Lifecycle

Envision, Deliver, Scale

Maturity

builder, scaler, ai-enterprise

Risk tiers

2, 3, 4

Platforms

copilot-studio, ai-foundry, m365-agents, power-platform

Editions

scale, enterprise

Reviewers

design-authority, security-privacy, responsible-ai

Status

draft

Copilot Cowork

Copilot Studio plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

As agents mature, a single agent often tries to do too much, or several teams build agents that would be more useful together. This skill designs Copilot Studio solutions in which agents cooperate: when to split work into child or connected agents, how a parent decides which agent to call and what context it passes, whose identity each agent uses, who owns each part, and how failures, loops and accountability are handled. Multi-agent designs usually go wrong when splitting is done for elegance rather than need, when context and permissions leak across agents, and when nobody owns the behaviour of the whole.

When to use

• One agent's scope, knowledge and tools have grown so broad that orchestration and testing are suffering.
• Several teams own agents in related domains and want users to reach them through one front door.
• An agent needs to call an agent built by another team, or on another Microsoft platform such as Foundry.
• A design proposes several agents and the split needs testing before build.

When not to use

• Designing a single agent's overall solution - use copilot-studio:studio-agent-design.
• Routing between topics, tools and knowledge within one agent - use copilot-studio:topics-and-orchestration.
• Agentic workflows with bounded autonomy built on Foundry - use ai-foundry:agentic-workflow-design.
• Hand-off from an agent to a person or contact centre - use copilot-studio:conversation-design.
• Formal review of the architecture - use design-authority:ai-design-review.

Questions to ask first

1. What problem does splitting solve - scope too broad, different owners, different release cycles, reuse - and could better descriptions or topics solve it instead?
2. Which agent does the user talk to, and does the user need to know other agents are involved?
3. What context passes between agents, and is any of it sensitive or beyond the receiving agent's purpose?
4. Whose identity does each agent use for knowledge and tools when called by another agent?
5. Who owns the end-to-end behaviour, and who owns each agent?

Required inputs

• The solution design for each agent involved, with knowledge maps and action registers.
• Ownership for each agent and agreement from owners of agents being reused.
• The authentication design for each agent.
• The risk tier of the combined solution, which is at least the highest tier of any component.

If the owner of a reused agent has not agreed to it being called, the design cannot depend on it. Record the dependency as unconfirmed.

Decision framework

Split only when at least one of these holds: different owners, different release cycles, a sub-domain whose instructions conflict with the rest, or genuine reuse by more than one parent. The combined solution takes the highest risk tier of its parts, and reviewers assess it as a whole.

Practitioner approach

Test the need before designing the split. Many "we need multiple agents" proposals are really one agent with overlapping descriptions or an unstructured knowledge layer. Try fixing the single agent first and record why that was not enough.

Design from the user's point of view. Usually one agent is the front door and others work behind it. Decide whether users should be told when another agent is involved; where a connected agent has a different owner or acts on different systems, telling users improves transparency and helps support.

Write a contract for each agent-to-agent call. Describe what the called agent does, when the parent should call it, the inputs it accepts, the outputs it returns, and what it does not do. Treat these descriptions as carefully as tool descriptions, because the parent's orchestrator chooses agents the same way it chooses tools.

Control context deliberately. Pass only what the called agent needs to do its job; do not forward the whole conversation by default. Sensitive data passed to an agent with a broader audience, different logging or a different environment is a data exposure. Record what passes in each direction.

Keep identity honest. Each agent should act with the end user's identity where possible, so that the combined solution cannot do more than the user could. Where a called agent uses a service identity, the parent's users inherit its reach; review that explicitly.

Contain failure. Decide what the parent does when a called agent is unavailable, slow or returns nothing useful, and prevent loops where agents call each other repeatedly. Set clear limits and fallbacks, and tell the user plainly when part of their request could not be completed.

Assign ownership at two levels: each agent's owner, and an owner for the end-to-end behaviour who coordinates releases, testing and incidents across agents. Version connected agents and agree change notice between teams, so a change to a shared agent does not silently break its callers.

Test end to end as well as per agent: routing between agents, context passed, identity at each step, failures of each dependency and the user's experience across the whole conversation.

Outputs

• A multi-agent design: agents, pattern for each, the reason for the split, and a diagram of calls and context flows.
• An agent contract for each agent-to-agent call: purpose, when called, inputs, outputs, exclusions and version.
• An identity and context map showing what passes between agents and under which identity each acts.
• Ownership at agent and end-to-end level, recorded in the studio-solution-design.
• End-to-end test cases including dependency failures and loop prevention.

Microsoft platform considerations

Child agents, connected agents, agent-to-agent protocols and calls to agents on other Microsoft platforms are developing quickly and several capabilities may be in preview. Check ms-copilot-studio-guidance, ms-agents-extensibility and ms-agents-compare for what is currently supported, and ms-copilot-studio-security-governance for admin controls over which agents may be connected. Do not commit to a pattern without confirming it in the source records.

Adoption considerations

Users want one place to ask. A well-designed front door with specialist agents behind it can simplify adoption, but only if the experience feels coherent; test with users, not only with the teams who own each agent.

Knowledge considerations

Each agent keeps its own knowledge with its own owners. Avoid connecting the same source to several agents with different descriptions, which produces conflicting answers across the solution.

Security and privacy considerations

Context passed between agents, service identities in called agents and data crossing environments or platforms are the main exposures. Map them, minimise them and send the map to security-privacy:data-exposure-review and security-privacy:connector-review.

Responsible AI considerations

Accountability blurs when several agents contribute to an outcome. Make one owner accountable for the end-to-end behaviour, keep a human decision point for outcomes affecting people, and make it possible to trace which agent produced which part of an answer or action.

Evaluation requirements

Evaluate each agent on its own and the solution end to end, including routing between agents, context minimisation, identity at each step, dependency failures and loops. From tier 3, the evaluation-quality reviewers agree the end-to-end evaluation.

Value measures

Track end-to-end resolution, failures caused by dependencies and reuse of connected agents across parents, owned by the end-to-end owner and reported at solution level.

Scale notes

Starter

Not usually needed; keep to single agents and fix scope and descriptions first. Child agents within one owner's agent are the most a starter organisation should attempt.

Scale

Child agents for distinct sub-domains, and a small number of connected agents with contracts, owners and versioning.

Enterprise

A catalogue of reusable connected agents with contracts and owners, end-to-end owners for composite solutions, and design authority review for every new cross-team or cross-platform call.

Hand-offs

• To copilot-studio:studio-agent-design for each agent's design.
• To ai-foundry:agentic-workflow-design where Foundry agents take part.
• To security-privacy:data-exposure-review with the identity and context map.
• To copilot-studio:studio-testing-and-evaluation with end-to-end test cases.

Reviewer gates

design-authority reviews every multi-agent design for necessity and supportability, security-privacy reviews context and identity flows, and responsible-ai reviews accountability where outcomes affect people. The solution is reviewed at the highest tier of its parts; unreviewed context flows to an agent with broader access are a blocking finding.

Failure modes

• Agents are split for neatness, doubling ownership and testing effort without solving a real problem.
• The whole conversation is forwarded to a connected agent with a wider audience and different logging.
• A connected agent changes without notice and its callers start failing.
• Two agents call each other in a loop, and nobody owns the end-to-end behaviour.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Split an agent without recording the problem the split solves.
• Pass more context between agents than the called agent needs.
• Depend on another team's agent without its owner's agreement and a versioned contract.
• Leave a composite solution without an owner for its end-to-end behaviour.