Lesson 33.1 gave you the discipline: start with one good agent plus a queue, and split only when tools, context, outputs, or review criteria truly differ. This lesson shows the shape of a split that passes that test — an editorial pipeline — and the machinery that makes it work: an orchestrator, explicit handoffs, shared state, and contracts.

The pipeline that earns its roles

Consider a research-to-publication workflow with six stages:

discovery → factual researcher → analyst → draft writer → validator → human publisher

Each stage exists because its job differs on the axes from 33.1, not because "more agents feels thorough":

The researcher may browse; the writer may not. The analyst may compute; the validator may only check. The publisher is a human with a button no agent holds. That is separation with a reason.

The four pieces of machinery

Four concepts hold any multi-role system together. Learn them as vocabulary before you build:

• Orchestrator. The component that assigns work, tracks progress, and combines results. It is usually ordinary software — a queue worker, a Python script, an n8n workflow — not a clever boss-agent improvising assignments. It says: "researcher, here is lead #14 and its source packet; writer, here is validated evidence set #14; validator, here is draft #14." It never invents content itself.
• Handoff. The moment one stage's output becomes the next stage's input. A handoff is a file, a database record, or a queue message — something you can open a week later. It is never a disappearing chat message.
• Shared state. The durable record every stage reads and writes: job ID, stage status, artifact locations, errors, and what is still pending. Without it, each worker starts blind and re-asks questions an earlier stage already answered.
• Contract. The written agreement for one role: what it receives, what it must return, which tools it may use, when it must stop, and what happens when it fails. A contract turns "the researcher researches" into something testable.

Structured output, not vague summary

The single most important rule: each stage passes structured output, never a conversational summary.

A vague handoff looks like this: "I found some interesting stuff about the company — revenue seems up, there were some risks mentioned, looks promising overall." The next stage cannot verify "seems up," cannot find which filing said so, and cannot tell what was skipped. Every downstream worker inherits the fog.

A contracted handoff looks like this:

# HANDOFF — researcher → analyst (job 2026-09-12-014)

## Input received
Lead #14 + source packet v3 (3 approved filings, retrieval dates included)

## Findings (structured)
- { claim: "Q2 revenue $4.1B, +8% YoY", source: filing URL, page, retrieved_at }
- { claim: "Gross margin 61%, down 2pts", source: filing URL, page, retrieved_at }

## Could not verify
- Segment split for APAC — filing references exhibit not yet retrieved

## Artifacts
- evidence/2026-09-12-014.json (2 records, schema v2)

## Next
Analyst: compare against prior quarter using ONLY evidence/*.json. Do not browse.

The analyst now has claims with provenance, an explicit gap, a file path, and a constraint. The validator later checks the draft against exactly that JSON file. This is the same handoff discipline Sonariq uses between its research stages (see Class 32.4): each stage's HANDOFF.md records objective, inputs, findings, decisions, validation, missing data, and next instructions.

Tying it to SweepsMonitor

SweepsMonitor, the controlled editorial system from Class 32.4, is this pipeline running in production on a VPS. Map its parts to the vocabulary above:

• Collectors are the discovery and researcher roles. They run on schedule, consult only approved sources, and build factual source packets. Their behavior is failed-closed: if a source is unreachable or unparseable, the collector records the failure rather than inventing a substitute.
• Validators are the validator role. They check drafts against required fields, source matches, and quality rules before anything moves forward. A draft that fails validation never reaches review — it returns to the queue with a defect list.
• Persistence is the shared state. A database records leads, evidence, drafts, validation results, and publication status, so any run can resume from reality instead of re-researching from scratch.
• GitHub handoff is the handoff to the human publisher. A validated draft arrives as a review pull request with its evidence attached. The human merges; the merge flips the publication status. No agent publishes silently.

Notice what the orchestrator is here: scheduling, queues, and worker code — visible infrastructure from Part VII — not a charismatic manager-agent. The intelligence sits inside bounded roles; the coordination sits in boring, inspectable software. That is the pattern to copy.

Practical exercise

Pick the editorial pipeline above (or your own workflow from 33.1) and write role contracts for three consecutive roles — e.g., researcher, writer, validator.

For each role, write these five lines:

1. Input: exactly what it receives (file path, record ID, schema version). 2. Output: exactly what it returns (schema, location, required fields). 3. Tools: which tools it may call — and one tool it must never touch. 4. Stop: the condition that ends its run (items processed, budget, or "evidence exhausted"). 5. Failure: what it writes when it cannot complete (defect list, missing-information note, queue return) — never a guess.

Finish line: three role contracts, each fitting on half a page, with no shared vague verbs ("research," "check," "handle") left undefined.

Verify: swap two contracts and ask: could the writer do its job using only the researcher's declared output, without asking a follow-up question? If not, the output schema is incomplete.

Common failure mode: contracts that say "output: a summary." Replace every "summary" with a field list: which claims, which sources, which gaps, which file.

Check your understanding

1. What does the orchestrator do, and why is it usually ordinary software rather than another clever agent? 2. Why must a handoff be structured output rather than a conversational summary? 3. In SweepsMonitor, which component plays the validator role, and what happens to a draft that fails?

Transition: the price of the pipeline

A pipeline with contracts is the best version of multi-agent work — and it still costs you something. Every handoff can duplicate, conflict, or go stale; every parallel branch can hide a disagreement until publication day. The final lesson in this class prices those coordination costs so you can decide when the pipeline is worth it.