Update (September 2026): AI-900 and AI-102 retired on June 30, 2026. Their replacements, AI-901 (Azure AI Fundamentals) and AI-103 (Azure AI App and Agent Developer Associate), are the current exams. For the current path, see the AI-103 Study Guide.
June 2026 update: This guide reflects the multi-agent orchestration patterns available in the Microsoft Agent Framework (the umbrella SDK that ships as semantic-kernel on PyPI) as of June 2026, and the AI-103 official course content (AI-103T00-A) Learning Path 2 Module 8.
If you build one agent, you write a prompt. If you build two agents, you write an orchestration. The moment you have more than one model in your application, you have to make architectural choices that did not exist before: who talks first, who decides when the conversation is finished, who owns which tools, what happens when two agents disagree, and how the final answer gets composed.
The Microsoft Agent Framework ships five named patterns for exactly these decisions, and AI-103 tests all five. Many candidates can recite the names but cannot tell you which pattern to choose for a given scenario, which is the part the exam actually cares about.
This guide fixes that. We cover what multi-agent orchestration is, why you would use it instead of a single agent, the five patterns in depth (Sequential, Concurrent, Group Chat, Handoff, and Magentic) with a working code shape for each, the decision matrix that tells you which one to pick, where teams get stuck in production, and exactly which parts of LP2 Module 8 you must internalise before sitting AI-103.
TL;DR
Multi-agent orchestration is the practice of composing two or more AI agents into a single system that solves a task no individual agent could solve as well alone. The Microsoft Agent Framework ships five patterns: Sequential (agents in a fixed pipeline), Concurrent (agents work in parallel and results are merged), Group Chat (agents converse under a manager that picks who speaks next), Handoff (one agent transfers control to a specialist), and Magentic (a research-derived planner-driven pattern that adapts the plan as it goes). All five are tested in AI-103 Learning Path 2 Module 8, weighted inside the "Integrate and Deploy AI Solutions" exam domain at 20-25% of the exam. The pattern you choose follows from the task shape, not from preference.
What multi-agent orchestration actually is
Multi-agent orchestration is the layer in your application that decides which agent runs, when, with what context, and how their outputs combine. In the Microsoft Agent Framework, the orchestration is a first-class object: you instantiate an orchestration class (SequentialOrchestration, ConcurrentOrchestration, GroupChatOrchestration, HandoffOrchestration, or MagenticOrchestration), give it a list of member agents, and invoke it with a task. The orchestration runs the agents according to its pattern and returns a final result.
The orchestration object is the thing that distinguishes a multi-agent system from "two agents that happen to be in the same code base." Without orchestration, you are writing imperative glue: call agent A, parse output, conditionally call agent B, merge by hand. With orchestration, the pattern is declarative and the framework handles the wiring, the retries, the context propagation, and the telemetry.
That distinction matters for AI-103. The exam keeps asking the same underlying question in different scenario clothing: given this task description, which orchestration pattern is correct? It is rarely a trick question. Each pattern has a clean signature, and the trigger words in the scenario tell you which one fits.
Why multi-agent at all? (And when not to)
The default for a new project should be a single agent with tools. A single GPT-4o agent that calls a few well-chosen MCP servers can solve a remarkable range of tasks, and it is simpler to debug, cheaper to run, and easier to reason about than any multi-agent system.
You graduate to multi-agent when one of three things becomes true.
The task naturally decomposes into specialised roles. Research, drafting, and editing are different skills that benefit from different prompts and different tool surfaces. Triage, billing, and technical support require different tool access and different escalation policies. When your single agent's system prompt starts looking like a job description for three different people, split them.
The task requires multiple independent perspectives that must be combined. A bull, bear, and neutral analyst examining the same earnings report will reach different conclusions, and the combination is more useful than any individual view. A single agent prompted to "consider three perspectives" tends to produce a mush; three agents prompted independently produce real disagreement that you can synthesise.
The task has an open shape that requires planning and replanning. Research tasks, software-engineering tasks, and incident-response tasks rarely follow a script. You start somewhere, learn something, adjust the plan, learn more, adjust again. A single linear agent struggles; a planner-driven multi-agent system thrives.
If none of these apply, if the task is small, well-scoped, and lives in one specialist's head, stay with a single agent. The exam asks scenario questions where candidates over-engineer by reaching for orchestration when a single agent would do, and the correct answer is "no orchestration needed."
The five patterns at a glance
Memorise this table. Every AI-103 multi-agent scenario question reduces to picking a row.
| Pattern | One-line shape | Best for | Decision authority | Order of execution |
|---|---|---|---|---|
| Sequential | A then B then C, each consumes the previous | Fixed-pipeline tasks (research, draft, edit) | Hard-coded by the developer | Strictly linear |
| Concurrent | A, B, C in parallel, results aggregated | Independent perspectives on the same input | Hard-coded by the developer | Parallel |
| Group Chat | Agents converse, a manager picks who speaks next | Consensus and iterative refinement tasks | Group chat manager (configurable) | Dynamic, round by round |
| Handoff | A then B (or A then C) based on routing logic | Triage and specialist escalation | Each agent decides who to hand off to | Dynamic, single active agent at a time |
| Magentic | Planner agent maintains a ledger, delegates to specialists, replans | Open-ended tasks where the plan emerges | Planner agent (LLM-driven) | Adaptive, replans on every step |
The rest of this guide unpacks each pattern with a working code shape, a real scenario, and the production gotchas. If you only have time to internalise one section, internalise the decision matrix near the end.
Pattern 1: Sequential, the assembly line
A Sequential orchestration runs its member agents in a fixed order. The output of agent A becomes the input to agent B, whose output becomes the input to agent C, and so on. There is no branching, no replanning, no decision authority beyond the order the developer hard-coded.
When to use Sequential
When the workflow is genuinely linear and every stage depends on the previous stage. Content production is the canonical example: researcher gathers facts, writer drafts, editor polishes, publisher formats. Each role is a specialist; each role's output is the next role's input; the order never changes.
Sequential is also the right pattern for any "pre-process, process, post-process" shape, for example a translation pipeline (detect language, translate, adapt for cultural context), or a code-generation pipeline (parse requirements, generate code, review).
When not to use Sequential
When stages might run out of order, when intermediate stages might be skipped based on context, or when stages might need to revisit earlier work. Those are signals for Handoff (if routing is the variable) or Magentic (if the plan itself needs to adapt).
Code shape
from semantic_kernel.agents import ChatCompletionAgent, SequentialOrchestration
from semantic_kernel.agents.runtime import InProcessRuntime
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
service = AzureChatCompletion(deployment_name="gpt-4o", endpoint=ENDPOINT, api_key=KEY)
researcher = ChatCompletionAgent(
service=service,
name="researcher",
instructions="Gather five recent, citation-worthy facts on the topic. Be concise.",
)
writer = ChatCompletionAgent(
service=service,
name="writer",
instructions="Turn the researcher's facts into a 200-word blog intro. Cite inline.",
)
editor = ChatCompletionAgent(
service=service,
name="editor",
instructions="Tighten the writer's draft. Cut filler. Preserve every citation.",
)
orchestration = SequentialOrchestration(members=[researcher, writer, editor])
runtime = InProcessRuntime()
runtime.start()
result = await orchestration.invoke(
task="Azure AI Foundry multi-agent orchestration in 2026",
runtime=runtime,
)
print(result.value)
Production gotchas
Context inflation. Each stage receives the previous stage's full output, which means the editor sees the writer's draft plus the researcher's notes plus the original task. Long pipelines blow up the context window. Mitigation: have each stage emit a focused output, and consider summarisation stages between heavy stages.
Brittle ordering. If the researcher fails or returns nothing useful, the writer still runs with a bad input and the editor still runs with a worse one. Mitigation: add validation between stages, or use Magentic when the pipeline needs to be reliable in the face of stage failures.
Pattern 2: Concurrent, the parallel jury
A Concurrent orchestration runs its member agents in parallel against the same input, then aggregates the results. There is no inter-agent communication during the run, each agent sees only the original task, and the aggregation step decides how to combine the parallel outputs.
When to use Concurrent
When you want multiple independent perspectives on the same input. Stock analysis is the lab Microsoft Learn uses for this pattern: a bullish analyst, a bearish analyst, and a neutral analyst all examine the same company; their conclusions are combined into a balanced final view. Triage in code review is another fit: three different reviewer personas (security, performance, readability) each examine the same diff in parallel.
Concurrent is also the right pattern for any "broad search" task where you want diverse candidates rather than one consensus answer, for example brainstorming product names, generating multiple design options, or producing variant ad copy for A/B testing.
When not to use Concurrent
When agents need to react to each other's output (use Group Chat), when one agent should route the task to a specialist (use Handoff), or when the workflow has natural stages (use Sequential).
Code shape
from semantic_kernel.agents import ChatCompletionAgent, ConcurrentOrchestration
bull = ChatCompletionAgent(
service=service,
name="bull",
instructions="You are a bullish equity analyst. Argue why to buy. Be specific.",
)
bear = ChatCompletionAgent(
service=service,
name="bear",
instructions="You are a bearish equity analyst. Argue why not to buy. Be specific.",
)
neutral = ChatCompletionAgent(
service=service,
name="neutral",
instructions="You are a balanced equity analyst. Weigh both sides without picking one.",
)
orchestration = ConcurrentOrchestration(members=[bull, bear, neutral])
result = await orchestration.invoke(
task="Analyse Microsoft's Q4 2025 earnings for a long-horizon investor.",
runtime=runtime,
)
for member_result in result.value:
print(f"--- {member_result.name} ---")
print(member_result.content)
Production gotchas
Cost. Concurrent runs N agents per task instead of one. Be honest with yourself about whether the extra perspectives justify the extra inference cost.
Aggregation is on you. The orchestration gives you the raw outputs from each agent; deciding what to do with three different opinions is the application's job. A common pattern is to have a fourth, post-aggregation "synthesis" agent that reads all N outputs and produces a single combined response.
Try a real Azure AI lab, free
A pre-provisioned Azure environment in your browser. No Azure account, no credit card, no setup.
Most large enterprises already run on Microsoft infrastructure. Azure AI Foundry is the platform those teams use to build and deploy AI apps, so the skills you practice here map directly to real job demand.
Pattern 3: Group Chat, the round-table
A Group Chat orchestration puts the member agents in a shared conversation. After each turn, a group chat manager decides who speaks next. The conversation continues until the manager decides the chat is complete, or a configured maximum-rounds limit is hit.
When to use Group Chat
When the answer benefits from iteration, agents refine each other's work, push back on weak arguments, or collaborate to reach a consensus. Product design discussions, architectural reviews, threat modelling, and "red team / blue team" exercises all fit.
Group Chat is also the right pattern when you want an explicit manager role that controls the flow. The framework ships RoundRobinGroupChatManager (each agent gets a turn in order) and supports custom managers (for example, an LLM-driven manager that reads the conversation so far and decides who should speak next based on what is needed).
When not to use Group Chat
When the workflow is genuinely linear (use Sequential), when you want parallel independent views (use Concurrent), or when the cost of having every agent see every message in the conversation history is prohibitive. Group Chat is the most context-heavy of the five patterns.
Code shape
from semantic_kernel.agents import (
ChatCompletionAgent,
GroupChatOrchestration,
RoundRobinGroupChatManager,
)
architect = ChatCompletionAgent(
service=service,
name="architect",
instructions="Propose a system design. Listen to feedback. Iterate.",
)
security = ChatCompletionAgent(
service=service,
name="security",
instructions="Critique the design from a security and threat-modelling angle.",
)
operator = ChatCompletionAgent(
service=service,
name="operator",
instructions="Critique the design from an operability and on-call angle.",
)
orchestration = GroupChatOrchestration(
members=[architect, security, operator],
manager=RoundRobinGroupChatManager(max_rounds=6),
)
result = await orchestration.invoke(
task="Design an event-driven order-processing service for a mid-size retailer.",
runtime=runtime,
)
Production gotchas
Runaway rounds. Without max_rounds, an agreeable group of agents will happily chat forever. Always set a hard cap, and tune it based on the task: six rounds for a design review, two or three for a quick refinement.
Echo chambers. Three agents with overlapping instructions will agree quickly and produce nothing new. Build in real disagreement, explicitly opposing perspectives, or use Concurrent if you don't need iteration.
Context cost. Every agent sees the entire conversation on every turn. With six agents and six rounds, you are paying for thirty-six full-context inferences. Budget accordingly.
Pattern 4: Handoff, the triage desk
A Handoff orchestration starts with one active agent. Based on the user's request, that agent can transfer control to a different, more specialised agent by invoking a handoff. The handoff is a first-class concept in the framework: you declare which agents can hand off to which others, with what description, and the LLM decides at runtime whether to invoke each handoff.
Only one agent is active at any moment. There is no parallel work, no shared conversation. Each agent owns its own tool surface and instructions. When the active agent decides the task is outside its scope, it hands off.
When to use Handoff
The canonical use case is customer support. A triage agent classifies the incoming request and hands off to a billing specialist, a technical-support specialist, or a sales specialist. Each specialist has narrower instructions and tool access than the generalist triage agent. The specialist either resolves the request or hands back to triage.
Handoff is also the right pattern for any system with role-based escalation, for example an incident-response system where a first-line agent handles routine alerts and hands off to a senior agent for anything ambiguous, or a healthcare-intake system where the intake agent routes to the right clinical specialist.
The exam loves Handoff scenario questions because the trigger words are obvious: "route", "specialist", "escalate", "transfer".
When not to use Handoff
When the task does not partition cleanly along role lines (use one of the other patterns), when you want multiple agents working at once (use Concurrent or Group Chat), or when the routing logic is so simple it does not need an LLM to decide (just use a function call).
Code shape
from semantic_kernel.agents import (
ChatCompletionAgent,
HandoffOrchestration,
OrchestrationHandoffs,
)
triage = ChatCompletionAgent(
service=service,
name="triage",
instructions="Classify the user's request and hand off to the right specialist.",
)
billing = ChatCompletionAgent(
service=service,
name="billing",
instructions="Handle billing, refunds, invoices, and payment-method questions.",
)
tech = ChatCompletionAgent(
service=service,
name="tech",
instructions="Handle technical issues, error messages, and product bugs.",
)
handoffs = OrchestrationHandoffs()
handoffs.add(source_agent=triage, target_agent=billing,
description="For billing, refunds, invoices, or payment questions.")
handoffs.add(source_agent=triage, target_agent=tech,
description="For technical issues, error messages, or product bugs.")
handoffs.add(source_agent=billing, target_agent=triage,
description="When the request is not actually a billing question.")
handoffs.add(source_agent=tech, target_agent=triage,
description="When the request is not actually a technical question.")
orchestration = HandoffOrchestration(
members=[triage, billing, tech],
handoffs=handoffs,
)
result = await orchestration.invoke(
task="My invoice from May shows a charge I do not recognise.",
runtime=runtime,
)
Production gotchas
Handoff descriptions are prompts in disguise. The text in description= is what the active agent's LLM uses to decide whether to invoke a handoff. Vague descriptions cause vague routing. Write them as if you were briefing a new hire.
Specialists need their own tools and approval policies. A billing specialist that can issue refunds needs an MCP server scoped to the billing system, with require_approval="always" on the refund tool. A triage agent should not be able to issue refunds, give it no billing tools at all. Tool scope follows agent role.
Handoff loops. Two agents that disagree about whose job a request is will bounce it back and forth forever. The framework caps this, but you should also test for it and add escalation routes (back to triage, or to a human) to break loops cleanly.
Pattern 5: Magentic, the autonomous planner
Magentic is the newest and most ambitious of the five patterns, derived from Microsoft Research's Magentic-One work. A Magentic orchestration uses a manager agent that maintains a task ledger, a structured record of what is known, what is unknown, what has been tried, and what to try next. The manager plans, delegates to specialist agents, observes results, and replans. The plan is not fixed at the start; it emerges and adapts as the manager learns.
The defining feature is replanning. When a specialist returns an unhelpful result, the manager updates the ledger and chooses a different approach. When a specialist surfaces new information, the manager incorporates it into the plan. This is closer to how a project lead works than to how a script executes.
When to use Magentic
Open-ended, multi-step tasks where you do not know the plan upfront. Research projects ("find out everything we should know about X before deciding Y"), software-engineering tasks ("get this failing test to pass"), and analysis tasks ("explain why our churn spiked last week") all fit.
Magentic is also the right pattern when the cost of a wrong-but-confident first answer is high, and the user is willing to wait longer for a more carefully reasoned answer.
When not to use Magentic
When the workflow is well-known and stable (use Sequential), when the latency budget is tight (Magentic is the slowest of the five patterns because replanning means more inference rounds), or when the user expects a conversational reply rather than a research-style deliverable.
Code shape
from semantic_kernel.agents import (
ChatCompletionAgent,
MagenticOrchestration,
StandardMagenticManager,
)
researcher = ChatCompletionAgent(
service=service,
name="researcher",
instructions="Find primary sources. Cite each finding.",
)
analyst = ChatCompletionAgent(
service=service,
name="analyst",
instructions="Synthesise findings into a structured argument with explicit assumptions.",
)
critic = ChatCompletionAgent(
service=service,
name="critic",
instructions="Stress-test the analyst's argument. Identify weaknesses.",
)
orchestration = MagenticOrchestration(
members=[researcher, analyst, critic],
manager=StandardMagenticManager(chat_completion_service=service),
)
result = await orchestration.invoke(
task="Why did our SaaS churn jump 4 percentage points in May 2026?",
runtime=runtime,
)
Production gotchas
Cost and latency. Magentic is the most expensive of the five patterns by a wide margin because the manager runs an inference on every step. Budget accordingly.
Observability is non-negotiable. Because the plan emerges at runtime, you cannot reason about what the system "should" do, you can only inspect what it actually did. Wire up OpenTelemetry tracing from day one, log every manager decision, and review traces regularly.
Manager prompt drift. The StandardMagenticManager is configurable; teams that customise its prompt often introduce subtle planning bugs. Start with the default, tune only when you have a specific reason.
Ready to build all five patterns hands-on?
Pre-provisioned Azure AI Foundry sandbox. Build Sequential, Concurrent, Group Chat, Handoff, and Magentic with real tools and OpenTelemetry tracing.
The decision matrix: which pattern when?
If you remember nothing else from this guide, remember this section.
Start with the task shape, not the agent count. The pattern follows from how the work decomposes.
- If the work has a known, fixed sequence of stages, choose Sequential.
- If the work benefits from multiple independent perspectives on the same input, choose Concurrent.
- If the work needs iteration, refinement, or consensus-building among agents, choose Group Chat.
- If the work has a triage step followed by specialist execution, choose Handoff.
- If the work is open-ended and the plan needs to emerge as the system learns, choose Magentic.
| If the scenario mentions... | The exam answer is almost certainly... |
|---|---|
| "Pipeline", "stages", "in order", "step by step" | Sequential |
| "Parallel", "multiple perspectives", "independent analysts", "aggregate" | Concurrent |
| "Discussion", "iterate", "consensus", "round-table", "refine together" | Group Chat |
| "Triage", "route", "escalate", "specialist", "transfer" | Handoff |
| "Research", "open-ended", "plan as you go", "adapt", "replan" | Magentic |
If two patterns plausibly fit, default to the simpler one. Sequential beats Group Chat when both could work. Single agent beats Sequential when both could work.
Cross-cutting concerns
Five things apply across every pattern. Read these once and you will catch most production bugs before they ship.
Context passing. Every pattern propagates context differently. Sequential passes the previous output. Concurrent passes only the original task. Group Chat shares the full conversation. Handoff transfers context with the handoff. Magentic carries the ledger across all delegations. Know which pattern propagates what, because most "the agent forgot the earlier instruction" bugs are context-passing bugs.
Tool scope follows agent role. This is the single most important production rule and it is tested on the exam. Each agent should have only the tools it needs to do its job. A triage agent does not need access to the billing system. A researcher does not need access to the production database. Scope tools narrowly; if a handoff or orchestration step needs broader access, the receiving agent should have it, not the sender.
Error handling. Agents fail. Tools time out. Network drops. Every orchestration pattern should have a defined behaviour for what happens when a member agent errors: retry, skip, fail the whole orchestration, escalate to a human. The default is usually wrong for production; set it explicitly.
Observability. Multi-agent systems are harder to debug than single-agent systems by an order of magnitude. Trace every agent invocation, every tool call, every handoff, every manager decision. Wire OpenTelemetry to Application Insights via the Semantic Kernel telemetry filters. You cannot fix what you cannot see.
Cost. Multi-agent systems multiply inference cost. Track token usage per orchestration and per member agent. Set per-task budgets. If you are not measuring cost, you are not in production.
How multi-agent orchestration fits AI-103
The AI-103 official course (AI-103T00-A) places multi-agent orchestration in Learning Path 2, Module 8: Orchestrate a Multi-Agent Solution, eleven units, one of the longest modules in the course. The lab scenario is a multi-agent stock-analysis system built with the Concurrent pattern using Semantic Kernel.
Module 8 implicitly anchors several other exam topics:
- The Microsoft Agent Framework SDK from LP2 Module 7 (which is the SDK you instantiate orchestrations with)
- Tool integration via MCP from LP2 Module 3 (because member agents typically have MCP tools)
- The Agent Service primitives (threads, runs, run steps) from LP2 Module 1 (because orchestrations run on top of those primitives)
Multi-agent orchestration sits inside the Integrate and Deploy AI Solutions exam domain, weighted at 20-25% of the exam. Expect at least two scenario questions where you are given a task description and asked to pick the right pattern, and at least one question that tests the cross-cutting concerns above, typically tool scope or error handling.
For the broader curriculum context, our AI-103 Study Guide walks the full course module-by-module, and the Semantic Kernel guide covers the underlying SDK these orchestrations are built on.
Where teams get stuck in production
Five recurring failure patterns, drawn from real Azure AI Foundry deployments.
Reaching for orchestration when a single agent would do. New teams over-engineer. The first multi-agent system in a code base is usually too multi-agent. Start with one agent and a few well-chosen tools; add a second agent only when there is a concrete reason. The exam asks scenario questions where the "no orchestration needed" answer is correct.
Vague handoff descriptions or weak agent instructions. The orchestration runtime is exactly as good as the prompts you give it. A Handoff with three target agents and one-line descriptions of each will route nearly randomly. Write descriptions like API documentation; write instructions like job descriptions.
Unbounded loops. Group Chat without max_rounds. Handoff between two agents who disagree about whose job it is. Magentic with a manager prompt that never declares success. Always cap something, rounds, time, tokens, or manager iterations, and design the cap into the pattern from the start.
Shared mutable state across agents. Two agents writing to the same external system without coordination is a race condition waiting to happen. Either scope writes to one agent, or wrap shared resources with an MCP tool that has its own concurrency control.
No telemetry. This bears repeating. Multi-agent systems that ship without distributed tracing are nearly impossible to debug. Wire OpenTelemetry on day one.
Study strategy for the orchestration section
Two weeks before the exam, run this sequence.
Days 1-3. Build the Sequential, Concurrent, and Handoff code shapes from this guide. Run each one. Read every event the runtime emits.
Days 4-6. Build the Group Chat and Magentic code shapes. Vary max_rounds for Group Chat and observe how the conversation changes. Vary the Magentic manager's task and observe how it replans.
Days 7-9. Mix patterns. Build a Handoff where one of the specialists is itself a Sequential pipeline. Build a Concurrent orchestration whose results feed into a Magentic synthesis step. Real systems compose patterns; the exam may not test composition directly, but the intuition will help.
Days 10-14. Practice scenario questions. Read each scenario and pick the pattern before reading the options. Then verify against the trigger-word table above. If you find yourself between two patterns, ask which one is simpler, that is usually the right answer.
Frequently asked questions
What is multi-agent orchestration?
Multi-agent orchestration is the practice of composing two or more AI agents into a single system that solves a task no individual agent could solve as well alone. On Azure AI Foundry, orchestration is provided by the Microsoft Agent Framework via five named patterns: Sequential, Concurrent, Group Chat, Handoff, and Magentic.
What are the five multi-agent orchestration patterns in the Microsoft Agent Framework?
Sequential (fixed pipeline), Concurrent (parallel perspectives), Group Chat (round-table with a manager), Handoff (triage to specialist), and Magentic (planner-driven, adaptive). All five are tested on AI-103 Learning Path 2 Module 8.
When should I use Sequential vs Group Chat?
Use Sequential when the workflow has a fixed, known order of stages. Use Group Chat when the workflow benefits from iteration, refinement, or consensus among the agents. If both could work, choose Sequential, it is simpler, cheaper, and easier to debug.
When should I use Concurrent vs Group Chat?
Use Concurrent when you want independent perspectives on the same input with no inter-agent communication. Use Group Chat when the agents need to react to each other's contributions. Concurrent is cheaper because each agent sees only the original task; Group Chat is richer because each agent sees the full conversation.
What is the Handoff pattern best for?
Triage-then-specialist workflows. A generalist agent classifies the request and transfers control to a more specialised agent that owns the relevant tools and instructions. Customer support, incident response, and healthcare intake are canonical examples.
What is the Magentic pattern?
Magentic is an orchestration pattern derived from Microsoft Research's Magentic-One work. A manager agent maintains a task ledger and adaptively plans, delegates, and replans as the system learns. It is the right choice for open-ended tasks where the plan must emerge at runtime.
Is multi-agent orchestration tested on AI-103?
Yes. Learning Path 2 Module 8 is dedicated to it, and orchestration scenarios appear across the "Integrate and Deploy AI Solutions" exam domain, weighted at 20-25%. Expect multiple scenario questions that ask you to pick the right pattern.
How do I pass context between agents in an orchestration?
It depends on the pattern. Sequential passes the previous output as the next input. Concurrent gives each agent only the original task. Group Chat shares the full conversation. Handoff transfers context across the handoff boundary. Magentic carries the manager's ledger across delegations.
Can I combine multiple orchestration patterns?
Yes, and real systems often do. A Handoff specialist can itself be a Sequential pipeline. A Concurrent orchestration can feed a Magentic synthesis step. Compose freely, but resist the temptation to over-orchestrate; the simpler design usually wins.
What is the most common mistake teams make with multi-agent systems?
Reaching for orchestration when a single agent with good tools would do the job. The second most common is shipping without distributed tracing. Both are catchable by treating "do I really need a second agent here?" as the first question and "what does OpenTelemetry tell me?" as the second.
Where to go next
If you have not already, read the AI-103 Study Guide for the full curriculum map, the Azure AI Foundry Explainer for the platform context, the Semantic Kernel guide for the SDK these orchestrations run on, and the MCP guide for how member agents get their tools. For broader retrieval context that member agents often consume, see Building RAG Pipelines with Azure Cognitive Search.
The hands-on advantage
Reading about orchestration patterns gets you halfway to the exam. The other half is watching a Group Chat run away for forty rounds because you forgot max_rounds, debugging a Handoff loop where two agents bounce the same request back and forth, and tracing a Magentic ledger to figure out why the manager declared victory before the task was actually done.
Our AI-103 hands-on labs walk you through the full end-to-end build of all five patterns in a pre-provisioned Foundry environment. You build a Sequential content pipeline, a Concurrent equity-analyst panel, a Group Chat design review, a Handoff customer-support desk, and a Magentic research assistant, each with realistic tools, scoped MCP servers, and OpenTelemetry tracing. No Azure subscription required. No "spin up a Foundry project and hope nothing breaks." Just a working sandbox and a scenario you can finish in a sitting.
View pricing or try a free lab.