Agents or Workflows? Knowing Which You Need

"Agent" has become the default word for anything involving a language model and more than one step. The distinction worth keeping is narrow and practical: in a workflow, you decide the sequence; in an agent, the model does.

That single difference determines how the system fails, how you test it, and how much it costs to run.

Workflows: you own the control flow

A workflow is ordinary software with model calls in it. Classify the request, retrieve some context, generate a draft, validate it, write it to the database. The path is fixed. Branching is explicit.

The advantages are the advantages of ordinary software. You can test each step. You can reason about cost, because the number of calls is bounded. Failures are localised and debuggable. Most tasks people call "agentic" are workflows, and are better as workflows.

Agents: the model owns the control flow

An agent decides which tool to use, in what order, and when it is finished. This buys genuine flexibility for open-ended problems where the right sequence is not knowable in advance.

It costs you predictability. The same input can take a different path on different runs. Cost per task is variable and unbounded without explicit limits. And debugging becomes archaeology — reading a trace to work out why the model chose a path.

Choosing

If you can draw the flowchart, build the flowchart. A problem you can describe as a sequence of steps does not need a model to discover that sequence at runtime, and paying it to do so on every request is poor engineering.

Reach for an agent when the path genuinely varies by input, when the tool set is large enough that hard-coding every combination is impractical, or when the task is exploratory by nature.

If you do build an agent

• Cap iterations. A hard step limit prevents a loop becoming a bill.
• Make tools narrow. Tools that do one thing with clear parameters are chosen correctly far more often than tools with broad, overlapping scopes.
• Gate side effects. Anything that sends, deletes, charges or publishes should require explicit approval. Reading is cheap to get wrong; writing is not.
• Trace everything. You cannot debug what you did not record. Capture the full sequence of calls, tool inputs and outputs.
• Make tools idempotent. Agents retry. A retried action that double-charges a customer is a serious bug.

The practical middle

Most good systems are workflows with small agentic pockets — a fixed pipeline where one step is allowed to reason freely within tight bounds. You get determinism where you need it and flexibility where it earns its place.

Starting with a workflow and introducing agency only where the fixed path genuinely fails is the cheaper order. Starting with a fully agentic design and trying to constrain it afterwards rarely converges.