You have a task. It needs to call an API, summarise the result, and write the output to a file. You reach for an agent. It feels like the right tool β modern, flexible, capable of reasoning its way through whatever comes up. The agent runs. It gets partway through, second-guesses itself, calls the API twice, writes an incomplete file, and loops. Five minutes and a few thousand tokens later, you have a bug report to write.
The three-step pipeline you needed was knowable before you wrote a line of code. The path was fixed. An agent was the wrong shape for a fixed path.
The alternatives you should reach for first
Not everything that involves an LLM needs an agent. Anthropicβs Building Effective Agents draws a clear and useful line: a workflow is a system where the LLMβs actions are orchestrated by predetermined logic; an agent is a system where the LLM itself decides the steps. The distinction matters because agents are expensive to run and hard to predict. Most tasks donβt justify both of those costs.
The workflow patterns are the boring defaults β and boring defaults are right more often than they get credit for:
Prompt chaining runs a fixed sequence: the output of one LLM call becomes the input of the next. Translation then editing then formatting. Extraction then summarisation. The path is a list. Code it as a list.
Routing inspects the input and sends it down one of several fixed branches. A customer message is classified β billing, technical, general β and handed to the branch that knows how to respond. The LLM decides which branch at the start, then the branch runs deterministically. No open-ended step-picking at runtime.
Parallelisation runs several fixed calls at the same time and combines the results. You need three independent analyses of a document: run them in parallel, join the outputs. No coordination overhead, no shared state, nothing for the models to trip over.
Evaluator-optimiser runs one call to produce an output, then a second to critique it, in a fixed loop until a criterion is met or a step count is reached. The loop is bounded. The logic is known in advance. The model doesnβt invent the loop; the code drives it.
Each of these patterns uses an LLM for what an LLM is genuinely good at β language understanding, flexible generation, qualitative judgement β without asking the model to manage its own execution. The structure comes from code. The LLM fills slots in that structure.
When an agent actually earns its place
There is a real class of tasks where the path genuinely cannot be drawn in advance. The next step depends on what the current step finds. The work requires making a sequence of decisions where each decision narrows the space of reasonable next decisions β and that narrowing canβt be reduced to a finite set of branches you write beforehand.
A research task that needs to follow a trail: find a paper, scan its references, follow two of them, find a contradiction, look for a third source to resolve it. You donβt know when you start which references matter or whether the contradiction will appear. An agent earns its place here because the LLM must direct its own steps; thereβs no other way to encode βfollow whatβs relevantβ.
A debugging task where the agent reads an error, hypothesises a cause, writes a fix, runs the tests, reads the new error, and updates its hypothesis. The loop length is unknown. The branches are too many to enumerate. You need a model that can revise its plan from evidence.
The deciding question is whether the path is knowable before execution. If yes, encode it. A workflow is more predictable, cheaper to run, easier to debug, and faster to iterate. If no β if the task genuinely requires the model to discover the structure as it goes β then an agent is the right tool, and you should build one deliberately.
Where an agent loses
The cost of choosing an agent when a workflow would have sufficed is specific and documented. Community research consistently finds that fully autonomous agent systems run at roughly 15 times the token cost of a simple single call (this is a widely cited finding from the agent-design community, not a precise universal figure β treat it as an order of magnitude). For a simple or medium-complexity task, that overhead buys nothing. You paid for the model to manage its own reasoning; the task didnβt need managed reasoning.
Agents also introduce failure modes that workflows donβt have. An agent can stall in a reasoning loop. It can take an action that seemed locally reasonable but is globally wrong. It can lose the thread across a long context and contradict a decision it made ten steps ago. These are not bugs to be fixed β they are properties of open-ended planning in a model. Workflows, by contrast, fail in well-understood, reproducible ways: a step fails, an output is malformed, a branch condition mismatches. Failures that have shapes are failures you can handle.
Agents are not better. They are different β and the difference is appropriate for a narrower set of tasks than they are typically given.
The escalation line
Start with the simplest pattern that could work: a single prompt, then a chain, then routing, then parallelisation, then an evaluator loop. Reach for a single-agent architecture only when that landscape canβt be mapped in advance. Reach for a multi-agent structure only when a single agent has genuinely hit its ceiling β and that ceiling has its own discussion.
The anatomy of what a multi-agent structure looks like when itβs genuinely warranted lives in a separate place: The Coordinator, the Worker, and the Delegator. That post covers the pattern. This one is about deciding whether you need it at all.
The most important judgement in building with LLMs is not how to architect a sophisticated system. It is knowing when a sophisticated system is the wrong answer.