AI agents vs chatbots: what's the real difference?
The word 'agent' is doing a lot of marketing work. Here is the actual distinction, what changes technically when a system takes actions, and what it costs you.
Every vendor now sells "agents". Most are selling chatbots. The distinction is not marketing — it changes the architecture, the risk profile, and the price.
The actual difference
A chatbot takes a message and returns a message. It may search your documents to answer well, but the output is always text. Nothing in your business changes.
An agent takes a goal and executes steps against real systems to achieve it. It decides which tool to use, calls it, reads the result, and decides what to do next. Something in your business changes.
The line is simple: does it write, or does it do?
What changes technically
Once a system takes actions, four new problems appear that a chatbot never has:
1. Permissions. Every tool the agent can call is a capability someone could trigger through conversation. Scope tools to the authenticated user, not the agent.
2. Idempotency. Agents retry. If "issue refund" runs twice, you have a problem. Every action needs to be safe to repeat, usually via idempotency keys.
3. Auditability. When an agent books the wrong slot, you need the full trace: what it was asked, what it retrieved, which tool it called with which arguments, what came back. Log all of it.
4. Stopping. Agents loop, so they need the same ceilings and circuit breakers as any automation. Without step limits, cost ceilings, and a definition of done, an agent can happily spend money in a circle.
None of this is exotic engineering, but it is real engineering, and it is why agent projects cost several times what a chatbot costs.
Where agents genuinely earn their cost
The pattern that works: a bounded task with clear success criteria, repeated often, currently done by a human copying between systems.
- Triage an inbound ticket, look up the account, apply the right tag, draft a reply for approval.
- Read an invoice, extract the fields, match it to a purchase order, flag mismatches.
- Take a booking request, check availability across calendars, propose slots, confirm.
- Monitor a data source, detect a defined condition, open a ticket with the context attached.
Notice these are narrow. The successful agent deployments we have built are narrow ones.
Where they do not
- Open-ended goals. "Grow our revenue" is not a task.
- Irreversible high-stakes actions without human approval. Money, legal commitments, and anything a customer sees should pass a person until you have earned confidence.
- Tasks that happen twice a month. The engineering cost never pays back.
- Processes nobody has documented. An agent cannot automate a process that only exists in someone's head — you have to write it down first, and often that turns out to be the whole value.
The pragmatic middle
Most of our clients get the best return from something in between: an assistant that does the reading, gathering, and drafting, then hands a human a ready-made decision.
The human stays in the loop, so the risk stays bounded — and you capture most of the time saving, because gathering context was always the slow part.
What to ask before you commit
- Is the task defined tightly enough to describe in a paragraph?
- What is the cost of it doing this wrong, and who notices?
- How often does it happen? (Below weekly, be sceptical.)
- Can every action be undone or approved first?
- Does the process exist in writing today?
If four of five are comfortable answers, an agent is worth scoping. If not, a well-built assistant will deliver more value for far less.
If the task is really a scheduled data movement rather than a judgement call, a plain automation will be cheaper and more reliable.
Tell us the task and we will tell you honestly which of the two it needs — including when the answer is a plain script with no AI in it at all.
