Guide

When to use a pipeline spec instead of a workflow spec

Published 14 September 2026

Most writing about AI systems uses "workflow" and "pipeline" as the same word. They are not the same thing, and which one you are building decides what your spec has to answer, because the two have different correctness conditions.

The industry really does use the words loosely

None of the sources cited here separates a pipeline from a workflow. Anthropic splits agentic systems into workflows and agents, IBM sets agentic workflows against rule-based automation, and LangChain frames workflow against agent. The distinction below is drawn here, not borrowed from them.

Anthropic's engineering post "Building Effective AI Agents" splits agentic systems into workflows and agents, and its definition of a workflow is deliberately broad: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths." Under that umbrella it names prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer. None of them is called a pipeline. Prompt chaining, which Anthropic describes as decomposing a task into a sequence of steps where each call processes the output of the previous one, is what many engineers mean when they say pipeline.

IBM Think's page on agentic workflows runs a different axis: agentic workflows against traditional rule-based automation such as RPA, which IBM characterises as following predefined rules and design patterns. That is dynamic versus rule-bound, not batch versus case. Harrison Chase's LangChain post "Not Another Workflow Builder" keeps the workflow-versus-agent axis, framed as predictability against autonomy, and its complexity table runs from a no-code agent to a no-code workflow to a workflow written in code. No row is a pipeline.

So do not expect the distinction below to be backed by those sources. It is drawn here, and the reason to take it seriously is not authority but consequence: a spec that gets the correctness condition wrong ships the wrong guarantees.

The distinction

A workflow shepherds one case through branching decisions. A refund request, a candidate, a support ticket. The steps are known, but which steps this particular case visits is not, and the route is part of the answer.

A pipeline moves a body of records through fixed transformations on a trigger or a schedule. Every record goes through roughly the same stages.

Question Workflow Pipeline
Unit of work one case a body of records
What starts it an event about that case a schedule, or a batch trigger
What varies between runs the route taken the records, not the steps
Core correctness question did this case reach the right end state by the right route did every record land somewhere
Signature failure the case stalls in a state nobody owns a record vanishes and the run reports success
Where a human sits an approval gate inside the route a review queue for records the run could not place

The one-line test

If you would naturally describe the job as records per night, it is a pipeline. If you would describe it as one case at a time, from the event that starts it to the decision that ends it, it is a workflow.

Re-score every open lead each night and write the score back is records per night. When a refund request comes in, decide whether it needs a manager is one case at a time. You rarely have to think hard about which sentence you would say out loud.

The hybrid trips people up. A nightly job that classifies each record and sends it to one of several destinations still passes the pipeline test: a conditional inside a stage is a transformation, not routing. What makes something a workflow is that the route is part of the deliverable, because someone cares which path this case took and who approved it.

Completeness, not routing

A workflow is correct when the case reached the right end state by a defensible route. A pipeline is correct when nothing was lost. Write the completion condition in exactly those terms. For a batch run: every record processed, either passed or parked in a dead letter queue, with none silently dropped. For a streaming run: the epoch drained with no unhandled errors.

The failure it defends against is specific. A record hits a parse error in a middle stage, an exception handler swallows it, and it appears in neither the output nor the error log. The run reports success, and the shortfall surfaces weeks later when someone reconciles totals, by which point the source data may be gone. Routing bugs announce themselves, because a case sits there visibly unfinished. Completeness bugs do not.

Four things a pipeline spec must answer

The four are an idempotency strategy, pre-conditions checked before the first record is touched, a dead letter queue with a human re-injection path, and per-stage cost and token tracking with alerts.

Idempotency. Anything on a schedule gets double-triggered eventually: a retry after a timeout, a manual re-run by someone unsure the first one worked. State the idempotency strategy explicitly, a run key or upsert writes, so a second trigger does not double-write. A workflow started by a real-world event rarely needs this, because the event carries its own identity.

Pre-conditions checked before the first record is touched. Source reachable, destination writable, and no other instance of this pipeline already running. A half-finished pipeline is worse than one that refused to start, and a concurrent second instance is how you get duplicate writes and interleaved partial state.

A dead letter queue with a human re-injection path. The queue is the easy part. What specs usually omit is how a record gets out of it: who reviews it, what they may change, and how the corrected record re-enters at the stage it failed. A dead letter queue nobody can re-inject from is a slower way of losing data.

Per-stage cost and token tracking, with alerts. A workflow handles one case at a time, so its cost stays visible. A pipeline multiplies whatever each stage costs by the whole record count, and you find out at the end of the billing period. Tracking per stage rather than per run tells you which transformation is the expensive one.

Workflows need a different set:

  • routing logic written as a complete decision tree
  • an explicit place where the human gate sits
  • a state schema that survives a resume
  • a measurable completion predicate

Neither set does much for the other, and that asymmetry is the argument for treating them as separate build types.

When it is neither

If you cannot write the stage list up front, because which steps run depends on what the model finds partway through, you have an agent and should spec it as one. Anthropic's guidance is worth borrowing: agents suit open-ended problems where the number of steps is difficult or impossible to predict and no fixed path can be hardcoded, and complexity is worth adding only where it demonstrably improves outcomes. A fixed sequence of transformations is not a weakness to be upgraded away from. It is the property that makes completeness checkable.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's Pipeline build type emits DEAD_LETTER_QUEUE and COST_TRACKING as sections in their own right, alongside TRANSFORMATION_LOGIC and STATE_SCHEMA, and a scheduled pipeline has to state an idempotency strategy, a run key or upserts, before the spec is complete. Its Workflow build type emits ROUTING_LOGIC and a human-in-the-loop protocol instead. The two disagree about which sections are mandatory because they disagree about what correctness means.

Sources

Suggested internal links