Multi-agent orchestration patterns and best practices

Generative orchestration also supports multi-agent systems, where one agent calls other agents. When you break problems into multiple specialized agents, you make your application more modular, scalable, and manageable.

Inline agents

Inline agents, also known as child agents, are small, reusable workflows within the same agent. They're often just topics that the main agent uses as subroutines. For example, the main agent can call a "Translate Text" topic as one step in a larger plan. Inline agents share context with the main agent, so passing data between them is simple.

Best practice: Keep inline agents focused on a single responsibility and test them well.

Connected agents

Connected agents are separate agents with their own orchestration, tools, and knowledge. The main agent delegates part of a request to a child agent. For example, an IT agent calls a Sales agent to get information about pricing. Connected agents enable modularity and domain separation, and can bypass plan limits. They might have different privileges or knowledge, so apply governance and audit controls.

However, using connected agents requires careful governance:

• Orchestration: The parent orchestrator should have clear criteria for when to hand off to a connected agent. The orchestrator usually hands off when the user's intent matches the connected agent's domain. To assist this process, describe the connected agent's purpose clearly in the parent's configuration. Treat the entire connected agent as an agentic "tool" with a description, from the perspective of the parent.

• Data handoff: You must manage data handoff. Decide what context from the parent to pass to the connected agent. Copilot Studio passes along the conversation history by default when one agent calls another, so the connected agent understands the previous context of the conversation. But you might need to pass specific parameters too. For example, if the main agent already knows the user's name from earlier, it might send that to the connected agent to avoid asking again.

• Security: The connected agent might have access to things the parent agent doesn't. Ensure that calling the connected agent doesn't inadvertently bypass restrictions. For example, if the parent agent isn't allowed to delete records but the connected agent can, the parent agent shouldn't call the connected agent in scenarios where deletion might happen without proper approval. Treat a connected agent call like any other powerful action. If it's doing something sensitive, subject it to the necessary checks or user consent.

• Audit and monitoring: Log when a connected agent was invoked and what it did. Since it's a separate agent, you have separate transcripts for it. It's important for debugging to correlate the parent and connected sessions. Typically, identifiers in the telemetry link the two.

When to separate agents

Don't create a separate agent for every subtask. Use separate agents if the subtask:

• Is complex enough to have its own suite of tools or knowledge (different domain of expertise)
• Requires different governance rules or access controls than the main agent
• Can be reused in many different main agents (so it's like a service agent)

If none of those conditions apply, a simple inline agent might handle the job well while also being simpler than a full connected agent. Separate agents introduce overhead to the system. There is a slightly longer execution time due to context switching, and complexity in maintaining multiple agents. So use them judiciously. For a practical approach, start with one agent. Then only split into multiple agents when you clearly see a need for modularity or a boundary a single agent shouldn't cross.

Best practices for multi-agent orchestration

The following best practices apply when authoring instructions for parent and subagents in a multi-agent setup.

1. Single response principle

Ensure only one agent talks to the user per turn. In a multi-agent setup, the parent agent is the only one that should deliver the final response. Subagents are researchers, not responders.

• Do: Add to parent instructions: "You're the only agent that communicates with the user. Combine findings from all child agents into a single response."
• Don't: Leave it ambiguous. Without explicit guidance, subagents reply to the user directly, causing duplicate or partial messages.

2. Subagent instructions must declare their role

Always tell subagents they're subagents. Subagents don't inherently know they're part of an orchestration. Without explicit guidance, they behave as standalone agents and send messages directly to the user.

• Do: Add to every subagent's instructions: "You're a subagent. Do NOT reply to the user directly. Your job is to search for information and return your findings to the parent agent. The parent agent handles all communication with the user."
• Don't: Assume subagents figure out the orchestration pattern on their own.

3. Use clear, direct language in instructions

Always use directive language. Avoid soft or polite phrasing. The platform injects system-level instructions by using strong language (MUST, DO NOT, NEVER). Instructions written with soft language ("please try to," "you should," "it would be good to") lose priority when they conflict.

• Do: "NEVER reply to the user directly. ONLY return your findings."
• Do: "There must be exactly one final response per user question."
• Don't: "Please try to avoid sending messages to the user and instead return your findings."
• Don't: "Ideally, we want a single combined answer."

4. Use one knowledge source per subagent (no overlap)

Assign distinct, nonoverlapping knowledge sources to each subagent. If two subagents search the same knowledge base, one subagent finds the answer first. The second subagent either returns duplicate results or skips its search entirely, adding no value.

• Do: CA-1 searches Knowledge Source A (for example, HR policies). CA-2 searches Knowledge Source B (for example, IT documentation).
• Don't: Give both subagents access to the same documents, Dataverse tables, or SharePoint sites.
• Note: If you only have one knowledge source, use a single agent with knowledge instead of splitting into two subagents. Multi-agent adds value only when sources are genuinely different.

5. Use accurate and distinct descriptions for subagents

Write clear, distinct descriptions for each subagent visible to the parent. The parent agent uses subagent descriptions to decide routing. If descriptions are vague, identical, or inaccurate, the parent can't make good routing decisions.

• Do: CA-1: "Searches HR policy documents for employee-related questions." CA-2: "Searches IT knowledge base for technical support questions."
• Don't: Give both agents the same description when they serve different domains.
• Don't: Use generic descriptions like "This agent can help with questions."

6. Parent instructions must define the orchestration pattern

Tell the parent agent how to orchestrate. Don't just say "use child agents." The parent needs explicit instructions on the pattern: invoke agents, wait for results, combine, then respond.

• Do: "When the user asks a question: 1. Invoke both child agents to gather information. 2. Wait for both child agents to return their findings. 3. Combine the findings into a single, unified response. 4. Deliver exactly one response to the user. Child agents must not reply to the user directly."
• Don't: "When the user asks a question, invoke child agents and get the response from both sources and give a single combined answer." (Too vague. Instruction doesn't tell subagents to stay silent.)

7. Include the "no direct reply" directive in the task delegation

Even with clear subagent instructions, adding reinforcement in the delegated task provides a safety net.

• Do: Add to parent instructions: "When delegating to a child agent, always include in the task: 'Return your findings only. Don't reply to the user.'"
• Don't: Rely solely on the subagent's own instructions. The task context gives the subagent more signals that reinforce the pattern.

8. Test with domain-mismatch queries

Always test with questions that don't match any subagent's domain. This testing reveals whether subagents gracefully return "no information found" versus returning information that might be incorrect, getting hung up, or sending confusing messages.

• Do: Test with queries outside all subagent domains (for example, ask about weather when agents handle HR and IT).
• Do: Verify the parent handles "both agents found nothing" gracefully.
• Don't: Only test with simplest case queries that perfectly match one subagent's domain.

9. Prefer ask over inform when expecting a follow-up

Use question/ask-style interactions when expecting the user to respond. Use inform/send-style only for final one-way messages. If the agent asks the user something by using a one-way message (inform), the user's reply goes back to the parent planner as a brand-new query. In this case it's better to continue the same conversation with the subagent.

• Do: Write instructions like: "If you need clarification, ask the user a question and wait for their response."
• Don't: Write instructions like: "Inform the user about the options and let them choose." "Inform" signals a one-way message, while "ask" signals a two-way exchange.

Quick reference checklist

Related information

• Add other agents overview
• Add a child agent
• Connect to an existing Copilot Studio agent
• Connect to a Microsoft Foundry agent
• Connect to a Microsoft Fabric Data agent
• Connect to a Microsoft 365 Agents SDK agent
• Connect an agent available over the Agent2Agent (A2A) protocol