Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Copilot Studio lets you enhance your agents by connecting them to other agents. Agents can hand off user interactions to each other or respond to autonomous triggers. Scale out your solutions efficiently and effectively by using modular agents tailored to particular tasks or data sets.
There are several ways to add other agents to your existing Copilot Studio agent:
- Create child agents. Child agents are lightweight agents within your existing agent.
- Connect to other Copilot Studio agents within your environment.
- Connect to external agents:
All agents you add to an agent appear on its Agents page.
Connecting to agents built with Microsoft Foundry, Microsoft Fabric, Microsoft 365 Agents SDK, and agents available via the A2A protocol, is currently available in public preview.
Important
This article contains Microsoft Copilot Studio preview documentation and is subject to change.
Preview features aren't meant for production use and may have restricted functionality. These features are available before an official release so that you can get early access and provide feedback.
If you're building a production-ready agent, see Microsoft Copilot Studio Overview.
Considerations for multi-agent solution design
Multi-agent orchestration can be powerful, but it's not always necessary and you should consider carefully before adopting a multi-agent approach to your solution. The following considerations are important when deciding if and how you should utilize child agents within your main agent, or connect your agent to a separate agent.
When to use child agents
Create child agents within your agent when:
- You're building a single use case to respond to a single intent or complete a single task (for example, create a ticket, check a status, book a flight).
- A single developer or a small, cohesive team manages the entire agent solution.
- You want to logically group tools, instructions, and knowledge into clearly defined subagents within a larger agent.
- You don't need separate configuration settings, authentication, or deployment capabilities for the subagents.
- You don't intend to publish these agents separately or make them available independently.
- You don't need to reuse the agent across multiple agents.
When to consider breaking your agent into multiple connected agents
You should consider breaking your agent into multiple connected agents when the ability for your agent to differentiate between the available tools, based on their name and description, starts to degrade.
As a rule of thumb, this degradation in performance can happen when your main agent has more than 30-40 choices of action (tools, topics, and other agents). However, degraded performance can also happen in an agent with a smaller number of tools with close descriptions can also cause this issue.
Ultimately, you should assess your agent's performance against your own evaluations. While you should always start by reviewing your descriptions to see if further differentiation is possible, splitting functionality across multiple agents can help to maintain precision.
Other reasons you might consider splitting your solution across multiple connected agents include:
- Multiple teams or developers manage different agents independently.
- You need to publish and maintain agents separately, and make them available directly on independent channels, as well as being usable by other agents.
- Agents must have their own dedicated settings, such as which model the agent is configured to use.
- You need independent application lifecycle management (ALM) processes for each agent.
- You want to make your agent reusable (that is, connected to and usable by more than one agent).
You can mix connected agents and child agents in your solution. For example, you could break out parts of your solution into separate agents that users could also access directly. Each of those agents could have their own child agents for key purposes.
Potential impacts of multi-agent solutions
Having your solution split across multiple agents can:
- Increase latency due to the extra orchestration hops that are introduced. For example, the main agent orchestration identifies a connected agent that can handle the query. The connected agent then runs using its own orchestration layer to determine how to handle the query with its available tools.
- Increase the testing, management, and governance surface area for a solution.
Redirect to an agent from a topic
You can explicitly redirect to a child or connected agent from within a topic. Once the agent is done, the originating topic where you redirected from resumes. You can insert more nodes after the agent redirect node as needed.
Select the Add node icon under the node after which you want the redirect to occur, select the agent you want to redirect to in the Add an agent sub menu.
Some agents support passing input and retrieving output variables, such as when you configure inputs and outputs on a child agent. If inputs are available, you can add them via the node and set a value for each one. Each output for the agent automatically has a topic variable created where the values from the outputs are placed.
You can now save and test your topic to ensure the agent redirect is working as desired.
Note
Redirecting to Fabric Data agents isn't currently supported.
Manage existing connected agents
You can make any child or connected agent momentarily unavailable or remove it entirely from your solution.
Temporarily make a child or connected agent unavailable to your main agent
On the Agents page for your main agent, use the Enabled toggle next to the agent you want to turn on or off.
Turning off a child agent or a connected agent makes it inactive—that means it doesn't respond to users or triggers.
Delete a child agent
On the Agents page for your main agent, select the More icon (…) next to the child agent you want to remove and select Delete.
Remove a connected agent
On the Agents page for your main agent, select the More icon (…) next to the connected agent you want to remove and then select Disconnect agent.
Reference a child agent or connected agent in your main agent's instructions
It can be useful, especially for autonomous agents, to be able to reference child agents you created or other agents you connected. With this method, you can break down a long instruction set for an agent into smaller focused pieces.
Go to the Overview page for your main agent.
In the Instructions field, enter a slash (/) and select the desired agent. Copilot Studio automatically saves the instructions.
Test your agent. When you use the test panel in Copilot Studio, you should see your agent referenced in the activity map.
Known limitations
The following limitations apply to child and connected agents.
Fabric Data agents can't currently be redirected to using the Redirect node within a topic. Fabric Data agents can't currently be explicitly referenced within instructions.
Fabric Data agents don't currently function when your main agent is deployed to Microsoft 365 Copilot.
Citations might not always be maintained when passing outputs back from an agent back to a calling agent.
While child and connected agents respect the Use general knowledge setting of the main agent, by not using general knowledge as part of answers generated by the built-in knowledge tool, they might sometimes use underlying language model knowledge when generating questions or messages.
You can't connect to an existing agent that is already connected to other agents.