"Agent" has become the default word for anything that makes more than one model call. Most of those systems are not agents in any meaningful sense — they are pipelines with a fixed sequence, and treating them as agents makes them worse.
The distinction is precise. In a chain, you wrote the control flow: step one runs, then step two, then a branch you specified. In an agent, the model decides what happens next based on what it observed.
What changed in 2026
- The pendulum swung back toward structure. After a period of building agents for everything, teams rediscovered that deterministic pipelines are easier to operate.
- Hybrid shapes became standard. A workflow whose individual stages happen to call agents proved more reliable than one large loop.
- Cost pressure forced the question. Agent loops are meaningfully more expensive, and finance departments started asking why.
- Debuggability became the deciding argument. A fixed path is reproducible; a model-chosen path is not.
The comparison
|
Prompt chain |
Agent loop |
| Control flow |
You write it |
Model decides |
| Same input, same path |
Yes |
Not guaranteed |
| Cost |
Predictable |
Variable |
| Latency |
Predictable |
Variable |
| Debugging |
Straightforward |
Requires tracing |
| Handles unforeseen situations |
No |
Yes |
| Failure mode |
A step fails, visibly |
Does not converge, quietly |
The reproducibility row carries most of the practical weight. When a chain produces a bad result, you know exactly which step ran and can inspect its input and output. When an agent produces a bad result, you first have to work out what path it took — which is why agent observability is a requirement for agents and merely nice for chains.
The test
Ask one question: could you write the steps down before seeing the input?
If yes, write them down. Extract, validate, transform, store. Classify, route, respond. Retrieve, rank, generate. These are chains, and implementing them as agents means paying a model to rediscover a sequence you already know, differently each time.
If genuinely no — if the sequence depends on what is found along the way, and you cannot enumerate the branches — that is where an agent earns its cost. Debugging an unfamiliar failure, researching an open question, navigating a codebase you have not seen: these do not have a knowable sequence.
Most tasks people build agents for are in the first category, and the tell is usually that someone wrote the steps in a design document before building the agent that discovers them.
The hybrid shape
The architecture that works best in practice is neither extreme: a chain whose stages call models, with an agent loop only at the stages that genuinely need one.
A document processing pipeline might be: extract text deterministically, classify with a model call, route on the classification, run an agent loop only for the ambiguous category, then validate and store deterministically.
Four of those five stages are fixed. One is an agent. The system is mostly predictable, mostly cheap, and handles the genuinely uncertain part properly. Cost and latency are bounded except in the branch where they need not be.
This also localises the failure. When something goes wrong, you know whether it was a deterministic stage — inspect the code — or the agent stage — inspect the trace.
Common mistakes
- Building an agent for a known sequence. Cost and unpredictability for no capability gain.
- Building a chain for genuine exploration. Fails on the first case you did not anticipate.
- One large agent instead of a chain of small ones. Harder to debug, budget, and resume.
- No tracing on the agent portion. Undiagnosable failures.
- Assuming agents are more capable. They are more flexible; a chain calling the same model is equally capable within its scope.
- Not bounding the agent stage. An unbounded loop inside an otherwise predictable pipeline is where the surprise bills come from.
FAQ
Are chains just workflows?
Essentially yes, with model calls as steps. The vocabulary varies; the property that matters is that you specified the control flow — see agentic workflows.
Can a chain have branches?
Certainly. Branching on a classification result is still deterministic control flow — you wrote the branches. What makes it an agent is the model choosing an action you did not enumerate.
How do I migrate an agent to a chain?
Trace real runs and look at the paths actually taken. If most runs follow one of a few sequences, encode those as a chain and keep the agent for the residual.
Which is better for latency?
Chains, almost always — fewer calls and no reasoning overhead deciding what to do next. Predictable latency also makes SLOs possible, per LLM latency budgets.
Where to go next
For structuring the deterministic portion, read agentic workflows. For the loop pattern when you genuinely need it, ReAct agents, and for breaking work into stages, task decomposition.