Phase 8: Multi-Agent Systems & Platform Architecture · 50 min · Claude Code · Python

Multi-Agent Production Patterns

A specialist agent team isn't five agents running whenever — it's a dependency graph, and running a step before its dependency finishes isn't parallelism, it's a race condition.

Hiring signal: Scheduling a planner-coder-reviewer-tester-deployer pipeline against a real dependency graph — not just calling agents in a fixed sequence — is the concrete difference between a toy multi-agent demo and production orchestration.

What you will learn

Design a specialist agent team (planner, coder, reviewer, tester, deployer) with an explicit dependency graph between roles
Run independent specialist agents in parallel while strictly respecting dependencies between dependent ones
Explain why Anthropic's multi-agent research system has subagents return findings, not raw context, to the lead agent
Detect and reject a cyclic dependency in an agent task graph instead of allowing it to hang or misorder

Introduction

Multi-Agent Production Patterns

A team scales up their orchestrator-worker pattern from c12-05 into a full specialist pipeline: a planner agent breaks down a feature request, a coder agent implements it, a reviewer agent checks the diff, a tester agent runs it against acceptance criteria, and a deployer agent ships it once everything passes. Someone, trying to speed things up, kicks off the reviewer and the deployer at the same time as the coder, reasoning that running everything "in parallel" is faster. The reviewer reviews an empty diff. The deployer tries to ship code that doesn't exist yet. This isn't a parallelism win — it's a dependency violation dressed up as an optimization, and it's exactly the failure a real multi-agent production system has to structurally prevent, not just avoid by convention.

Orchestrator-worker at scale is a dependency graph

A specialist agent team isn't "five agents, run them whenever" — it's a directed graph of dependencies, and the orchestrator's actual job is respecting that graph: the coder can't start meaningfully before the planner produces a plan; the reviewer and tester can't run before the coder produces a diff, but can run in parallel with each other once the coder is done, since neither depends on the other; the deployer can't run until both the reviewer and the tester have passed. Getting the parallelism right means running truly independent steps concurrently (reviewer and tester, once their shared dependency is satisfied) while strictly serializing steps that depend on each other — the goal is real parallelism where it's actually available, not parallelism claimed everywhere regardless of whether the dependencies allow it.

Dependency violations don't look like bugs at first
The reviewer running against an empty diff doesn't crash — it produces some kind of review, just a meaningless one, for a diff that doesn't exist. The deployer failing to find code to ship might just log an error and move on. Dependency violations in a multi-agent pipeline frequently produce output that's technically valid-looking but semantically nonsense, which is exactly the kind of failure a structural dependency check prevents and a "we'll be careful about ordering" convention eventually misses.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Memory and state across agents, Cycles are a design error, not a runtime accident, This generalizes past five specific roles, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

Agent