In the previous post 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,
or visual layers like Flowise. 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,
Azure 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,
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.