Agents vs workflows: who decides the next step?

In a workflow, the control flow — which LLM call happens after which, and with what — is written by you, in code, ahead of time. In an agent, the model itself decides its next action at runtime, in a loop: plan, call a tool, observe the result, decide again, until it judges the task done. The difference isn't capability, it's who's driving.

Start with the simplest workflow that solves the problem. Reach for full agentic autonomy only when the task's unpredictability genuinely requires it — an agent loop costs more in latency, dollars, and reliability risk than a fixed sequence of calls, so that cost needs to buy you something a workflow structurally can't provide, not just feel more impressive to build.

"Workflow" and "agent" aren't two discrete categories so much as two ends of a spectrum measured by how much of the control flow you hand to the model. A simple prompt chain (call 1's output feeds call 2, always) is a pure workflow. A router (the model picks one of N predetermined paths, but the path itself is fixed once chosen) hands the model a little control — more agent-like than a chain, but still bounded and enumerable. A full agent loop with an unbounded number of tool calls and no predetermined stopping point sits at the far end, where the model controls not just which path but how many steps it takes and when it's done.

The real engineering decision, then, isn't "workflow or agent" as a one-time architectural choice — it's incrementally deciding, task by task and even sub-task by sub-task, how much of the control flow genuinely needs to be dynamic. Most production systems that call themselves "agents" are actually a workflow with one or two genuinely agentic components embedded in it, not autonomy end to end.

Triaging an incoming support ticket — classify it, route it to one of five fixed handlers (billing, bug report, feature request, account access, other) — is a workflow: the five categories are known in advance, the routing logic is stable, and hardcoding "if billing, go here" is both cheaper and more reliable than letting a model improvise a route it might get wrong in a way that's hard to catch. This handles the large majority of incoming tickets cheaply and predictably.

But "investigate this obscure production bug using logs, code search, and running tests to reproduce it" cannot be hardcoded into a fixed path, because you genuinely don't know what the investigation will find — the next useful action (check this log, grep for that error, run this specific test) depends entirely on what the previous action turned up. That's an agent loop, deliberately reserved for the minority of tickets that actually need open-ended investigation, while the cheap, predictable workflow handles routing for the other 90%.