A workflow follows a fixed, predetermined sequence of steps defined in code, where each step's logic and order are set in advance, while an agent dynamically decides its own sequence of steps and tool calls at run time based on the input and intermediate results it encounters. In a workflow, a large language model might handle one or more individual steps, such as summarizing a document or classifying an intent, but the overall control flow, branching and step order are fixed by the developer, which makes workflows predictable, easy to test and cheap to run. An agent instead reasons about what to do next at each turn, which makes it far more flexible for open-ended tasks with unpredictable paths but also less predictable and more expensive, since it typically makes more model calls to figure out its own next step. Common guidance on this distinction is to default to the simplest workflow that solves the problem and only reach for full agent autonomy when task variability genuinely requires the model to make its own routing decisions. Many production systems land in between, using a workflow with an agentic sub-step for the one part of the task that needs judgment. Nanobase AI starts every engagement by determining which category a task truly falls into before building anything.
Five named workflow patterns cover most cases that feel like they need an agent
A large share of tasks that get proposed as "agent" projects are actually well served by one of a small number of fixed workflow patterns, where a large language model handles individual steps but the overall control flow is set by the developer rather than decided by the model at run time. Naming these patterns explicitly makes it much easier to recognize when a task fits one of them instead of reaching for full autonomy by default. Most tasks that feel like they need an agent are actually a workflow pattern in disguise.
| Pattern | Structure | Good fit |
|---|---|---|
| Prompt chaining | Fixed sequence of LLM calls, each step's output feeding the next | Multi-stage tasks with a known, unchanging order |
| Routing | A classification step sends the request down one of several fixed paths | Requests that fall into distinct, known categories |
| Parallelization | Independent sub-tasks run simultaneously, results aggregated | Tasks decomposable into parts with no dependency between them |
| Orchestrator-workers | A controller dynamically assigns sub-tasks, but the overall structure is fixed | Tasks where the number or nature of sub-tasks varies per request |
| Evaluator-optimizer | One call generates, a second evaluates and requests revision, looped until acceptable | Tasks where output quality benefits from iterative self-critique |
Why the fixed-versus-dynamic line is the real distinction
The difference between these workflow patterns and a true autonomous agent is not whether an LLM is involved in the decision, since routing and orchestrator-workers both use a model to make a choice. The difference is whether the space of possible next steps is bounded and known in advance by the developer, as in a workflow, or open-ended and decided by the model at run time based on whatever it encounters, as in an agent. A routing workflow's model picks among a fixed, small set of predetermined paths; an agent's model can decide to call any combination of its available tools in any order, including sequences the developer never explicitly anticipated.
Default to the simplest pattern that solves the problem
Common guidance is to default to the simplest workflow that solves the problem and only reach for full agent autonomy when task variability genuinely requires the model to make its own routing decisions, because workflows are more predictable, easier to test exhaustively, and cheaper to run than an agent re-deciding its own next step on every turn. This is not a conservative fallback position; it reflects that most enterprise tasks, once actually mapped out, have a knowable structure that does not benefit from the added unpredictability and cost of full autonomy.
A decision sequence for a new task
Mapping the task before choosing an architecture catches most cases where "this needs an agent" turns out to be a five-minute misreading of a fixed process.
- Map out the task's actual steps as they occur today, even if performed manually, before assuming it needs agentic flexibility.
- Check whether the sequence and branching of those steps is knowable in advance; if so, one of the five workflow patterns almost certainly fits.
- Identify whether variability exists specifically in how many sub-tasks are needed or what order makes sense, which points toward orchestrator-workers rather than full autonomy.
- Reserve true agent autonomy for the specific sub-portion of the task where the model genuinely must decide its own path through the problem, not the whole task by default.
Hybrid systems are the common real-world outcome
Many production systems land in between these two categories, using a workflow as the overall structure with one agentic sub-step embedded at the specific point that needs judgment. A document-processing pipeline might use prompt chaining for extraction, validation and formatting, all fixed steps, but embed a small agentic loop specifically for resolving ambiguous or exception cases that do not fit the standard extraction pattern. This keeps the predictable, cheap majority of the pipeline as a workflow while isolating the model's autonomy to exactly where it earns its cost.
Frequently asked questions
Is routing considered a workflow or an agent?
Routing is a workflow pattern, because the possible destinations are fixed and known in advance by the developer; the model only chooses among them, it does not invent a new path. This distinguishes it from an agent, which can combine tools in sequences the developer did not predetermine.
Can a workflow use a language model at every step and still not be an agent?
Yes, all five patterns described here can use an LLM at every single step; what keeps them workflows rather than agents is that the developer, not the model, decides the overall sequence and branching structure in advance.
When does an orchestrator-workers workflow become a multi-agent system?
The line blurs when the orchestrator's assignment logic becomes flexible enough that it is effectively deciding an unbounded set of possible task decompositions rather than choosing among a fixed set of known sub-task types. In practice, many production orchestrator-workers systems sit close to this boundary and are described using either term.
Does choosing a workflow over an agent limit future flexibility?
Not significantly, since a workflow can have an agentic sub-step added later at the specific point that turns out to need more flexibility than initially assumed, without needing to convert the entire pipeline to full autonomy. Starting simple does not foreclose adding autonomy where it is later proven necessary.
How Nanobase AI helps
Nanobase AI starts every engagement by determining which of these patterns a task truly falls into before building anything, matching structure to actual variability rather than defaulting to full autonomy. This assessment feeds directly into what agent orchestration actually involves and into recognizing when an agent is the wrong tool entirely.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.