AI Agents vs Chatbots — And Which One You Actually Need
Agent is the most overused word in software right now. Here's the practical difference between a chatbot, an assistant and a true agent, what each one costs to run, and how to choose without buying complexity you don't need.
Every vendor is selling agents now. Most of them are selling chatbots with a new label, and a few are selling something genuinely more capable — and considerably harder to operate safely.
The distinction matters because the three categories have very different costs, risks and failure modes. Picking the wrong one is how businesses end up with an expensive system that nobody trusts.
The three things people mean by "AI"
A chatbot answers questions. It receives a message and returns text. It might be grounded in your documentation so its answers are accurate, but it doesn't do anything — it has no ability to change the state of your business. Its worst failure is a wrong answer.
An assistant answers questions and drafts actions. It can look things up in your systems and prepare work — a reply, a quote, a summary, a data entry — but a person approves before anything happens. Its worst failure is a bad draft that someone catches.
An agent pursues a goal across multiple steps, taking real actions. Give it an objective and it decides what to do, calls the tools it needs, checks its own progress, and keeps going until it's done or stuck. Its worst failure is doing several wrong things quickly, in your production systems.
That last sentence is the whole design problem. An agent's power and its risk come from exactly the same property: it acts without asking each time.
A concrete comparison
Take one task — a customer emails asking to reschedule a booking.
| What it does | What can go wrong | |
|---|---|---|
| Chatbot | Tells the customer how to reschedule | Gives outdated instructions |
| Assistant | Finds the booking, drafts the change and a reply, waits for staff approval | Drafts the wrong booking; staff catch it |
| Agent | Finds the booking, checks availability, moves it, notifies the customer, updates the calendar | Moves the wrong booking and tells the customer it's done |
All three are legitimate products. The right one depends entirely on how much it costs you when the system is wrong, and how often you're willing to have a human in the loop.
Most businesses need an assistant
This is the unglamorous conclusion, and it's right far more often than the market implies.
Assistants hit a sweet spot: they remove the blank-page problem and the lookup work — which is where most of the time actually goes — while keeping a human on the decision. Staff stay in control, trust builds quickly because people can see the reasoning, and your worst-case outcome is a discarded draft rather than a customer incident.
They're also dramatically cheaper to build and run. There's no need for the elaborate guardrails, rollback paths and monitoring that a genuinely autonomous system demands.
Start here. Move to full autonomy for a specific task once you've watched the assistant get that task right hundreds of times in a row.
When an agent genuinely is the right answer
Agents earn their complexity when:
- The task is high volume and low value per instance. Human approval on every one would cost more than the occasional mistake.
- The steps vary each time, so a fixed automation script can't express the work.
- Actions are reversible — you can undo a draft, a ticket, or an internal record far more easily than a payment or a customer email.
- The environment is bounded. The agent works inside a system you control, with a limited set of tools, not across your entire business.
Internal data processing, triage and enrichment, test generation, research and report assembly — these are good agent territory. Anything touching money, contracts, or direct customer communication deserves a human gate for a long time.
What it actually takes to run an agent well
If you do go down this path, the model is the easy part. The engineering around it is the project:
- Tool design. An agent is only as good as the actions available to it. Each tool needs a narrow, well-described purpose and validation on its inputs — a vague tool invites creative misuse.
- Permissions. The agent should have the minimum access required. Read-only wherever possible. Separate credentials so you can see and revoke what it did.
- Stopping conditions. Step limits, cost limits, and a clear definition of done. Without these, a confused agent will happily loop.
- Human gates on irreversible actions. Sending, paying, deleting, publishing. These should require approval even in an otherwise autonomous flow.
- Full audit logging. Every action, with inputs and outputs, retained. When something goes wrong you need to reconstruct exactly what happened.
- Monitoring and alerting. Success rates, escalation rates, cost per run. Agents degrade quietly when an upstream system changes.
None of this is exotic engineering, but it's real work, and it's the difference between a demo and something you'd let near a customer.
Ground it in your data, whichever you choose
The single biggest determinant of whether any of these feels useful or embarrassing isn't the model — it's whether it has access to accurate, current information about your business.
A model answering from general knowledge will confidently invent your refund policy. A model retrieving your actual policy document and answering from it, with a citation, will not. That retrieval layer is usually the majority of the value and a good chunk of the build effort, and it's the same work whether you end up with a chatbot, an assistant or an agent.
Build the knowledge layer first. It's the part that makes everything above it credible, and it's useful even if you never go beyond a simple assistant.
How to choose, quickly
Work down this list and stop at the first yes:
- Do people just need answers from information you already have? Build a grounded chatbot. Cheapest, fastest, lowest risk.
- Do people spend most of their time looking things up and drafting? Build an assistant. Best value for most businesses.
- Is the volume so high that approving each item is the bottleneck, and are the actions reversible? Consider an agent — for that one task, inside clear limits.
- Is the process actually the same every time? You don't need AI at all. Traditional process automation will be cheaper, faster and more reliable.
That last point catches more projects than you'd expect. A surprising number of "we need an AI agent" conversations end with a well-designed integration and a few rules.
Costs to expect
- Grounded chatbot: $15k–$35k to build, low running costs.
- Assistant integrated with your systems: $30k–$80k, depending on how many systems it touches.
- Production agent with proper guardrails: $80k+, and a meaningful ongoing operations commitment.
The step up in price between an assistant and an agent isn't the intelligence — it's the safety engineering, the monitoring and the testing. That's precisely why you shouldn't buy an agent until you've proven you need one.
Not sure which of these your problem calls for? Talk to us — we'll map the task, tell you the simplest thing that would work, and say so plainly if the answer is "no AI required". If you're weighing up where to apply this first, our guide to practical AI use cases is a useful companion.