A chatbot answers, an automation follows a path someone drew in advance, and an agent decides its own next step as it goes. Which one you have sets how it is guarded, tested and priced. Below are the questions we ask before calling anything an agent, and what that scoping produces.
What actually separates the three
Separate them by how much the system decides for itself while it runs, not by how capable the model is. The same model can sit under all three.
| Chatbot | Workflow automation | AI agent | |
|---|---|---|---|
| Given | A question | A trigger | A goal and a set of tools |
| Who decides the steps | No steps: one grounded answer | The person who mapped the path | The system, at run time, from what it finds |
| Where its job ends | A good answer, or a hand-off to a person | The end of the mapped path | When the goal is met or a person must approve |
| What has to be guarded | The accuracy of answers | Every point where the mapped path needs judgement | A whole class of actions, because the route varies |
Vendors have every reason to call all three “agents”, because the word sells. Buy the wrong one and you either pay for flexibility nobody uses, or under-build something that quietly cannot do the job.
Where the lines blur
A chatbot that retrieves documents from a knowledge base is still a chatbot: retrieval makes the answer accurate, not the system agentic. An automation with fifteen branches is still an automation, because every branch was foreseen at design time. And an agent limited to one tool can behave exactly like an automation on any single run.
The test that survives all three cases is simple. Did a person have to foresee the exact route for the system to take it? If yes, it is a chatbot or an automation. If the system takes routes nobody wrote down, it is an agent, and it needs tighter guardrails, not looser ones.
- The route
- None: one grounded answer, or a hand-off to a person
- What is guarded
- The accuracy of answers
- The route
- Drawn in advance: every branch foreseen at design time
- What is guarded
- Every point where the path needs judgement
- The route
- Chosen at run time, from what it finds
- What is guarded
- A whole class of actions, with tighter guardrails
The seven questions in our agent scoping sprint
Our scoping sprint for agent work exists to answer one question first: is the task agent-shaped at all? We ask these in order, and most requests are settled by the first two.
| Question | What the answer tells us | What gets written down |
|---|---|---|
| 1. Is the whole job answering a question from documents you already have? | If yes, it is a chatbot. Stop here. | Stop: scope a grounded-answer build |
| 2. Can the full path, exceptions included, be drawn on a whiteboard today? | If yes, map it as an automation: every branch can be tested before launch | Stop: scope the mapped path as an automation |
| 3. Does step three depend on what step two turns up? | If yes, across several steps and several tools, it is agent-shaped | The task, tested against those three conditions |
| 4. Which systems would it touch, and what access does each call need? | The tool list, and the main driver of cost: one CRM lookup and six back-office systems are different projects | Tools and the permission scope for each call, agreed in writing |
| 5. Which actions are irreversible, external or above a set value? | Where a person must approve before anything executes | Approval thresholds |
| 6. What does a hard case from the real job look like? | Whether the agent can be tested on the cases where the obvious next step is wrong | Evaluation scenarios from the actual task, traps included |
| 7. Where must the data stay, and what may it cost to run? | Which model fits | A model recommendation on fit, cost and data residency |
Question five applies to all three systems. A chatbot allowed to issue refunds unsupervised carries the same risk as an ungoverned agent doing it: the checkpoint follows the consequence of the action, not the sophistication of what takes it. Our post on why governed delivery means we say no to some automation requests explains where those checkpoints sit.
What the scoping produces, and how long it takes
Our scoping and evaluation sprint takes 1 to 2 weeks. It ends with one of two documents: an itemised scope for a pilot on one real task, or a written case for a cheaper build. If the honest answer is a chatbot or a workflow automation, we recommend that build in writing, whatever was asked for.
When the task is agent-shaped, the pilot runs for 3 to 6 weeks on one real task from your operation. Every step is logged, every tool call is scoped to the least access it needs, and anything irreversible waits for a person.
Runs are supervised and scored against your own baseline, and the agent runs unattended only where it has earned it. The AI agents page sets out the pilot and the monthly run that follows it.
When to say no to an agent
- The path can be mapped. An automation will be more predictable and cheaper to test, and an agent adds nothing but things to guard.
- Nothing to point it at. “We want an agent” with no job attached cannot be scoped or tested. Start from a queue your team already works.
- Nobody can define a good result. Without a baseline from the current process, there is nothing to score the agent against.
- Nobody will own the approvals. If no one has time to approve the actions an agent proposes, its gates become a bottleneck or get switched off.
Describe the task, not the technology, in any brief you send. “The next step depends on what a live stock check turns up” tells a vendor what to build. A vendor who agrees “yes, that’s an agent” to every request is serving the sale, not the task.
Written by
Parvessh Agarwal
Founder and Chief Executive, Vinove
Parvessh founded Vinove in 2004 with one idea: build focused technology companies that earn their place in real markets. His focus is on the long game, on companies that survive and serve real customers long after launch.
LinkedIn →
