« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 07 — Multi-Agent Orchestration: Roles, Message Bus & Coordination

Answers these JD lines: Citi's and RBC's "multi-agent systems" and "perception / reasoning / planning / execution" language, and the explicit AutoGen / CrewAI (and LangGraph / Google ADK) framework experience those roles ask for. This is where "one agent" becomes "a team of agents" — and where a senior engineer's honest answer is often "this should still be one agent with good tools."

Why this phase exists

Phase 01 built one agent loop. Sometimes one loop isn't the right shape: a task has genuinely separable sub-jobs (research, then write, then check), or it needs a second opinion to be reliable. Multi-agent orchestration is how you wire several agents — each with a role and its own policy — so they coordinate through a shared channel instead of a tangle of direct calls.

But multi-agent is the most over-reached-for pattern in the field, so this phase teaches the tradeoff, not the hype. Four ideas do the work:

1. Separation of concerns via roles. A supervisor routes, workers do specialized tasks, a critic verifies. Each agent's prompt and tools stay small and focused, which is easier to build, test, and keep reliable than one mega-prompt trying to do everything.
2. A message bus / blackboard. Agents coordinate by posting to a shared, ordered, inspectable log plus a shared state dict — not through hidden side channels. That is what makes a multi-agent run auditable and reproducible.
3. Typed handoffs, least-context. Delegation is a first-class, validated transfer ({from, to, task, context}) that passes the receiver only what it needs — not the whole history. Context is a budget (Phase 04); a handoff that dumps everything is a cost and a quality regression.
4. Verification is the reliability lever. A critique-revise loop catches a bad draft and sends it back — turning Phase 00's 0.95^n decay into something you can arrest. This is the legitimate reason to add a second agent: to verify, not to look sophisticated.

And the counterweight, which is the Staff-level point: more agents multiply cost, latency, and failure modes. A single well-tooled agent usually beats a swarm. Reach for multi-agent when the work is genuinely parallel or genuinely needs specialized verification — never to paper over a weak single agent.

Concept map

• Topologies: supervisor / orchestrator-worker (one router, N specialists), hierarchical (supervisors of supervisors), network / peer (agents hand off to each other), sequential / parallel pipelines (fixed chains and fan-outs), blackboard (coordinate through shared state). Most production systems are supervisor-worker or a sequential pipeline.
• The message bus / blackboard: post(msg) → ordered history(); a shared state dict. Deterministic ordering (a counter, never a clock).
• Roles: supervisor (routes by state), worker (acts on a handoff), critic (approve / revise + feedback). One Agent base, an injected policy(context) -> str.
• Handoffs: a typed {from, to, task, context} transfer; validate the target; pass least-context (OpenAI Agents SDK handoffs; context passing).
• Verification: critique-revise / reflection / debate — the 0.95^n lever from Phase 00.
• Guards: max_turns / max_rounds everywhere — the multi-agent step budget.
• Failure modes: ping-pong loops, context explosion, cost blowup, error propagation between agents, responsibility diffusion.

The lab

Integrated scenario (how this shows up at work)

A "research assistant" must gather sources on a topic, write a summary, and make sure the summary is actually supported by the sources. You model it as a supervisor routing to a researcher then a writer (a two-step pipeline over the blackboard), and wrap the writer in a critique-revise loop with a fact-check critic that rejects any claim without a citation. The supervisor terminates on "done"; the critic bounds at max_rounds so a stubborn draft can't loop forever; the writer only sees the researcher's findings (least-context), not the supervisor's bookkeeping. Then the senior move: you measure it against a single well-tooled agent and keep the multi-agent version only where the critic measurably lifts reliability — because the swarm costs 3× the tokens and latency. That judgment is the phase.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• You can name the five topologies and say which one a given task wants (and why most are supervisor-worker or a sequential pipeline).
• You can explain the least-context handoff and why dumping the whole history is a bug.
• You can state, from Phase 00's 0.95^n, why a critic buys reliability back — and when a second agent is not worth its cost/latency.
• You can list the multi-agent failure modes (ping-pong, context explosion, cost blowup, error propagation, responsibility diffusion) and the guard for each.

Key takeaways

• Multi-agent is separation of concerns + verification over a shared bus, bounded by a step budget — not "more agents = smarter."
• The critic is the point. Verification is the reliability lever (Phase 00); most of the value of multi-agent is the second opinion, not the extra hands.
• Handoffs are least-context by default; context is a budget you spend, not a firehose.
• The most senior thing you can say in a multi-agent design review is frequently "this should be one agent with good tools" — the same "least-agentic that works" discipline from Phase 00.
• Everything here is the loop from Phase 01, composed: each agent is a policy; the orchestrator is a loop over policies; durability (Phase 08), security (Phase 09/10), and evals (Phase 11) all plug into the same bus.