Catalog / Orchestration

Pipeline

A fixed chain of narrow stages. Each stage transforms its input into an explicit artifact and hands it to the next; no stage sees the whole task.

Reference task used across all patterns: "My order arrived damaged. Can I get a refund?"

Topology

ActorWorker

Run

09 steps

Ready to run

Play runs the whole scenario. Step advances one event at a time so you can read what happens.

Metrics

Wall-clock time0.0 s
Tokens processed0
Estimated cost$0.000
Stages since error
0
Illustrative values. They show proportions between patterns, not benchmarks.

All steps

Normal run

  1. Request arrives. There is no lead agent. The order of the stages is fixed in code, and the request simply enters the first one.
  2. Intake. Intake has one narrow job: turn free text into a structured ticket with the customer, order 4417 and the complaint.
  3. Pass the ticket. The artifact between stages is explicit and typed. The next stage reads the ticket, not the conversation.
  4. Classify. The classifier labels the ticket as a damage claim. A prompt this narrow works well on a small, cheap model.
  5. Pass the label. Only the label and the ticket move on.
  6. Policy check. The damage rule applies. Delivered 12 Sep, inside the 30-day window, damage confirmed by the carrier.
  7. Pass the decision. The decision travels on as data, separate from the wording.
  8. Write the reply. The writer turns the decision into a message. It never decides anything itself.
  9. Respond. Refund approved. Four small models in a row cost far less than one large agent, and each stage can be tested alone.

Outcome: correct answer. Every stage did one simple thing and passed on an explicit artifact. The chain is cheap, predictable and easy to test, because nothing in it is decided at run time.

Failure mode

  1. Request arrives. Identical start to the normal run.
  2. Intake. The ticket is extracted correctly.
  3. Pass the ticket. Nothing has gone wrong yet.
  4. Misclassified. The classifier keys on “arrived” and labels the case as a shipping issue. Its output is well-formed, so nothing downstream will question it.
  5. The wrong label moves on. From here the mistake is no longer an output. It is the next stage's input.
  6. Right rule, wrong case. Policy check applies the late-delivery rule. The parcel arrived on 12 Sep, on time, so it correctly concludes that no compensation is due.
  7. The wrong decision moves on. Each stage trusts its input completely. That trust is what makes a pipeline cheap.
  8. A fluent refusal. The writer produces a polite, confident rejection. Every stage after the classifier did its own job well.
  9. Incorrect response. The customer with a damaged order is told the delivery was on time. The error is three stages old and invisible in the output.

Failure: error propagation. A pipeline has no way back, so an early mistake rides to the end. Mitigation: validate at stage boundaries, pass evidence along with each label, and check the final answer against the original request.

Execution trace

Model workingSending a message

Reference

Problem
The task splits into fixed steps, each simple enough for a small model and a narrow prompt.
Analogy
An assembly line. Each station does one operation and passes the part on, and a defect introduced early rides to the end of the line.
Use when
The steps are known in advance and always run in the same order, and you want each one cheap, testable and replaceable.
Avoid when
The path depends on what is found along the way, or an early mistake is expensive. A chain has no built-in way to go back.
Typical failure
Error propagation: an early wrong output is treated as fact by every later stage.
Also known as
Prompt chaining (Anthropic)Sequential orchestration (Microsoft)SequentialAgent (Google ADK)
Related patterns
Sources

Space play or pause   → next step   ← previous step  R reset   F failure mode