In this guide
Agent vs Workflow
A workflow wins whenever its steps can be spelled out ahead of time, no matter how many there are. An agent earns its place only when that's not possible. There, the right move at each point depends on what the last one turned up. Default to a workflow, and reach for an agent when a workflow genuinely can't be written.
Who decides an agent's steps
Put an agent and a workflow side by side, and the difference comes down to who's steering. In an agent, a model looks at the current situation and picks the next move itself — act, check something, or stop — for as long as the task takes. Nobody scripts that path beforehand; it gets worked out live, one decision at a time. The full mechanics, including the agent loop itself, are covered on the AI agent page.
What a workflow is
A workflow runs a fixed sequence of steps, in the same order, every time. It can absolutely use a model inside one of those steps — to classify something, generate text, or make a narrow choice. But the shape of the process itself is set in code, not decided by the model. A document-processing workflow might always run the same three steps: extract text, summarize it with a model, then save the summary. The model does real work in the middle step, but the order and number of steps never change. A fixed shape with one or two of those model-made decisions built in has its own name: the agentic workflow page covers it, with routing as a common example.
Agent vs workflow, side by side
| Agent | Workflow | |
|---|---|---|
| Who decides the next step | The model, at runtime | Code, written in advance |
| Steps known ahead of time? | No — the count and order can vary | Yes — fixed and predictable |
| Model calls per run | Several, chosen as it goes | Fixed, known before it runs |
| Where it can go wrong | At any decision the model makes | Only where the code itself has a bug |
| Best fit | Tasks whose steps depend on what's found along the way | Tasks whose steps are already known |
The test: can you list the steps in advance?
The test is whether a complete list of steps exists before you start coding. If one does, build a workflow, regardless of how long that list turns out to be. If step three can't be pinned down until you've seen what step two returned, a workflow won't hold. That's the real signal you need an agent — not a stylistic preference either way.
Two real scenarios. Sorting an incoming support ticket into one of three known categories is a workflow's job. The categories and what to do with each are already known, so a routing step handles the one part that needs judgment. Diagnosing an unfamiliar production error is an agent's job for the opposite reason. Nobody can hand the code a fixed list of what to check, because check four only makes sense in light of what check three found.
Plenty of real systems land between the two: a fixed shape like the routing example above, with a model making one or two of the calls inside it. See the agentic workflow page for when that middle ground fits better than either extreme.