If the steps are known, write the steps. Agents are for cases where the steps are not known — and they are far more expensive, in latency and money and debugging hours, than teams expect when they reach for them.
The decision tree
- Is the sequence of steps known in advance, for ≥80% of cases? → workflow.
- Is the variation in steps small (under 5 branches)? → workflow with a router.
- Is the sequence different almost every time, and is the agent meaningfully more accurate than a static flow? → agent.
- Is the agent recommendation high-stakes? → agent with HITL approval gate.
Why workflows usually win
- Cheaper. Workflows make 1 model call where agents make 5–15.
- Faster. Workflows complete in seconds; agents in tens of seconds.
- Easier to evaluate. Each step has a known input and expected output.
- Easier to debug. A failed step has a stack trace. A failed agent has a confused log.
- Easier to govern. Auditors love a flowchart. Auditors do not love an autoregressive loop.
When agents do win
Long-tail support cases where the user's intent isn't in your top-50 list. Research tasks that genuinely require iteration. Multi-system reconciliation where the path depends on what was found. In each of these, an agent's flexibility outweighs its cost — but only after you have tried and failed to capture the variation in a workflow.
The hybrid pattern
In production, most of our systems are workflows that contain agent steps. The outer shell is deterministic. One or two of the steps are agentic. This gives you the operability of a workflow and the flexibility of an agent. It also keeps your audit story simple — auditors look at the flowchart and see what's deterministic and what's not.
What the literature gets wrong
Agent papers benchmark on tasks that favor agents. Production benchmarks on tasks that favor workflows. Both are right within their context. Don't let "agentic AI" become a hammer. Most enterprise problems are nails for workflows.
Workflow first. Agent only when you can prove the workflow is insufficient.