
Chatbot, Assistant or Agent: What You Are Actually Buying
Neo Hives IT Solutions· 10 September 2026·10 min read
The word "agent" currently describes at least five different products, priced across two orders of magnitude. That vagueness is expensive in both directions: businesses pay agent money for something a decision tree would do, and they buy an agent to solve a problem that needed a form and a database query. Nobody is necessarily being dishonest. The vocabulary has simply outrun the definitions.
This is a short guide to telling them apart — what each one actually does, what it cannot do, what breaks, and the two questions that place any product on the map in about a minute.
The five things people call AI
1. The rule-based chatbot. A decision tree with buttons. "Track my order / Book a visit / Speak to someone." No model involved, entirely predictable, cheap, and still the correct answer for a surprising number of websites. It fails the moment somebody types a question the tree does not contain, which is why it earned its poor reputation — not because it is useless, but because it was deployed where it could not cope.
2. The general-knowledge chatbot. A language model attached to a chat window with no grounding in your business. It answers fluently about anything, including your refund policy, which it does not know and will therefore invent. This is the one configuration to avoid in a customer-facing role. It looks the most impressive in a demonstration and carries the most risk in production, because being wrong and being confident are not correlated with each other.
3. The knowledge assistant. A model that answers questions using your documents, with a citation, and says it does not know when the answer is absent. Read-only: it tells, it does not do. This is the highest-value low-risk deployment for most businesses, and the mechanics — permissions, staleness, citations — are covered in answers from your own documents.
4. Workflow automation with a model step. An ordinary, deterministic process — the kind that has existed for decades — with one or two judgement steps handed to a model: classify this email, extract these eight fields, summarise this call, draft this reply. You define the sequence; the model only makes the judgement it was asked for. This is where most successful projects live, and it is the least discussed category because it is the least exciting to sell.
5. The agent. The model decides the sequence itself. Given a goal, it chooses which tools to call, in what order, when to stop, and it takes actions with real consequences — updating the CRM, issuing the credit note, replying to the customer. Genuinely more capable, and by a wide margin the most work to make safe, because the number of paths it can take is no longer something you enumerated in advance.
A sixth term worth knowing: copilot, meaning any of the above embedded in the tool a person is already using, where a human stays in the driving seat. It is a delivery style rather than a capability, and it is often the right one — adoption is much easier when nobody has to open a new system.
The comparison, on one screen
| Rule-based chatbot | Knowledge assistant | Model-in-the-loop workflow | Agent | |
|---|---|---|---|---|
| Who decides the steps | You, in advance | Not applicable — it answers | You, in advance | The model, at run time |
| Can it change anything | No | No | Yes, along a fixed path | Yes, along a path it chose |
| Where facts come from | What you typed | Your documents | Your systems | Your systems and its own judgement |
| Typical failure | Cannot handle the question | Retrieves the wrong passage | One field extracted wrongly | Plausible sequence of wrong steps |
| How hard to make safe | Trivial | Permissions work | Bounded and testable | The bulk of the project |
| Build effort | Days | Weeks | Weeks | Months, done properly |
| Right when | Few, fixed intents | Answers exist in documents | High volume, written-down process | The sequence genuinely varies per case |
Two questions that classify anything
Who decides the order of the steps? This is the real dividing line, and it does not appear in any brochure. If you wrote the sequence, you have automation — testable, predictable, cheap to reason about. If the model picks the sequence, you have an agent, and you have inherited a much harder verification problem, because next Tuesday it may choose a path nobody has ever seen.
What is it allowed to change? Risk lives here, not in cleverness. A system that can only read is bounded by embarrassment. A system that can write to your CRM, send email, move money or delete records is bounded by its permissions and your approval rules — and those are engineering decisions you make, not properties of the model you bought. The most reassuring answer a vendor can give is a short, specific list of the writes their system is allowed to perform.
Why everything is called an agent, and how to check
"Agent" prices better than "workflow". That is most of the explanation. The useful response is not scepticism about the label but a few questions that only have good answers if the thing is real:
- "Show me the log of one multi-step run." A real agent produces a trace: what it decided, which tools it called, what came back, why it stopped. If there is no trace, there is no agent — and more importantly, no way to debug it later.
- "What happens when step three fails?" Retry, abandon, escalate, or silently carry on with bad data? This single question separates people who have run these systems from people who have demonstrated them.
- "What can it write to, and what needs approval?" Should be a specific list, not a philosophy.
- "How do you know it works?" The answer should mention a fixed set of test cases and a number, not a demonstration. Ours is described in how to test an AI system before customers do.
- "What does it cost per completed task at our volume?" If the only available answer is a price per million tokens, this has not been run in production.
- "What happens when the underlying model is retired?" It will be. The right answer involves a pinned version and a test suite, not surprise at the question.
Which one you probably need
- People keep asking questions that are answered in your documents — knowledge assistant. Weeks, low risk, and the most commonly underestimated option.
- A written-down process happens hundreds of times a month — workflow automation with a model step. This is where the money usually is, and the argument for it is laid out in AI business process automation.
- Your website gets the same six questions — a rule-based chatbot, or better, a clearer web page. Genuinely.
- Calls go unanswered outside office hours — a voice agent with a narrow scope and a good handover.
- Each case takes a different route through several systems and needs judgement at each turn — an agent, with a person approving anything irreversible. Worth doing, and worth being honest that it is the expensive option; what it takes to build one properly is in our note on choosing an AI agent development company in India.
- You are not sure which of these describes your problem — that is a process question rather than a technology one, and it is what IT consultation is for.
What agents genuinely add
None of the above is an argument that agents are hype. They solve a specific problem: cases where the sequence of steps cannot be enumerated in advance because it depends on what earlier steps discovered. A refund enquiry that turns out to be a delivery problem that turns out to be a supplier error follows a path no flowchart contains. Handling that class of work without a person is what agents are for, and when the alternative is a queue of humans doing careful multi-system detective work, they are worth the effort.
What makes them work is boring plumbing rather than model choice: narrowly scoped tools, so a wrong decision has a small blast radius; approval gates on anything irreversible; idempotent writes, so a retry cannot double-post; and a full trace of every decision. Tool access is increasingly standardised — the Model Context Protocol is the emerging common interface for connecting models to systems — but a standard connector does not decide what the agent is permitted to do. That remains your call, and it is the decision that determines whether the project is safe.
The ladder, and why to climb it in order
Each rung is cheaper and safer than the one above, and each one teaches you something the next needs. Skipping to the top is the single most reliable predictor of a failed project.
| Step | What you learn | What it costs to be wrong |
|---|---|---|
| 1. Answer questions from your documents | Whether your documents are usable at all | An unhelpful answer |
| 2. Add a judgement step to one existing process | Whether your systems are reachable and your data clean | One field wrong, caught by a check |
| 3. Let it act, with a person approving | Your real error rate, on real cases | Nothing — approval catches it |
| 4. Let it act, and sample the results | Whether the error rate holds at volume | A recoverable mistake, noticed quickly |
| 5. Let it choose its own steps | Where judgement genuinely varies | A sequence of confident wrong actions |
How we think about this at Neo Hives IT Solutions
We try to name the category before quoting anything, because the honest recommendation is often the cheaper one. Plenty of enquiries that arrive asking for an agent are better served by a knowledge assistant and a tidier process, and some are better served by a form, a database query and no AI at all. When an agent genuinely is the answer, we build it with narrow tools, approval gates and a trace from the first day, because those are what make it maintainable rather than impressive. We are an early-stage company and we would rather be the people who told you which rung you are on. How we report results is visible in our case studies.
Common questions
Are chatbots obsolete? No — badly-placed ones are. A three-option decision tree that routes accurately beats a language model that answers fluently and wrongly. Match the tool to the number of intents you actually have.
Can an agent replace a team? It can absorb the repetitive share of a team's work, which is usually most of the volume and rarely most of the value. Exception handling does not disappear, it concentrates — and the remaining cases are harder than the average one was, which is why headcount business cases tend to overstate themselves.
What about "AI employees"? A marketing term for an agent with a name and an avatar. Judge it by the same two questions: who decides the steps, and what is it allowed to change. The avatar does not affect either.
Do we need an agent framework? Not to start. A great many production systems are a scheduled job, a few well-chosen prompts, a database and careful error handling. Frameworks help when the sequence is genuinely dynamic; before that they mostly add moving parts.
Can one system be several of these? Yes, and good ones usually are — a rule-based front door for the common intents, retrieval for questions, a bounded workflow for the routine transactions, and an agent for the messy minority. The point of the vocabulary is to be deliberate about which part is which, not to pick one for everything.
Where to start
Write down the task you want handled, then answer the two questions about it yourself: does the sequence of steps vary from case to case, and does anything need to be changed in a system as a result? Those two answers tell you which of the five you need, and they will usually point one rung lower than the pitch you were expecting.
Our free AI readiness audit is a 45-minute conversation and a short written summary naming the category your problem falls into and what it would realistically take — including when the answer is that you do not need any of this yet. Or get in touch and describe the task in a sentence.