Multi-agent orchestration — the five patterns

When one agent is not enough, there are five ways to arrange several. Questions here describe a scenario and expect the pattern, so learn them by the shape of the problem each one solves.

Matching the scenario to the pattern

Pattern	Its shape	Choose it when
Sequential	Linear — each output feeds the next input	A pipeline with a known order
Concurrent	Parallel, then aggregate	Independent work that fans out
Handoff	Control transfers at runtime — the agent decides	Routing to a specialist at runtime
Group chat	A shared conversation; a manager picks the next speaker; every agent sees the full history	Brainstorming and collaboration
Magentic	A powerful manager plans dynamically, keeping a ledger	Open-ended tasks with an unknown path

The distinguishing question for most of these is who decides what happens next. In sequential and concurrent, you decided at design time. In handoff, the agent decides. In group chat, a manager decides who speaks. In Magentic, a manager decides what the plan even is.

Building one

The first step of unified orchestration is to define the agents and describe their capabilities. Descriptions again — the manager routes by reading them.

In code: SequentialBuilder().participants([...]).build(), then workflow.run(). Collect events where type == "output".

Group chat internals

Two mechanics worth knowing because they explain the cost:

• Agents do not share one session instance.
• The orchestrator broadcasts each response to synchronise everyone's context.

So every participant sees everything, which is what makes collaboration work and also what makes it expensive. Each broadcast adds to every agent's context.

Magentic internals

It derives from AutoGen's Magentic-One. The architecture is group chat plus planning.

Three controls worth knowing by name: max_round_count, max_stall_count and max_reset_count. All three exist because a dynamically planning manager has no natural stopping condition — the same reason card 9 insisted on capping reflection loops. Anything that decides its own next step needs a limit imposed from outside.

The trap

Group chat and Magentic look alike, and the exam exploits that.

Pick group chat for collaboration where the shape of the work is known. Pick Magentic only when the task is genuinely complex and the path is unknown. The deciding word in the scenario is usually whether anyone knows in advance what the steps are.

One further point that turns up: the full range of patterns generally needs the self-hosted Agent Framework, not the Foundry Agent Service alone. If a question constrains you to the hosted service and then asks for Magentic, the constraint is the answer.