Chatbot, Workflow, or Agent? Pick the Simplest Thing That Works
Six weeks building an agent for a task with three fixed steps. One question — can you draw the flowchart before seeing the input? — separates the three architectures and saves most of that time.
A team spent six weeks building an agent to process incoming invoices. Extract the fields, validate them, route to the right approver. It worked, mostly, with occasional bewildering failures nobody could reproduce.
The task had three steps, in a fixed order, every time. It was a workflow with a model call in the middle, and building it as an agent added a decision-making layer to a problem with no decisions in it.
The three architectures suit genuinely different problems, and picking the heaviest one by default is the most common expensive mistake in this space.
The three
A chatbot is one model call, possibly with retrieval, possibly in a conversation. No tools that act, no loop. It answers.
A workflow is code you wrote, with model calls at specific points. The control flow is yours: fixed steps, explicit branches, a loop you can read. The model does language work — extract, classify, summarize, generate — inside a structure it doesn't control.
An agent decides what to do next. The model chooses which tool to call and when to stop; the sequence differs run to run, and that variability is the feature.
The dividing line that matters: who owns the control flow. In a workflow you do. In an agent the model does. Everything else — tools, retrieval, memory — appears in all three.
The question that decides it
Can you draw the flowchart before seeing the input?
If yes, build the workflow. Fixed sequences deserve fixed code: it's cheaper, faster, debuggable with a stack trace, testable with ordinary tests, and it fails in ways your existing tooling already handles.
If the flowchart depends on what you find — the next step is determined by the previous result in ways you can't enumerate — that's an agent, and the variability you're paying for is buying something real.
The invoice example fails this test immediately. Extract, validate, route. Same three steps, every invoice, forever. The variation was in the content, which a model call inside a workflow handles perfectly.
What each costs
| Chatbot | Workflow | Agent | |
|---|---|---|---|
| Calls per task | 1 | fixed, known | variable, unbounded |
| Debugging | read the prompt | stack trace | read the trace, reconstruct the reasoning |
| Testing | input/output | ordinary tests | trajectory evals, run N times |
| Failure mode | wrong answer | broken step, loud | wrong sequence, quiet |
| Latency | one call | predictable | unpredictable |
The agent column is not worse — it's the cost of dynamic control flow. It's worth paying when you need that. It's pure overhead when you don't. ⚠️ Note especially the failure row: workflows break loudly at a specific line, agents go subtly wrong in a way that requires reading a transcript to notice.
The middle ground people miss
Most real systems are a workflow with agentic steps. The overall shape is fixed; one or two steps inside it are open-ended.
Invoice processing, done properly: extract (model call), validate (code), route (code) — and when validation fails in a way the rules don't cover, hand that invoice to an agent with tools to investigate and resolve. → The common path is deterministic and cheap. The exception path gets the flexible, expensive treatment it actually needs.
This shape is almost always better than either extreme, and it's what teams tend to arrive at after building the all-agent version first.
✅ Signals you need a real agent
- The number of steps genuinely varies with the input and can't be bounded in advance.
- Which tool comes next depends on what the last one returned, in ways you can't enumerate.
- The task involves investigation — searching for something whose location is unknown.
- Recovery from failure requires judgment, not a retry policy.
❌ Signals you're over-building
- Your "agent" calls the same tools in the same order every time.
- You've written prompt instructions describing the exact sequence to follow.
- Your eval assertions are all about the sequence being correct — you're testing that a dynamic system behaves statically.
- You're debugging by adding more instructions about what to do first.
That third one is worth dwelling on: if the correct trajectory is fixed and you're testing for it, you have encoded a workflow in a system designed not to have one, and paying model calls for the privilege.
The takeaway
Agents buy dynamic control flow, and you pay for it in predictability, cost, and debuggability whether or not you use it. Draw the flowchart first. If you can draw it, build it — and put a model call wherever a step needs language understanding. Save the agent for the part of the problem where nobody can say in advance what happens next.