Phase 5: Agent Orchestration Patterns · 50 min · Claude Code · Python

Multi-Agent Orchestration

Multi-agent systems fail for a specific, predictable reason: agents working in isolation make locally reasonable decisions that conflict at integration time.

Hiring signal: Being able to say precisely when a multi-agent design will hit Cognition's integration-conflict failure mode — and when a task is genuinely independent enough to avoid it — is sharper system-design judgment than either 'always use one agent' or 'always parallelize.'

What you will learn

Identify when a task's subtasks are independent enough to genuinely benefit from a multi-agent split
Name the three multi-agent anti-patterns: agent thrashing, hallucination propagation, context explosion
Explain Cognition's core critique of multi-agent systems and when it does and doesn't apply
Detect integration conflicts caused by specialist agents making incompatible assumptions in isolation

Introduction

Multi-Agent Orchestration

A team splits a large refactor across two specialist coding agents working in parallel: one handles the payments module, one handles the notifications module, both of which need to call a shared internal process(data) function that's also being touched by this refactor. Neither agent has visibility into the other's work as it happens. Agent A, reasoning locally and reasonably, adds an optional second parameter to process() to support a new payments feature. Agent B, also reasoning locally and reasonably, assumes the original single-parameter signature is stable and writes notification code that calls it the old way. Both pieces of code are individually correct. Integrated together, one of them is broken, and neither agent could have known, because neither had the other's context.

This is the precise failure mode Cognition's engineering team describes in their "don't build multi-agents" argument: sub-agents acting in parallel, without shared context, make decisions that look locally reasonable and conflict at integration time. It isn't a claim that multi-agent systems never work — it's a claim about exactly when they fail, which is useful precisely because it tells you when the failure mode doesn't apply.

When multi-agent genuinely fits

The previous lesson's single-agent case (2,000 contracts, one well-harnessed agent) worked because the subtasks shared no interdependent assumptions — processing contract #47 correctly has nothing to do with how contract #48 gets processed. Multi-agent orchestration is the right call under a similar condition, scaled up: genuinely independent subtasks, where a specialist agent's decisions in one don't create hidden coupling with another's decisions in a different one. Fixing an unrelated typo in ten different files, each requiring no shared assumption about interfaces or behavior, is a legitimate case for parallel specialist agents — the failure mode this lesson describes simply doesn't have anywhere to occur, because there's no shared interface for two agents to disagree about.

Cognition's critique, precisely
The failure isn't "multiple agents are bad." It's that agents reasoning in isolation, about a shared or interdependent piece of the system, will make independently-reasonable decisions that don't reconcile — because reconciliation requires context neither agent had. The fix isn't always "use one agent instead." Sometimes it's making the shared interface explicit and fixed before dispatching to parallel agents, so there's nothing left for them to independently (and differently) assume.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The three anti-patterns at multi-agent scale, Specialist roles, when they earn their keep, Anthropic's own multi-agent system as a working counter-example, 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.