As language models have become components in automated systems, two architectural patterns have emerged for orchestrating them. The first is the workflow, in which a model is invoked at fixed points within a predetermined sequence of steps. The second is the agent, in which a model decides for itself which actions to take and in what order. The two are often discussed interchangeably, yet they suit very different problems. This article offers a framework for choosing between them.
Defining the Two Patterns
A workflow is a sequence of steps whose structure is fixed by the developer. Control flows through a graph that the author designed in advance; the model may classify an email, extract fields, or draft a reply, but the path from input to output does not change between runs. Workflow automation platforms such as n8n model this explicitly as nodes connected by edges, where each node performs a defined operation.
An agent, by contrast, is given a goal and a set of tools and decides at runtime which tools to call and how to sequence them. Anthropic’s documentation characterizes agents as systems in which the model directs its own process, looping until it judges the task complete. The control flow is emergent rather than authored, which is precisely the source of both an agent’s flexibility and its unpredictability.
The Central Trade-Off
The choice between the patterns is fundamentally a trade-off between predictability and flexibility. A workflow is predictable: because its structure is fixed, its behavior can be tested exhaustively, its cost per run is bounded, and its failures occur at identifiable points. An agent is flexible: it can handle inputs the author did not anticipate and tasks whose required steps vary from case to case. That flexibility comes at the price of predictability—an agent may take a different path each time, its token consumption is harder to bound, and its failures can be diffuse.
When a Workflow Is the Right Choice
A workflow is appropriate when the steps required to complete a task are known in advance and do not vary meaningfully between cases. Processing incoming invoices, routing support tickets by category, or enriching records in a database are well served by workflows, because the sequence of operations is stable even though the data changes. The guidance from Anthropic is consistent on this point: one should prefer the simplest pattern that solves the problem, and add agentic autonomy only when the task genuinely demands it. Most production automations fall into this category.
When an Agent Is Justified
An agent earns its added complexity when the path to a solution cannot be specified in advance. Tasks that involve open-ended investigation, where the next step depends on what previous steps discovered, are candidates—for example, debugging across an unknown codebase or researching a question whose answer requires following an unpredictable trail of sources. If you can draw the flowchart, build the workflow; if the flowchart would need a branch for every conceivable situation, an agent may be warranted. Even then, constraining the agent’s available tools and setting explicit stopping conditions is essential to keep cost and behavior in check.
A Pragmatic Middle Ground
The two patterns are not mutually exclusive. A robust system often embeds bounded agentic steps within an otherwise deterministic workflow. A pipeline might process records through fixed stages while delegating a single ambiguous sub-task—such as reconciling conflicting data—to a constrained agent. This hybrid preserves the testability of the workflow for the majority of the process while reserving autonomy for the narrow portion that truly requires it.
Conclusion
The decision between an agent and a workflow should be driven by the nature of the task, not by the appeal of the more sophisticated pattern. Where the steps are known, a workflow delivers predictability, bounded cost, and straightforward testing. Where the path genuinely varies with the input, an agent provides necessary flexibility at the cost of determinism. Choosing the simplest pattern that solves the problem—and reserving autonomy for the parts that demand it—is the discipline that keeps automated systems reliable and affordable.