Lessons 33.1 and 33.2 gave you both sides: start with one agent, and split into contracted roles only when the work earns it. This lesson prices the split. Every additional role buys capability and charges coordination tax.Builders who cannot name the tax always overpay.

The six failure modes

Memorize these. When a multi-agent demo goes wrong, the cause is almost always one of them:

1. Duplicated research. Two workers fetch the same sources because neither could see the other's completed work. You pay twice for the same evidence and get two slightly different copies. Cause: no shared state, or state nobody reads before acting.

2. Conflicting conclusions. The analyst says margins are recovering; the writer says they are deteriorating — each working from a different snapshot. Cause: workers reading different versions of the evidence, with no single authoritative artifact.

3. Stale context. A worker acts on yesterday's draft, last week's source packet, or a lead that was already rejected. Cause: handoffs without timestamps, version numbers, or expiry. A claim without a retrieved_at date is a rumor.

4. Invisible handoffs. Work passes through a chat message, a function call with no log, or an agent's private memory. When the output is wrong, nobody can replay the chain. Cause: treating conversation as infrastructure. If you cannot open the handoff a week later, it was not a handoff.

5. Runaway cost. Each role loads its own context window, retries its own failures, and calls its own model passes. Three roles rarely cost 3× one role — they cost 4–6×, because coordination messages, re-reads, and rework compound. Cause: no per-role budgets and no global stop condition.

6. Unclear ownership. The draft is wrong. Was the research incomplete, the analysis sloppy, the writing unfaithful, or the validation asleep? When every stage touched it and nobody signed it, the answer is a meeting. Cause: artifacts without named owners at every stage.

A single agent can suffer from stale data or high cost too — but it suffers visibly, in one log, under one owner. Multi-agent systems distribute the same problems across roles and then hide the distribution.

Sequential versus parallel: when parallelism pays

Multi-agent designs usually arrange work in one of two shapes. Choosing deliberately is half the debugging battle.

Sequential means stages run in order: discovery finishes, then research, then analysis, then writing, then validation. This is the editorial pipeline from 33.2. Its virtue is determinism — each stage sees the finished output of the last, and the timeline reads top to bottom. Its price is latency: total time is the sum of every stage, and one slow stage stalls everything behind it.

Parallel means independent branches run at once: three collectors each cover a different approved source; two analysts each test a different hypothesis against the same evidence; validators check formatting and factuality simultaneously. Its virtue is speed and coverage. Its price is reconciliation — someone must merge, deduplicate, and resolve conflicts when the branches rejoin.

Parallelism pays only when three conditions hold:

• Independence. Branches must not need each other's unfinished output. "Collector A reads filings, collector B reads macro data" is independent. "Writer drafts while researcher still gathers" is not — the writer will invent the missing facts.
• A merge plan. Before launching branches, write down who merges, by what rule, and what happens on conflict. Newest wins? Source-authority wins? Human decides? "We will figure it out" guarantees conflicting conclusions.
• A speed or coverage need that sequential cannot meet. Five sources with a morning deadline; a catalog too large for one context window; an experiment comparing two methods. If sequential finishes in time and fits in context, parallel's reconciliation cost buys nothing.

A practical hybrid, and the one SweepsMonitor uses: parallel collection, sequential synthesis. Independent collectors fan out across approved sources at once (parallel pays — the sources do not depend on each other), then one researcher consolidates the packets, and the remaining stages run sequentially with full visibility. Fan out where work is independent; funnel back to a single thread before judgment begins.

Debugging: the timeline plus the owner

When a multi-agent run fails, do not start by re-reading model outputs. Draw the run timeline first:

09:00 discovery (owner: scheduler) → lead #14 + packet v3
09:05 researcher (owner: collection worker) → evidence/*.json (2 records)
09:12 analyst (owner: analysis worker) → comparison note v1
09:20 writer (owner: drafting worker) → draft v1 (cites 2 records)
09:25 validator (owner: validation worker) → FAIL: claim 3 has no source
09:26 → returned to researcher queue with defect list

Five columns make this work: timestamp, role, input version, output artifact, owner. With it, the validator's failure above takes seconds to route — the defect points at the writer's third claim, the timeline shows which evidence version the writer used, and the owner column says who fixes it. Without it, the same failure becomes an afternoon of "but I thought the researcher found that."

Three debugging rules follow:

• One owner per artifact. Every file, record, and draft names the role (and ultimately the human) responsible for its correctness at that stage. Shared ownership is no ownership.
• Version every handoff. Packet v3, evidence schema v2, draft v1. When the analyst and writer disagree, the first question is "which versions did each of you read?" — and the timeline answers it.
• Budget the whole run, not just each role. Give every role its own step and spend limit, then cap the run globally (total tool calls, total cost, total elapsed time). A validator that bounces a draft back three times should trigger escalation to a human, not a fourth silent retry loop.

Practical exercise

Take the role contracts you wrote in 33.2 (or the six-stage editorial pipeline) and build a run timeline for one job from discovery to publisher.

1. List each stage in order with its input version and output artifact (file path or record ID). 2. Write one owner beside every artifact — a role name plus the human accountable. 3. Mark which stages run sequentially and which run in parallel, and justify each parallel branch against the three conditions (independence, merge plan, genuine need). 4. Inject one failure on paper — e.g., "validator rejects the draft: claim without source" — and trace it: which artifact is defective, which owner fixes it, and where does the job re-enter the timeline?

Finish line: a one-page timeline with timestamp, role, input version, output artifact, and owner for every stage, plus a written re-entry path for one injected failure.

Verify: cover the owner column and ask: for each artifact, is it obvious who signs it? Then cover the version column and ask: could two stages silently use different evidence? Any "no" or "yes" means the timeline is decorative, not operational.

Common failure mode: parallelizing judgment — two writers drafting from shifting evidence with no merge rule. Parallelize collection; keep analysis, writing, and validation sequential until the system has earned more.

Check your understanding

1. Name three of the six coordination failure modes and the missing discipline behind each. 2. Under what three conditions does parallel execution pay for its reconciliation cost? 3. Why does every artifact need exactly one owner?

Transition: memory beyond one run

You can now design the smallest system that works — one agent first, contracted roles only where earned, coordination costs priced and owned. But every design so far assumed the next run starts fresh. Real systems remember: evidence persists, drafts version, source packets expire. Class 34 turns short-lived run state into durable memory — files, databases, and retrieval — so the next run starts from reality instead of from scratch.