Guide

AI Agent vs Workflow vs Pipeline: the real differences

Published 19 September 2026

Most arguments about whether something is an agent, a workflow or a pipeline are really one question: at any given moment, what decides the next step. In a pipeline the schedule and the data decide, in a workflow a branch you wrote decides, and in an agent the model decides. Everything else follows from that.

Workflow: a branch you wrote decides

Anthropic's engineering post Building Effective AI Agents, published December 19, 2024 by Erik Schluntz and Barry Zhang, draws the line this way: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths."

Predefined is the operative word. A model can do plenty of work inside a step, but the connective tissue between steps is code a human wrote. That is why Anthropic counts orchestrator-workers as a workflow, alongside prompt chaining, routing, parallelization and evaluator-optimizer, even though it describes that pattern's central LLM as dynamically breaking down tasks and delegating them.

Harrison Chase makes the same cut in Not Another Workflow Builder, on the LangChain blog, October 7, 2025, by locating a workflow's complexity in its shape: "This complexity is represented in the 'graph' of the workflow, which is represented in some DSL." You can print it out.

Agent: the model decides

Anthropic's counterpart definition: "Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

Anthropic does not treat the two as unrelated species: both sit under the umbrella of agentic systems, and the split is architectural. An agent is a workflow with the routing table deleted and a model in its place. In a workflow the set of possible paths exists somewhere you can read; in an agent it exists only at runtime.

Chase describes the consequence: "So the overall structure of an agent is simple (just a prompt + tools), though that 'prompt' can often times be pretty complex." The complexity does not disappear. It moves out of the diagram and into the prompt.

Pipeline: the schedule and the data decide

Pipeline is the least standardised of the three words, and neither source above defines it: Anthropic's taxonomy has no pipeline in it, and Chase's axis is workflows versus agents. It comes from data engineering, where it means a scheduled or triggered flow that moves and reshapes a body of records, and it got borrowed into AI without anyone agreeing on the borrowing.

So say which meaning you mean.

  • The data-engineering meaning: batch or streaming, source to transform to destination. The run starts from a clock or an arriving file rather than a person, and the problems are throughput, retries and not losing anything.
  • The loose meaning: "LLM pipeline" just means a chain of model calls, which is Anthropic's prompt chaining pattern, a workflow.

The nearest anchor in mainstream writing is IBM Think's contrast with traditional automation: robotic process automation follows predefined rules and design patterns, which IBM says can be sufficient for repetitive tasks that follow a standard structure. That is the pipeline temperament: fixed structure, high volume, value from reliability rather than judgment.

A warning about the word "workflow" itself

Anthropic and IBM Think use the word workflow in two incompatible ways. For Anthropic, a workflow is the less autonomous option, with predefined code paths. For IBM Think, "Agentic workflows are AI-driven processes where autonomous AI agents make decisions, take actions and coordinate tasks with minimal human intervention", and the page goes further: "In artificial intelligence (AI), a workflow is not agentic if it does not consist of an AI agent."

Both are defensible. They are not compatible. When someone hands you a document that says workflow, find out which dialect it is written in before you agree to anything.

The comparison

Pipeline, workflow and agent differ on four dimensions: what decides the next step, whether the path is known in advance, what failure looks like, and what it costs to run.

Pipeline Workflow Agent
What decides the next step The schedule and the data A branch you wrote The model, at runtime
Is the path known in advance Yes, and usually it is one path Yes, every branch is enumerated somewhere No, including how many steps it takes
What failure looks like A stage or a record fails, and the danger is losing records quietly An input hits a case the routing does not cover, so it takes a wrong branch or stalls Plausible wrong steps that compound, and loops that do not end
What it costs to run Roughly predictable per record Bounded by the longest path through the graph Not knowable from the structure, and higher

Anthropic states the cost and the compounding directly: "The autonomous nature of agents means higher costs, and the potential for compounding errors."

Chase puts the trade in one sentence: "Workflows give you more predictability at the expense of autonomy, while agents give you more autonomy at the expense of predictability." He adds the caveat that stops it becoming a slogan: "Notably, when building agentic systems we are in pursuit of reliably good outcomes, which neither predictability or autonomy alone guarantee." Autonomy does not buy you quality. It buys a different failure surface.

A decision procedure you can run

Work down the list and stop at the first yes.

  1. Can you write down every path the work takes, and is there only one? Build a pipeline. Spend your effort on scheduling, idempotency, retries, and making sure nothing is lost in silence.
  2. Can you write down every path, and there are several? Build a workflow. Spend your effort on the routing table, where the human approval sits, and the state that carries between stages.
  3. Is the number of steps genuinely unpredictable? Build an agent. Anthropic's stated condition is exactly this: open-ended problems where it is difficult or impossible to predict the required number of steps, and where you cannot hardcode a fixed path. Spend your effort on tool descriptions, stop conditions and guardrails, and test it where it cannot do damage.
  4. Still torn? Take the less autonomous option first. Anthropic's recommendation is to find the simplest solution possible and add complexity only when it demonstrably improves outcomes.

Chase offers a cross-check: his post maps complexity to solution in three rows.

Complexity Solution
Low A no-code agent
Medium A no-code workflow
High A workflow written in code, naming LangGraph

His low-complexity answer is an agent, not a workflow: a small agent with a couple of tools can be less machinery than a diagram doing the same job.

Where this fits if you use Bespoke Prompting

Bespoke Prompting keeps these as separate build types rather than one generic builder, and its optional routing layer picks between them with this article's questions: does it decide its own next step, does the route change with the outcome, does it run on a schedule, and is the main job moving records or reacting to one thing at a time. One rule there is worth borrowing: a description matching no signals produces a flat tie and nothing is selected, because silently routing to the wrong build type is treated as worse than not routing at all.

Sources

Suggested internal links