Why does this distinction keep getting blurred?
“AI agent” became the fashionable word for almost anything with a language model behind it, and vendors have every incentive to use the term that sounds most advanced rather than the one that’s accurate. A single-turn FAQ tool gets called an agent. A fixed intake-and-routing script gets called an agent. The word sells; the underlying architecture is whatever it was going to be anyway.
The confusion has a real cost, and it isn’t just semantic. Each of the three is a different engineering problem with a different guardrail design, a different failure mode, and a different price. Buy the wrong one and you either overpay for flexibility you don’t need, or you underbuild something that quietly can’t do the job you actually have.
What actually separates an agent, an automation and a chatbot?
The clearest way to separate them is by how much the system decides for itself at run time, not by how capable the underlying model is. The same model can sit under all three.
- Chatbot: single-turn, grounded, one job. Answers a question, grounded in your own documentation, one turn at a time, and escalates to a human when it’s uncertain rather than guessing. It doesn’t plan ahead or take a sequence of actions. Its job ends the moment it gives a good answer. See how a chatbot build works.
- Workflow automation: one fixed path, run at volume. Runs a path you’ve already mapped, reliably, at volume (intake, triage, data entry) with a human checkpoint wherever that fixed path hits a judgement step. It doesn’t decide the sequence. The sequence is decided in advance, and the system executes it the same way every time. See how an automation build works.
- Agent: a goal, a toolset, its own sequence of steps. Given a goal and a defined set of tools, it plans its own sequence of steps toward that goal and decides at each point what to look up or call next, based on what it finds. The sequence can genuinely vary run to run. That’s the entire point of building one, and exactly why its guardrails have to be tighter, not looser, than either of the other two. See how an agent build works.
Where do these lines actually blur in practice?
Honestly, more often than the tidy definitions above suggest. A few real seams are worth naming rather than papering over.
A chatbot that retrieves is not automatically an agent
A support chatbot that pulls from a knowledge base to ground its answer in the right documents is still single-turn and still ends at a good answer. Retrieval is what makes the answer accurate, not what makes the system an agent. The test isn’t whether it looks things up. It’s whether it then plans and executes a multi-step sequence of its own choosing toward a goal beyond answering.
An automation with a lot of branches can start to look agent-shaped
A workflow with fifteen conditional branches feels more flexible than a five-step script, but it’s still a fixed path someone mapped in advance. Every branch was anticipated at design time, not decided at run time. The genuine dividing line is whether a human had to have foreseen the exact route for the system to be able to take it. An agent takes routes nobody wrote down.
An agent restricted to one tool can look like automation
An agent scoped down to a single tool and a narrow goal will often behave almost identically to a fixed automation on any given run, because there’s only one sensible path available to it. Even when a single run can’t tell you which one you’re looking at, the distinction still matters at the architecture level: what happens the day the task legitimately needs a second tool or an unplanned step.
So which one does your project actually need?
Work through these in order: most requests resolve at the first or second question, and the honest answer is frequently the cheaper, simpler build.
- 1. Does it need to take more than one kind of action?. If the whole job is answering a question well, from documents you already have, you need a chatbot. Stop here. Building anything more is added cost with no added benefit.
- 2. Can you write down the exact path in advance?. If every branch of the process can be mapped now, on a whiteboard, including the exceptions, that’s a workflow automation. It will run more predictably and cost less to evaluate than an agent doing the same job, because there’s nothing left for it to decide.
- 3. Does the right next step genuinely depend on what the system finds partway through?. If the path can’t be fully mapped because step three depends on what step two turns up, that’s agent-shaped. This is the minority case, and it’s the one that justifies the extra guardrail work an agent needs.
- 4. What happens if a step is wrong?. Whichever of the three you land on, this question decides where the human checkpoint sits: before a send, a spend, or a write to a live system, regardless of how the steps leading up to it were decided.
One honest note on that last question: it applies to all three, not just agents. A chatbot that’s allowed to issue refunds unsupervised is exactly as risky as an ungoverned agent doing the same thing: the checkpoint discipline is about the consequence of the action, not the sophistication of the system taking it. Why the checkpoint sits where it does is its own piece.
What does this mean for the brief you actually send a vendor?
Describe the task, not the technology. “We want an agent” tells a vendor what word you’d like to see in the proposal. “The right next step depends on what a live inventory check turns up” tells them what to build. A team worth hiring will tell you honestly when the request is chatbot-shaped or automation-shaped even after you’ve asked for an agent, and should be able to point at exactly where in a fixed path or a single-turn answer your actual problem lives.
It’s also fair to ask a prospective vendor to walk through the framework above against your specific task before any proposal lands. A vendor who reflexively agrees “yes, that’s an agent” to whatever you ask for is optimising for the sale, not for what the task needs; the same goes for an AI answer that told you what to buy. Start at the AI hub if you’re not sure yet which of the three fits: the discovery conversation is built to figure that out before anything is priced.
