Implement orchestrated multi-agent solutions

One agent with twenty tools selects badly. Several agents with four tools each select well — but now something must decide who acts, how information moves between them, and when the whole thing stops. This objective is the implementation side of multi-agent work: not just which pattern, but how state, termination, and composition actually get built.

Why This Matters

Decomposition is a quality technique, not just an architecture. Tool selection degrades with surface size. Splitting an agent by domain is often the fix for a selection problem, which is why "the agent picks the wrong tool" scenarios sometimes have a multi-agent answer.

Every orchestration needs a stopping condition. Nothing in a group chat or a Magentic run terminates by itself. Unbounded loops are the characteristic multi-agent failure.

Information does not move for free. State management shares data across executors; without it, participants either lose context or receive ever-growing blobs.

Prerequisites

• The five orchestration patterns and what each is for.
• That an agent selects tools from schema text.
• Human-in-the-loop as "pause for external input and resume", and checkpoints as "save and restore workflow progress".
• Agent evaluators, especially Task Adherence and Task Navigation Efficiency.

Learning Objectives

By the end of this lesson you will be able to:

1. Decide when to split one agent into several.
2. Implement handoff and group chat and justify the choice.
3. Manage shared state and termination across participants.
4. Compose with agents in workflows, workflows as agents, and agents as tools.
5. Instrument a multi-agent system so failures are attributable.

Building Blocks

The patterns, by decision authority. Sequential and concurrent fix the path at design time. Handoff lets the current agent transfer control directly. Group chat puts an orchestrator in charge of who speaks next. Magentic has a manager that plans, delegates, observes, and replans for problems where the plan is not known in advance.

Composition directions. Agents in workflows — agents as participants. Workflows as agents — a whole workflow exposed as a single callable agent. Declarative workflows — the structure as configuration. An agent can also be exposed as a tool to another agent, which is the tightest form of delegation.

State management is "sharing data across executors", so a later participant can read what an earlier one produced.

Durability. Checkpoints "save and restore workflow progress"; human-in-the-loop is "pause for external input and resume".

Agent-to-agent. A2A is preview, which matters when the design is constrained to generally available capability.

Deep Dive

When to split

Splitting is not automatically better. It adds latency, cost, and failure modes, so it needs a reason — and there are three good ones.

Tool-surface pressure. Selection quality falls as the tool list grows and overlaps. An agent with tools spanning billing, provisioning, and diagnostics is choosing among near-neighbours on every turn. Splitting by domain gives each agent a small, disjoint surface, which is often the real fix for a "picks the wrong tool" symptom.

Divergent instructions. When one agent's instructions contain contradictory guidance for different situations — be terse for status checks, be thorough for incident analysis — the conflict shows up as inconsistency. Separate agents hold separate instructions cleanly.

Different permissions. Hosted agents get a dedicated Entra identity per agent, and roles can be assigned at agent scope. If one capability needs write access to a system of record and another does not, splitting expresses least privilege in a way one agent cannot.

What is not a reason: the task has several steps. A multi-step task with a known order is a sequential workflow, and a fixed path is cheaper, faster, and trivially auditable.

Handoff, group chat, and agent-as-tool

Three ways one agent involves another, distinguished by what happens to control.

Handoff transfers it. The triage agent identifies a billing question and hands the conversation to the billing agent, which then owns the interaction. Natural for triage; the cost is that authority is distributed, with no single component seeing every turn.

Group chat keeps it centrally. An orchestrator decides who speaks next, so several agents can contribute to one problem and one component observes everything. That is the governance-friendly shape: policy applies in one place, and the run is easy to evidence.

Agent-as-a-tool retains it. The caller invokes another agent the way it invokes any tool — a call that returns a result — and remains in charge. This is the right shape for delegating a sub-task: summarise this document, classify this ticket, extract these fields. The conversation stays with the caller, which keeps accountability clear.

The mistake to avoid is using handoff where a delegated sub-task was meant. Handing off control to get one summary means the specialist now owns the conversation, and the original agent's goal is orphaned.

State and termination: the two implementation gaps

Pattern choice gets the attention; these two decide whether the system works.

Shared state. State management shares data across executors, and the design question is what each participant should see. Give everyone everything and you pay context cost on every turn and risk one agent acting on another's half-finished conclusion. Give them too little and they redo work or contradict each other. Deciding explicitly — this agent needs the customer record, that one needs only the classification — is part of the build.

