Multi-Agent Solutions: Design and Agent Reuse
Design patterns for multi-agent solutions, orchestration topologies, and reusing existing Copilot Studio agents as connected agents.
Why multi-agent? The limits of a single agent
Think of a single agent like a solo receptionist at a hotel.
One person can answer the phone, check guests in, and deal with complaints — but when the lobby is packed, they become a bottleneck. Now imagine a team: one at the front desk, one on the phone, one handling VIP guests. Each person is great at their job, and a manager routes guests to the right person. That is multi-agent design — multiple specialist agents coordinated by an orchestrator.
In Copilot Studio, a “connected agent” is an existing agent you plug into another agent’s workflow. You do not rebuild it — you reuse it. The orchestrator decides which specialist handles each request.
When to use multi-agent vs single agent
Not every scenario needs multiple agents. A single well-designed agent with good topic routing handles many use cases. Multi-agent becomes essential when agents need different knowledge, permissions, or ownership.
| Signal | Single agent | Multi-agent |
|---|---|---|
| Knowledge sources | One or two data sources | Multiple domain-specific knowledge bases |
| Security | Same permissions for everything | Different DLP policies or auth per domain |
| Team ownership | One team builds and maintains | Separate teams own HR, Finance, IT agents |
| Complexity | Under 30 topics | Hundreds of topics across domains |
| Reuse | Agent is purpose-built | Existing agents already solve part of the problem |
Exam tip: the reuse signal
The exam loves questions where an existing agent already exists. If the scenario says “the HR team already has a working Copilot Studio agent,” the correct answer is almost always to connect it as a connected agent — not rebuild its functionality in the orchestrator.
Multi-agent design patterns
Three patterns dominate multi-agent design. The exam expects you to recognise which pattern fits a scenario.
| Feature | How it works | Best for | Copilot Studio support |
|---|---|---|---|
| Orchestrator + Specialists | One primary agent routes to specialist agents based on intent classification | Enterprise help desks, multi-department bots where a single entry point serves many domains | Native — add connected agents to an orchestrator agent's topic routing |
| Peer-to-Peer | Agents call each other directly without a central coordinator | Loosely coupled systems where Agent A triggers Agent B for a subtask then continues | Limited — requires A2A protocol or Power Automate cloud flows to chain agents |
| Hierarchical | Multiple layers of orchestrators — a top-level agent routes to mid-level orchestrators, which route to specialists | Large enterprises with divisions containing departments containing teams | Supported via nested connected agents — orchestrator A connects to orchestrator B which connects to specialists |
Deep dive: orchestrator + specialists in practice
The orchestrator pattern is the most common in Copilot Studio. Here is how it works at runtime:
- User sends a message to the orchestrator agent (deployed in Teams, web, etc.)
- Orchestrator classifies intent using its topic triggers — “I need to update my tax code” matches an HR trigger phrase
- Orchestrator routes to the HR connected agent — the conversation context transfers to the HR agent
- HR agent processes the request using its own knowledge sources, connectors, and security context
- HR agent returns the result to the orchestrator, which delivers it to the user
The user never knows they are talking to multiple agents. From their perspective, it is one seamless conversation.
Connected agents in Copilot Studio
A connected agent is any agent — built in Copilot Studio, Foundry, Fabric, or exposed via A2A — that you add to another agent’s configuration. The hosting agent becomes the orchestrator.
How to add a connected agent (Copilot Studio to Copilot Studio):
- Open the orchestrator agent in Copilot Studio
- Navigate to Settings then Connected agents
- Select Add a connected agent then Copilot Studio agent
- Choose the agent from the list (must be in the same environment or shared)
- Configure the trigger description — this tells the orchestrator when to route to this agent
- Set the agent’s scope — what topics it handles and what context it receives
Scenario: Priya builds an orchestrator for AgentForge
AgentForge’s recruitment client has three existing Copilot Studio agents: an HR policy agent that answers benefits and leave questions, a Finance agent that handles expense approvals, and an IT helpdesk agent that resets passwords and provisions accounts.
Instead of rebuilding all three, Priya creates a new orchestrator agent called “Employee Hub.” She adds each existing agent as a connected agent with clear trigger descriptions:
- HR Agent: “Questions about leave, benefits, payroll, HR policies”
- Finance Agent: “Expense reports, budget approvals, procurement”
- IT Agent: “Password resets, software requests, hardware issues”
When an employee asks “How do I submit an expense report?”, the orchestrator matches the intent to the Finance trigger and routes the conversation. Each team continues to own and update their specialist agent independently — Priya only manages the routing logic.
Key design decisions
When designing multi-agent solutions, consider these factors:
| Decision | Options | Guidance |
|---|---|---|
| Routing method | Topic triggers, AI classification | Use trigger descriptions for predictable routing; AI classification for ambiguous intents |
| Context passing | Full conversation, summary only | Pass only what the specialist needs — minimize data exposure |
| Error handling | Fallback to orchestrator, escalate to human | Always define a fallback when a connected agent fails or times out |
| ALM strategy | Shared solution, separate solutions | Separate solutions let teams deploy independently; shared solutions enforce version alignment |
Exam tip: multi-agent equals different knowledge or permissions
The exam’s go-to signal for multi-agent is: different agents need different knowledge sources or security permissions. If a scenario describes one agent that needs access to HR data (restricted) and another that needs public product info (open), multi-agent with separate DLP policies is the answer.
Priya's client has an existing HR agent, Finance agent, and IT agent — all built in Copilot Studio. She needs a single entry point for employees. What should she build?
When is multi-agent design most appropriate?
In the orchestrator + specialists pattern, what happens when a user asks 'How do I reset my password?'