Pipeline Pattern
Agents arranged as fixed stages with typed hand-offs (Research → Analyze → Write → Review) trade flexibility for per-stage evaluation, replaceability and predictable cost.
Shape
A pipeline is the multi-agent version of a Unix pipe. Each stage receives a typed artifact, produces the next one, and knows nothing about stages beyond its neighbours. Research emits {sources: [...], notes}; Analyze emits {claims: [{text, support}]}; Write emits a draft; Review emits {approved, issues}.
Because the contracts are explicit, any stage can be a cheap model, an expensive model, or plain code. Review is often the stage that becomes deterministic first: schema validation, link checking and banned-phrase scans catch most issues without an LLM (Deterministic Evaluators).
Design rules
Define the artifact schema for every edge before writing any prompt. That schema is your test fixture: you can run Write against 50 stored Analyze outputs without ever running Research, which makes stage evals fast and cheap (Golden Datasets).
Keep back-edges bounded. A Review → Write loop is fine with a revision cap of 2; without a cap it is an agent loop in disguise. Persist the artifact after each stage so a failure in Write does not re-run Research's 40 web searches (Idempotency).
1type Research = { sources: { url: string; excerpt: string }[] }2type Analysis = { claims: { text: string; sourceIdx: number[] }[] }3type Draft = { markdown: string }4type Review = { approved: boolean; issues: string[] }5 6const stages = {7 research: (topic: string): Promise<Research> => runAgent(RESEARCH, topic, [search, readUrl]),8 analyze: (r: Research): Promise<Analysis> => callLlmJson(ANALYZE, r, AnalysisSchema),9 write: (a: Analysis, issues: string[] = []): Promise<Draft> => callLlmJson(WRITE, { a, issues }, DraftSchema),10 review: (d: Draft, a: Analysis): Review => lintDraft(d, a), // deterministic first11}Cost and latency profile
Latency is the sum of stage latencies — a 4-stage pipeline of 6 s stages is 24 s, always. That predictability is a feature for batch jobs and a problem for chat. If users are waiting, stream the Write stage and run Research in parallel shards.
Error propagation is the main risk: a wrong claim from Analyze becomes a confident paragraph from Write. Put validation between stages, not only at the end — checking that every claim cites an existing source index costs nothing and catches the most common hallucination path (hallucinated-citations).
Key points
- Stages communicate through explicit typed artifacts; that schema is the test fixture.
- Any stage can be swapped for cheaper models or deterministic code.
- Bound every back-edge; persist artifacts between stages.
- Latency is additive and predictable — good for batch, bad for chat.
- Validate between stages to stop error compounding.
When to use — and when not to
- The task is genuinely sequential with clear intermediate artifacts.
- You need per-stage metrics and the ability to replay stages offline.
- Batch or asynchronous workloads where predictability beats speed.
- The next step depends on runtime judgment — use a supervisor or a workflow graph with conditional edges.
- Interactive latency budgets under a few seconds.
- Only one stage really needs an LLM — then it is a script with one model call, not a pipeline of agents.
Failure modes
- Error compounding: early mistakes are amplified downstream.
- Unbounded review loops.
- Stage schemas drift as prompts change; downstream stages silently misread fields.
- Re-running the whole pipeline on a late failure because artifacts were not persisted.
Tradeoffs
Best debuggability of any multi-agent shape because every edge is an inspectable artifact.