Day 10: When to use a chatbot, workflow, or agent
A practical way to choose between conversation, repeatable workflows, and bounded autonomy.
Not every AI feature should be a chatbot. Obvious: right up until every prototype starts with a blank text box, because that is the fastest thing to build and the most impressive thing to demo.
The choice between chatbot, workflow, and agent is not a sophistication ladder. It is a decision about how much the system is allowed to do on its own.
| Pattern | Best when | Watch out for |
|---|---|---|
| Chatbot | The user needs exploration, explanation, or open-ended conversation | It becomes the vague front door for every workflow you never built |
| Workflow | The steps are known, repeatable, and auditable | It feels rigid when the task genuinely needs judgement |
| Agent | The system must choose actions under real constraints | Autonomy needs budgets, permissions, logs, and stop rules |
The two common mismatches
A chatbot bolted onto a job that needed a workflow. The user knows exactly what they want; the system makes them describe it in prose, guesses at the parameters, and produces something adjacent. A form with four fields would have been faster, more accurate, and auditable. Conversation is a wonderful interface for exploration and a poor one for a known process.
An agent given autonomy the task never required. The steps were fixed and knowable. Now they are decided at runtime, which means they vary, cost more, take longer, and cannot be traced without effort. All of the complexity, none of the benefit.
The blank text box is a decision, not a default
Once a chatbot becomes the front door, narrowing it later is genuinely hard. Users have learned they can ask anything, and every unhandled request now reads as a failure rather than as out of scope.
Starting narrow and widening is easy. Starting wide and narrowing is a product regression, and it will be experienced as one.
Choose against operating cost, not demo quality
Run the use case through each pattern and compare the things you will live with: cost per interaction, latency, how you would debug it, and who owns it when it misbehaves.
The pattern that demos best is frequently the most expensive to operate, and the gap does not appear until you are already committed.
Then write one sentence: what is this system allowed to do on its own? If that sentence is hard to write, the pattern choice has not actually been made yet.
Choose the simplest architecture that reliably solves the problem. The interface is part of the architecture, and the wrong wrapper makes a perfectly good model feel unreliable.
Day 10 of 60 Days of Production AI Systems.
Is your current use case truly a conversation, a workflow, or bounded autonomy?
Previous: Day 09: Why a capable model is still not a product
Next: Day 11: Why RAG is an evidence design problem, not a buzzword
Day 10 of 60 · From LLM Demo to AI Product (chapter 2 of 10)