Termination. Nothing stops on its own. A group chat continues while the orchestrator keeps selecting speakers; a Magentic run continues while the manager keeps replanning. Every orchestration needs an explicit stopping condition: a goal met, a maximum number of turns, an orchestrator decision, or a human decision.

The absence shows up in evaluation as Task Navigation Efficiency — an agent reaching the right answer by an unreasonably long path — and in the bill. A scenario describing agents that keep exchanging messages without converging is describing a missing termination condition, not a model problem.

Composition and reuse

Two directions and one packaging choice.

Agents in workflows puts agents inside a structured flow — the common case, where a deterministic pipeline needs judgement at a few points.

Workflows as agents exposes a whole workflow as a single agent, so a larger orchestration calls it like any participant without knowing its internals. This is the answer for reusing an existing multistep pipeline inside a bigger system, and rebuilding its steps as individual participants is the wrong one — it duplicates logic and loses encapsulation.

Declarative workflows express structure as configuration, which suits flows that must be reviewed, version-controlled, or edited outside application code.

Making failures attributable

A multi-agent failure is harder to localise, so instrumentation is not optional.

Traces show the whole run — which agent acted, which tool it called, what came back. Per-participant evaluation is what makes a score meaningful: Intent Resolution (did it understand), Task Adherence (did it stay on task), Task Navigation Efficiency (did it get there reasonably), and the tool-call family for each agent's own tools.

Two symptoms have characteristic causes. Handed to the wrong specialist is a routing problem — the triage agent's instructions or the specialists' descriptions. The right specialist behaving badly is that agent's own instructions or tool schemas. Distinguishing them requires evaluating participants separately rather than scoring the system as a whole.

Worked Examples

Example 1 — the wrong-tool symptom. One agent carries eighteen tools spanning billing, provisioning, and diagnostics, and frequently picks a near-neighbour.

Tool-surface pressure. Split by domain so each agent has a small disjoint set, and route with handoff for triage-into-specialist or group chat if several must contribute. Adding more instructions to one agent does not fix a selection problem caused by overlapping schemas.

Example 2 — a delegated summary. A case-management agent needs a document summarised mid-conversation, then continues its own work.

Agent as a tool — a call that returns a result while the caller retains control. Handoff would transfer ownership of the conversation to the summarising agent, orphaning the original goal.

Example 3 — agents that never converge. Two agents in a group chat exchange messages indefinitely, and costs climb.

A missing termination condition. Define an explicit stopping rule — goal met, maximum turns, or an orchestrator decision — and instrument with Task Navigation Efficiency to catch long paths. Nothing in an orchestration stops by itself.

Visual Explanations

What happens to control:

The build checklist beyond the pattern:

Common Mistakes

Splitting because a task has several steps. That is a sequential workflow.

Using handoff to delegate a sub-task. Control transfers; use agent as a tool.

Omitting a termination condition. Nothing stops by itself.

Sharing all state with every participant. Cost, and agents acting on half-finished conclusions.

Scoring the system instead of the participants. Failures stop being attributable.

Rebuilding a pipeline's steps as participants. Expose it with workflows as agents.

Choosing group chat and then bypassing the orchestrator. The single decision point was the reason to choose it.

Assuming A2A is available. It is preview.

Practice Exercises

1. Give three legitimate reasons to split one agent into several, and one illegitimate reason.
2. Distinguish handoff, group chat, and agent-as-a-tool by what happens to control.
3. Agents exchange messages indefinitely. Name the defect and the evaluator that surfaces it.
4. Which composition reuses an existing multistep pipeline, and why not rebuild it?
5. How do you distinguish a routing failure from a specialist failure?

Summary & Concept Map

Multi-agent implementation starts with justifying the split — tool-surface pressure, divergent instructions, or different permissions, never merely "several steps". Then choose by what happens to control: handoff transfers it, group chat routes every turn through an orchestrator giving one observable governance point, and agent-as-a-tool retains it for delegated sub-tasks. Beyond the pattern lie the two gaps that decide whether it works: shared state, decided deliberately per participant, and termination, which never happens by itself and shows up as runaway cost and poor Task Navigation Efficiency. Compose with agents in workflows and workflows as agents for reuse, place humans with HITL plus checkpoints, and evaluate per participant so a failure is attributable to routing or to a specialist.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.