The hype cycle problem
For the last 18 months, 'AI agent' has been the marketing word attached to anything an LLM touches. That's fine for pitch decks and a disaster for architecture. The choice between a workflow and an agent has real cost implications, real reliability implications, and real debuggability implications.
The rule most teams settle on after the first painful production incident: build the workflow first, and let a real failure — not a hypothetical one — drive the agent upgrade.
Definitions that actually help
A workflow is a fixed sequence of steps with LLM calls at specific points. The graph is defined by the developer. The LLM decides what to say, not what to do next.
An agent is a loop where an LLM decides what to do next — which tool to call, when to stop, what to try after a failure. The graph is dynamic and shaped by the model.
Everything else — 'agentic', 'multi-agent', 'autonomous' — is a variation on those two shapes. Get clear on which you're building before you name it.
Workflow-first as the default
Workflows are easier to test, easier to debug, cheaper to run, and easier to hand to another engineer. They also fail in predictable ways — a step returns a bad value and you know exactly where to look. Agent failures cascade across many steps in ways that are painful to reproduce.
If your problem can be expressed as a linear or branching flow with LLM decisions inside boxes, build it as a workflow. Most 'agent' problems look like this on close inspection.
When agents genuinely win
Three situations where an agent is the right choice:
- The problem's shape isn't known ahead of time — e.g., an open-ended research task where the sub-questions depend on what's found.
- The tool space is large and choosing dynamically is cheaper than pre-routing — e.g., a Claude+MCP agent with 20 tools where hardcoding the routes is more complex than letting the model decide.
- The user's request is genuinely conversational — a coding assistant, a research assistant — and the loop is the product.
The hybrid pattern
The most reliable production systems we see are workflow-shaped with one or two agent-shaped nodes inside them. A support ticket triage workflow with an agent-shaped 'clarify with the customer' node. A content pipeline with a workflow overall and an agent inside the research step.
This gets you the debuggability of workflows and the flexibility of agents where flexibility actually matters. It also localizes the risk — when the agent misbehaves, it does so inside a boundary the workflow enforces.
How to evaluate the choice
Ask three questions before writing code. Can you list the steps ahead of time? If yes, it's a workflow. Does the model need to choose from more tools than you'd want to route by hand? If yes, an agent may pay off. Is the loop itself the product? If yes, you're building an agent by definition.
Then build the boring version first. The exciting version is easier to justify when the boring version is a real thing shipping in production.