Orchestration: two vocabularies, one decision

There is a small trap in this topic that has nothing to do with agents and
everything to do with vocabulary: the syllabus and the product call the same five
things by different names.

The syllabus asks you to implement orchestration patterns "including hub-and-spoke,
sequential, parallel, peer-to-peer, and orchestrator-subagent". Microsoft Agent
Framework documents five built-in orchestrations called Sequential, Concurrent,
Handoff, Group Chat and Magentic.

They line up. Nobody publishes a table saying so.

The mapping

The syllabus says	Agent Framework calls it	Which means
Sequential	Sequential	Agents execute one after another in a defined order
Parallel	Concurrent	Agents execute in parallel
Hub-and-spoke	Handoff	Agents transfer control to each other based on context
Peer-to-peer	Group Chat	Agents collaborate in a shared conversation
Orchestrator-subagent	Magentic	A manager agent dynamically coordinates specialised agents

This mapping is my reading of the two vocabularies, not a Microsoft equivalence
table. The framework descriptions are quoted directly; lining them up against the
syllabus terms is the interpretive step.

Answer by shape, not by name

Because both vocabularies are in play, the reliable technique is to ignore the
names and read for the constraint.

"Each step needs the output of the last." Fixed order — Sequential.

"These subtasks are independent and latency matters." Concurrent.

"One front door, several specialisms behind it." Handoff. The user talks to one
agent and control moves based on what they need.

"The agents need to react to each other's contributions." Group Chat — a shared
conversation is the point.

"We do not know the steps in advance" or "it has to recover when a step
fails." Magentic. It is the only one of the five that re-plans.

Two things worth knowing about the expensive ones

Group Chat is the most expensive pattern and needs a termination condition.
Every agent sees every contribution, so context grows for everyone at once. Without
an explicit stopping rule, a group chat is a system that can talk indefinitely and
occasionally does.

Magentic re-plans, which means every manager turn is a full model call on top
of the subagents' work. That is what makes it capable and what makes it costly, and
it is why a Magentic design needs a budget rather than just an iteration limit.

The constraint that eliminates a pattern outright

This one is worth memorising because it is a clean, decisive rule:

If one agent must not see another agent's data, Group Chat is ruled out. A
shared conversation is shared by definition. No configuration fixes that, because
the sharing is the pattern.

Scenarios about isolation between business units, or separating data that must not
be commingled, are quietly eliminating an option before you have read the answers.

One more thing the framework gives you

Orchestrations support human-in-the-loop through tool approval and request-info:
agents can use approval-required tools that pause the workflow for human review
before execution. So a human gate is not something you bolt on around an
orchestration — it is available inside one.

The trap

Every pattern is defensible in the abstract, which means a question can never
sensibly ask "which orchestration pattern is best".

So it will always give you a constraint — order, latency, isolation, unknown steps,
recovery — and the constraint picks the pattern. If you find yourself weighing the
patterns against each other on general merit, you have missed the sentence that was
doing the work.