The fastest way to waste a quarter of engineering time is to build an agent when a workflow would have done. The slowest way to ship anything useful is to build a workflow when the work actually needs an agent.
We've shipped both, and we've shipped the wrong one. Here's the shape of the question we now ask before we touch any code.
Workflows are the default
A workflow is a series of steps with explicit branching. You write the logic. The system runs it the same way every time. When something breaks, you can point at the line.
If you can describe the work as a flowchart and the flowchart isn't embarrassingly large, build a workflow. They're cheaper to write, cheaper to debug, and the people who replace you in three years will thank you.
The catch is that "describable as a flowchart" requires real honesty. A
flowchart with 47 branches and four default cases that mostly mean "ask
Sarah" is not a workflow — it's a workflow trying to escape its own skin.
Agents are for irreducible judgment
You reach for an agent when the work has two properties:
- The space of inputs is too large to enumerate in advance.
- There's a judgment call inside the loop that doesn't compress into rules.
Customer support is the classic example. You can write rules for the ninety obvious cases. The other ten percent are why your team is exhausted. An agent earns its keep on that ten percent — and on the boring ninety, you wrap it in a workflow.
The middle ground people miss
Most of what we build is neither a pure workflow nor a pure agent. It's a workflow with a small agent inside one step: the step that requires judgment, retrieval, or rephrasing.
That hybrid shape has two huge advantages:
- Observability stays sane. You can still point at the line where things broke. The agent isn't deciding what to do next — it's deciding one specific thing inside a known step.
- You can replace the agent later. When the model improves, or when your judgment compresses into rules, you swap the step.
If you can break the work into a workflow where the agent only handles one or two steps, do that. The pure-agent loop is rarely the right answer.
The questions we ask first
When a team comes to us, before we suggest anything, we run through:
- Can you give me the rules? If yes, it's a workflow. If "well, it depends on the situation" — we're closer to needing an agent.
- What's the cost of a wrong answer? Higher costs mean more guardrails, more human-in-the-loop, more deterministic shape.
- How often does the work change? Volatile rules → agents (they generalize). Stable rules → workflows (they're cheap to keep).
- Who owns it after we leave? If the team can't maintain a Python service, we shouldn't build them one. The right tool is the one they can run on Tuesday morning.
A useful heuristic
If you can imagine a Notion doc that describes the entire process in under a page, it's a workflow.
If the process keeps slipping out of the doc — if every quarter the team asks "wait, do we still do it that way?" — there's an agent-shaped problem hiding in there. Find it.