AI agents and chatbots: what is actually different
The short answer
A chatbot answers questions from text it has been given. An agent takes actions in your systems: updating a record, processing a refund, creating an order. The difference is not conversational quality, it is permissions and integration. Agents cost more to build because the work sits in the connections and the guardrails, not the conversation. Gartner's forecast that agentic AI will autonomously resolve 80% of common service issues by 2029 describes agents, not chatbots.
The distinction in one example
A customer asks where their order is.
A chatbot searches your help articles and replies with the tracking policy. Accurate, and completely unhelpful, because the customer did not want the policy, they wanted their order.
An agent looks up the order in your system, checks courier status, tells the customer it is out for delivery today, and offers to change the delivery address. Then it actually changes it.
The second requires read access to your order database, an integration with the courier API, write access to change an address, and a rule about what it may change without approval. That is the whole difference. The conversation is the easy part, and it has been the easy part for a while now.
Why agents cost more to build
The conversational layer is largely commodity. The expensive work sits in four places that never appear in a demo.
Integration
Every system the agent touches needs an API, authentication, and error handling for when it is unavailable. An agent that works only when every dependency is healthy is a demo, not a system.
Permissions
What can it do alone and what needs approval? A refund under Rs 500 might be automatic; above that, a human. Those rules are business decisions, not technical ones, and getting them from the business is often the slowest part.
Failure handling
When the courier API times out, does the agent apologise, retry, or escalate? Undefined failure behaviour is where agents embarrass you publicly, because they will confidently invent an answer rather than admit the lookup failed.
Audit logging
Every action needs a record of what it did, on whose behalf, and on what basis. This matters for disputes, and under India's data protection framework it matters for demonstrating accountability.
Permissions: the part people underestimate
- Least privilege. Read-only access where reading is enough, and write access scoped to specific fields rather than whole records.
- Value thresholds. Anything above a defined financial or risk threshold gets human approval, and the threshold is set by the business rather than the developer.
- Reversibility. Prefer actions that can be undone. An agent that can cancel an order should not be able to permanently delete a customer record.
- Rate limits. An agent in a retry loop can perform a thousand actions before anyone notices. Cap it.
- A kill switch. One setting that stops all autonomous action while leaving the answering capability running.
Build these into the first version rather than after an incident. Retrofitting a permissions model onto a working agent means revisiting every action it can take.
What to build first
Start with a chatbot on structured questions. It is cheaper, it proves whether your knowledge base is good enough to support anything more ambitious, and it tells you what people actually ask rather than what you assume they ask.
Move to an agent when the logs show a specific repeated request that requires an action, and that action is well defined with a clear rule about when a human is needed. Both halves of that sentence matter. A repeated request with no clear rule produces an agent that escalates everything, which is a chatbot with extra steps.
Building an agent before you know what people ask is the most common way to automate the wrong thing thoroughly and expensively.
Where agents genuinely pay off
The common shape is repeated, multi-step, rule-bound work that a person currently does by copying between systems.
Order operations
Status lookups, address changes, delivery rescheduling. High volume, well-defined rules, and the customer benefit is immediate.
Document processing
Invoice data extraction into accounting, classification and routing of incoming documents. Repetitive, error-prone by hand, and easy to measure.
Lead qualification
Enriching, scoring and routing inbound enquiries. The rules already exist in someone's head; the agent makes them explicit and consistent.
Why integration got cheaper
One thing has genuinely changed in the last two years. The Model Context Protocol has become the common way to connect tools to AI systems, with its npm SDK passing 195 million monthly downloads by mid-2026, ahead of both the OpenAI and Anthropic SDKs individually.
That standardisation matters commercially rather than technically. Before it, every integration was bespoke, which meant the cost of connecting an agent to your systems scaled with the number of systems. A common protocol means tool integrations are increasingly reusable, and the build estimate for an agent has come down accordingly.
It has not made the permissions and failure-handling work disappear. Those remain the expensive part, and they are the part worth spending on.
From our own builds
On a client CRM we automated the scraping of 200,000 documents a month and the merging of 4.4 million legal notices, work that was previously manual. Those are agents in the practical sense: they act on systems rather than answering questions about them.
The design decision that took longest was not the automation itself. It was defining what the system was permitted to do without a human in the loop, and making every action reversible and logged. That conversation is with the business, not with the engineering team, and it is worth having before writing code rather than after.
Frequently asked questions
Considering an agent for your operations?
We design the permissions model and failure handling before the automation, because that is what separates a system you can trust from a demo.