# Pipeline, Flow, or Chain? Picking the Right Tool to Wire LLM Calls Together

> Source: <https://dev.to/phimage/pipeline-flow-or-chain-picking-the-right-tool-to-wire-llm-calls-together-46k5>
> Published: 2026-07-11 09:44:51+00:00

In the [previous post](https://phimage.github.io/blog/agents-as-planners/) I argued that agents are great

*planners* and DAGs are great *executors*. This one is the practical follow-up: when

you actually sit down to wire several LLM calls together, **what tool do you reach
for?**

Because the moment one prompt's output feeds the next, you've built a workflow —

whether you call it that or not.

```
download transcript → summarize → translate
       (tool)          (LLM)       (LLM)
```

That tiny pipeline is already the whole problem in miniature: a non-LLM step (fetch a

YouTube transcript), then a model call, then another model call that depends on the

first. Run it as one giant prompt and you lose visibility; split it into steps and you

gain debuggability — at the cost of more calls and more state to manage.

Half the confusion is vocabulary. The same idea ships under a dozen labels:

| Name | What it whispers |
|---|---|
| Chain | sequential, output → input |
| Pipeline | stages, data flowing through |
| Flow | branches and conditions |
| Workflow | general orchestration |
| Agent workflow | the model also decides
|

The word sets expectations. "Chain" promises a straight line; "agent workflow"

promises the thing might re-plan on you mid-run. Pick the label that matches how much

autonomy you're actually handing over — calling a deterministic two-step pipeline an

"agent" only invites disappointment.

There are two families of tools, and they solve different problems.

**LLM-native chaining libraries** — [LangChain](https://www.langchain.com/),

[LlamaIndex Workflows](https://docs.llamaindex.ai/en/stable/module_guides/workflow/),

[Azure Prompt Flow](https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/),

or visual layers like [Flowise](https://flowiseai.com/). These understand

*LLM-specific* concerns out of the box: prompt templating, passing context between

steps, token budgets, streaming, retries on a flaky model.

**General orchestrators** — [Airflow](https://airflow.apache.org/),

[Prefect](https://www.prefect.io/), [AWS Step Functions](https://aws.amazon.com/step-functions/),

[Azure Logic Apps](https://azure.microsoft.com/en-us/products/logic-apps). These treat

each LLM call as just another task in a DAG, and give you the heavyweight reliability

machinery: durable state, scheduling, checkpointing, audit trails, human approval.

The rule of thumb that falls out of the last post:

```
Few prompts, mostly LLM glue   → chaining library
Many steps, must not fail      → orchestrator (LLM call = one task)
The model decides the path     → agent, with one of the above underneath
```

Don't reach for a framework reflexively. If the task is genuinely simple, **one
well-crafted prompt** (few-shot or chain-of-thought) often beats a three-step pipeline

To get a feel for the moving parts I built [PromptKit](https://github.com/mesopelagique/PromptKit),

a small 4D toolkit where a chain is just named prompts piped together — the YouTube

example above, minus the download step:

```
var $result:=$runner.newChain().prompt("summarize").prompt("translate").run($transcript)

// $result.text     -> final translated summary
// $result.outputs  -> each step's output, for inspection
```

Nothing exotic — but writing it made the trade-offs tangible: where state lives, what

happens when step two fails, how you'd add a branch. Which is really the point. You

don't pick the tool by reading the marketing; you pick it by knowing whether your

problem is *LLM glue* or *reliable execution* — and most of the time, it's a bit of

both.

My take: "chain vs. workflow vs. agent" is less an architecture question than an

honesty question — how deterministic is your process, really? Name it accordingly,

then pick the lightest tool that survives the day you actually need a retry.