11.1 Design Multi-Agent Solutions

11.1 Design Multi-Agent Solutions

Quick Answer: Design multi-agent solutions when specialists, reuse, independent ALM, or distinct governance beat one overloaded agent. In Copilot Studio you compose child (inline) agents and connected agents so a main orchestrator hands off work. Invest first in description quality and when-to-split judgment—not in maximum agent count.

AB-620 Domain 2 includes Configure multi-agent collaboration from Copilot Studio, starting with design multi-agent solutions. Microsoft’s official framing: enhance agents by connecting them so they hand off interactions or respond to autonomous triggers, scaling with modular agents tailored to tasks or data sets. Everything you add appears on the main agent’s Agents page.

Mental model: orchestrator + specialists

Think of the main agent as an orchestrator and every child or connected agent as a specialist capability:

1. The user (or trigger) reaches the main agent.
2. Generative orchestration evaluates topics, tools, knowledge, and other agents using names and descriptions.
3. When a specialist matches, the main agent delegates (generative handoff) or a topic redirects explicitly.
4. The specialist runs its own tools, knowledge, and (for connected agents) orchestration.
5. Results return so the parent can continue—ideally as the only speaker to the user for that turn.

Exam trap: Multi-agent is not “always better architecture.” Microsoft explicitly says multi-agent orchestration is powerful but not always necessary. Start with one agent; split when modularity or boundaries are clear.

Child agents vs connected agents

Microsoft documents two composition styles you must distinguish on AB-620:

When Microsoft says to use child agents

Create child agents when:

• You are building a single use case for a single intent or task (create a ticket, check status, book a flight).
• A single developer or small team owns the whole solution.
• You want to logically group tools, instructions, and knowledge into clear subagents.
• You do not need separate configuration, authentication, or deployment for subagents.
• You do not intend to publish subagents separately or make them independently available.
• You do not need reuse across multiple parent agents.

When to break into multiple connected agents

Consider connected agents when tool differentiation degrades: the main agent struggles to choose among tools/topics/agents based on name and description. Microsoft’s rule of thumb: review around more than 30–40 choices of action (tools, topics, and other agents)—and also when a smaller set has similar descriptions. Always validate with your own evaluations; first improve descriptions before splitting blindly.

Other strong reasons to connect separate agents:

• Multiple teams manage agents independently.
• Agents must be published and maintained separately, available on independent channels and callable by others.
• Agents need dedicated settings (for example model configuration).
• You need independent application lifecycle management (ALM) per agent.
• You want the agent reusable across more than one parent.

You can mix child and connected agents: expose some specialists as connected agents users can open directly, while those specialists keep their own child agents for internal tasks.

Multi-agent vs single “fat” agent

Potential impacts Microsoft calls out: multi-agent can increase latency (extra orchestration hops: parent selects agent, child orchestrates again) and increase testing, management, and governance surface area. Design for those costs deliberately.

Description quality (the silent exam skill)

From the parent’s point of view, a connected or child agent is an agentic tool. Write descriptions that answer: When should the parent invoke this specialist, and for what?

Best practices (Microsoft multi-agent guidance):

1. Single response principle — Parent is the only agent that talks to the user per turn; subagents are researchers, not responders.
2. Subagent role declaration — Tell subagents they must not reply to the user directly; return findings to the parent.
3. Directive language — Prefer MUST / NEVER / ONLY over soft “please try to.”
4. One knowledge source per subagent, no overlap — Overlapping knowledge causes races, duplicates, or skipped work.
5. Accurate, distinct descriptions — Parent routes on them.
6. Parent defines the orchestration pattern — Invoke → wait → combine → one response.
7. Reinforce “no direct reply” in delegated tasks.
8. Test domain-mismatch queries — Ensure graceful “nothing found,” not inventiveness.
9. Prefer ask over inform when a follow-up is expected so conversation continuity stays correct.

Handoff mechanics you should design for

• Agents page — Add, enable/disable, delete child agents, or Disconnect connected agents.
• Topic redirect — Explicitly redirect to a child or connected agent; when done, the originating topic can resume and may map inputs/outputs when supported. (Fabric Data agent redirect limitations belong to the Fabric chapter; know redirects are a first-class design tool for Copilot Studio specialists.)
• Instructions with / — Reference agents inside parent instructions for autonomous or structured plans.
• Conversation history — Default pass-through helps context; some designs clear history pass-through so only the explicit task is shared (covered deeply in connected-agent integration).
• Security — Connected agents may hold higher privileges than the parent. Treat a specialist call like a powerful action: do not let the parent bypass approval simply because “another agent can delete.”
• Audit — Expect separate transcripts/telemetry; correlate parent and specialist sessions when debugging.

Realistic design scenarios

Scenario A — Split after tool sprawl. Contoso’s employee assistant grew to 45 tools and 12 topics with overlapping names (“Update request,” “Change request,” “Service request”). Routing quality falls. The team first rewrites descriptions, then extracts HR policy Q&A and IT break/fix into connected agents with independent knowledge and ALM, leaving the parent as a thin orchestrator plus shared identity topics.

Scenario B — Child agents are enough. A single travel team owns a booking agent. Subtasks—validate traveler profile, price itinerary, create expense draft—are child agents inside one solution. No separate channels, no multi-team ALM. Multi-connected architecture would only add hops.

Scenario C — Wrong split. Two child agents both search the same SharePoint HR site. Users get duplicate partial answers. Correct design: one specialist for that knowledge, or one agent with knowledge—not multi-agent theater.

Design decision checklist (exam + project)

1. Is the subtask a different domain with its own tools/knowledge?
2. Do governance or privileges differ from the parent?
3. Is the specialist reusable or independently published?
4. Does the team need independent ALM?
5. Can you write a non-overlapping description the parent can trust?
6. Have you accepted extra latency and wider test surface?
7. Will the parent enforce single response and subagent silence?
8. Did evaluations still fail after description cleanup alone?

Success checklist

• Explain orchestrator/specialist and handoff modes (generative, redirect, instruction reference).
• Contrast child vs connected with ALM, reuse, auth, and team ownership.
• Defend when not to multi-agent.
• Treat description quality as a routing control plane.
• Name latency, governance, security, and single-response best practices.

Master design judgment here and the next two sections—Foundry integration and existing Copilot Studio agent connection—become configuration of a pattern you already know how to justify.