AI Agents vs AI Workflows

The word agent now covers a chatbot with memory, a script that calls three tools in order, and a system that plans its own work. That range makes the word useless for deciding anything, which matters because the underlying choice is real and has consequences.

There is one question that separates the cases.

Who chooses the next step

The essential difference between an AI workflow and an AI agent is who chooses the next step.

In a workflow, your program holds the sequence. The model might classify a ticket, extract fields from a document or draft a reply, and when it finishes, your code decides what happens next. If step two succeeds, go to step three. If it fails, take the fallback you wrote. The model does work inside the steps; it does not choose them.

In an agent-like system, the model gets a goal and some freedom over what to do next. It looks at what came back from the last step and picks the next one: try a different search, call another tool, ask a question, stop.

Notice what the distinction is not about. It is not about tool use, because a workflow can call plenty of tools. It is not about how capable the model is. It is a fact about your program.

Tool use asks whether the model can request an action. Agent-like behaviour asks whether the model can decide which action or step should happen next.

What each one is good at

A workflow's advantage is that you can enumerate what it does. Every path was written by someone, so every path can be tested, reviewed as a diff, and reasoned about before it runs. When it fails it fails at an identifiable step. The cost is rigidity: an input that falls outside the branches you anticipated either stops or goes to a person.

Agent-like freedom earns its place when the path genuinely cannot be written in advance. Investigating why something broke, researching across sources where each answer changes the next question, working through an ambiguous request: in these, the next step depends on what the last one returned, and enumerating the possibilities beforehand is not realistic.

The cost is the same property viewed from the other side. Once the model selects steps, the set of possible runs is larger than you can enumerate, so you cannot review it as a list of paths. Failures become harder to reproduce, and cost and latency stop being predictable.

Most systems are somewhere in between

Most working systems sit somewhere between the two rather than at either end.

The common shape is an outer sequence you control with a pocket of freedom inside it. The overall lifecycle and its checkpoints are fixed; within one step, the model may choose among a handful of allowed operations. This is neither a pure workflow nor an unconstrained agent, and describing it as one or the other loses the information you need.

So the question worth asking about a design is not "is this an agent". It is where is choice genuinely valuable, and where does it cost more than it returns.

	Choose a fixed sequence when	Let the model choose when
Consequence	Actions are hard to undo: payments, deletions, messages to customers	Steps are cheap and reversible
Input shape	Inputs are standardised and the processing is understood	Inputs vary in ways you cannot enumerate
Cost and latency	Predictability matters	Some variance is acceptable
Debugging	You need to reproduce a run exactly	You can afford to inspect runs individually

A useful habit: grant freedom at the smallest scope that solves the problem. Freedom over which of four tools to use is a different proposition from freedom over what the whole task should be.

What this does not settle

Deciding the model may choose the next step says nothing about what it is allowed to do when it chooses. Those are separate questions, and the freedom to select a step is not the same as permission to perform it.

What happens between a chosen step and a real effect is from agent intent to governed execution.