05
Seven patterns · collaboration shapes
Seven patterns. Each solves a different problem.
Pick the wrong shape for your team of agents and you'll fight your own architecture forever. Pick the right one and a lot of the code writes itself.
Topology playground
Switch patterns. The pattern is the message flow.
Pattern 1 · Orchestrator (supervisor / conductor)
Who
One agent in charge plus a team of specialists. Specialists never talk to each other directly.
When
You roughly know the steps ahead of time and want runs you can predict and audit.
What
The lead breaks the goal into sub-tasks, hands them out, gathers results, and combines them.
Why
The easiest pattern to debug. One place enforces the rules. Most production systems start here.
Use case · Customer support triage
Inbound ticket arrives. Conductor reads it, decides: billing question → billing agent; refund → refund + policy agents; technical issue → diagnostic agent + KB agent. Specialists return structured findings; conductor drafts the customer reply. Why orchestrator wins here: ticket categories map to agents, no specialist needs to talk to another, and you need one place to enforce SLA timeouts and tone-of-voice rules.
Pattern 2 · Hierarchical (orchestrator-of-orchestrators)
Who
A top-level lead manages middle-level leads, each with their own team underneath.
When
The work breaks into separate chunks too big for one lead to manage by itself.
What
Big-picture coordination at the top, detailed work at the bottom. Middle managers shield the top from the noise.
Why
Lets you go beyond what a single context window can hold. Same idea as a company org chart.
Use case · Building a SaaS feature end-to-end
Top orchestrator owns the feature spec. Mid-orchestrators run frontend team (designer + reactYao 2023 dev + tester), backend team (API designer + db engineer + security reviewer), infra team (deploy + monitoring). Each team's mid-orchestrator only reports a status summary upward, the top never sees raw code review threads. Why hierarchical wins: a single orchestrator running 12 specialists would explode its context window and lose track of which thread it's on.
Pattern 3 · Pipeline
Who
A line of agents in order. The output of each one is the input to the next.
When
The work has clear steps that always run in the same order. Like translate, then summarize, then tag.
What
Each step does its one job. No going backward, no branching, no surprises.
Why
Easy to test each step on its own. Easy to swap one step for a different model.
Use case · Document intake for legal discovery
100,000 PDFs need processing. Pipeline: OCR agent → language detect agent → translation agent (if non-English) → entity extraction agent → privilege classifier agent → storage agent. Embarrassingly parallel across documents. Why pipeline wins: no document needs to "talk to" another; each stage is pure; failures restart at the last completed stage.
Pattern 4 · Peer swarm
Who
A group of agents that all talk to each other freely. No one is in charge.
When
Open-ended work where you can't predict the path ahead of time.
What
Agents broadcast or call each other directly. The structure of the work emerges as they go.
Why
Maximum flexibility. Also maximum chaos: easy to get stuck in loops, hard to debug.
Use case · Scientific brainstorming / literature exploration
Goal: "find unexplored connections between immunology and circadian rhythm research." Five peer agents, each takes a different journal corpus, posts findings to others, follows up on each other's leads. Why swarm wins: the path is genuinely unknown; rigid orchestration would prune the very serendipity you want. Caveat: hard cap on rounds, neutral judge to declare "done", and a token budget that bites, otherwise they'll talk forever.
Pattern 5 · Blackboard
Who
A group of agents plus a shared workspace they can all read and write to.
When
Long-running work where pieces show up over time and can't be finished in one sitting.
What
Each agent watches the shared workspace, picks up tasks it knows how to handle, and posts results back.
Why
Agents don't need to be online at the same time. The workspace itself is the audit trail.
Use case · 24/7 SOC threat investigation
Alerts arrive continuously. The blackboard holds the active investigation: indicators, timeline, hypotheses. Network agent watches for new IPs and posts findings. Endpoint agent reacts when an IP appears on the board, posts host data. Threat-intel agent enriches indicators. Hypothesis agent proposes what's happening. Analysts join in real-time. Why blackboard wins: agents work asynchronously across hours, the board persists across shifts, and audit trails are automatic, the board is the case file.
Pattern 6 · Debate
Who
Two or more agents argue different sides. A judge agent, or majority vote, picks the winner.
When
When getting the right answer matters more than getting it fast.
What
Round 1: each agent states its position. Round 2: they push back on each other. Round 3: a judge picks or combines.
Why
Catches mistakes one agent would miss. Forced disagreement surfaces hidden assumptions. Originally proposed in Du et al., ICML 2024; Liu et al., ICLR 2025 showed that mixing different model families in the debate works better than using copies of the same model.
Use case · Reviewing risky code changes
A pull request proposes changing payment processing code. The proposer agent argues why the change is safe and helpful. The critic agent argues every way it could break (race conditions, regulatory issues, rollback problems). After two rounds, a judge agent decides: "approve, but add these specific test cases", or "block, here's why." Why this works: one reviewer often misses things it wasn't looking for. Forcing two agents to disagree exposes blind spots. Cost: 3 to 5 times more tokens than a single review, but worth it for code that touches money.
Pattern 7 · Time-aware (wait-and-see)
Who
An agent that knows it doesn't have to act right now. Can act, defer, or come back later. Waiting is allowed.
When
Decisions where rushing makes things worse. Trading, anything that can't be undone, anything where new information will arrive soon if you wait a bit.
What
At each step the agent picks one of three: act now, come back at time T, or act now but mark the action reversible until time T. The orchestrator's scheduler honors the deferred steps and re-runs them on time.
Why
Most agents can't wait because they're built to answer right away. A real agent sometimes shouldn't. Treating time as something the agent can spend (like tokens or money) lets it make that call honestly.
Use case · A reconciliation agent that lets the dust settle
A bookkeeping agent gets a transaction at 14:32 that doesn't match anything. A naive agent flags an exception immediately. A time-aware agent knows bank settlement often takes 90 minutes, so it waits, comes back at 16:00, and only flags an exception if the mismatch is still there. Why this works: most "exceptions" resolve themselves with a little patience. Waiting cuts the false-alarm flood. Cost: almost free. Deferred work doesn't burn tokens; it just gets re-queued.
Quick reference: which pattern when?
| What you need | Pick this | Avoid this |
|---|---|---|
| Predictable runs, easy debugging | Orchestrator | Swarm |
| Lots of independent sub-projects | Hierarchical | Single orchestrator (it'll run out of context) |
| Same steps every time, in order | Pipeline | Debate (more than you need) |
| Open-ended exploration | Swarm | Pipeline (too rigid) |
| Long-running work, lots of auditing | Blackboard | In-memory orchestrator |
| Highest possible answer quality | Debate | Pipeline (no second-guessing built in) |
| Decisions that are better when not rushed | Time-aware | Pipeline (acts on every input as it arrives) |
Whichever pattern you pick, the next question shows up immediately: when one agent delegates work to another, what context comes along, and what stays behind? Pass too much and you leak; pass too little and the specialist guesses. Chapter 06 (Context exchange) covers the typed envelopes, handshakes, and compartments that make that question answerable rather than improvised.