Ask a chatbot how much vacation you have left and a good one will tell you. Ask it to book the time off, check whether your team is already short-staffed that week, and get it approved, and you will find the boundary very quickly.
That boundary is the whole distinction. A chatbot is a conversational interface over information. An AI agent is a system that pursues a goal by taking actions in other systems. The two are frequently sold under the same label, deployed for the same use cases, and budgeted as if they were interchangeable — which is why so many organizations end up with something that demos beautifully and resolves nothing.
The confusion is understandable because the surface can look identical. Both may present a chat window. Both may be powered by the same underlying language model. The difference is architectural and sits entirely behind the interface: whether the system can only produce text, or whether it can also decide what to do next and then do it.
The Comparison in Brief
| Dimension | Chatbot | AI agent |
|---|---|---|
| Primary function | Answers questions, routes requests | Completes tasks across systems |
| Control flow | Fixed at design time (rules, intents, or retrieval) | Determined at run time by a planning loop |
| System access | Usually read-only, often just a knowledge base | Read and write via scoped tools and APIs |
| Handles the unexpected | Falls back to a human or a default reply | Attempts an alternative approach, then escalates |
| Memory | Conversation context only | Working, retrieved, and persistent memory |
| Typical failure | Wrong answer | Wrong action |
| Build effort | Days to weeks | Weeks to months |
| Governance burden | Content accuracy | Permissions, audit logging, autonomy limits |
The bottom three rows deserve more attention than they usually get. A chatbot that gets something wrong produces an incorrect sentence, and the user notices. An agent that gets something wrong may have already changed a record, sent an email, or issued a payment. The engineering difference is roughly one order of magnitude; the governance difference is larger.
The Five Real Differences
Control flow
This is the definitional split. A chatbot's paths are enumerated in advance — whether by intent classification, a decision tree, or retrieval over a document set, a human decided what can happen. An agent receives a goal and constructs its own sequence, observing results and revising. That flexibility is why agents cope with the situations nobody scripted, and why they need action budgets and stop conditions that chatbots do not.
Tools and write access
Modern chatbots often read live data — a balance, an order status — which blurs the line and fuels the marketing confusion. The hard boundary is writing. Once a system can create a record, submit a request, move money, or send a message on someone's behalf, it needs a different security posture: scoped credentials per tool, input validation, idempotency so retries do not duplicate actions, and a full audit trail of every call. Retrofitting this onto a chatbot platform is usually harder than building an agent properly from the start.
Persistence across the interaction
A chatbot session is stateless in any meaningful sense — it remembers the conversation and forgets everything at the end. Agents maintain state across a task that may span minutes or days, waiting on an approval, a callback, or a batch job before continuing. This requires orchestration infrastructure, not conversational infrastructure.
Error behavior
When a chatbot cannot proceed it says so, which is a safe failure. When an agent cannot proceed it may try something else, and that is where the risk concentrates. The correct design pattern is an explicit escalation path: defined conditions under which the agent stops and hands to a human with everything it has gathered, rather than improvising. Agents without a designed stop condition are the ones that generate incidents.
Measurement
Chatbots are measured on containment and deflection — what fraction of conversations ended without a human. Agents should be measured on completed outcomes and error rate, which is a harder and more honest bar. A chatbot with 70% containment may simply mean 70% of users gave up. An agent with a 70% completion rate means 70% of the actual work got done.
When a Chatbot Is the Right Answer
Chatbots are not a legacy technology, and treating them as one wastes money. They remain the correct choice in several situations.
When the need is genuinely informational — policy questions, product documentation, opening hours, benefits explanations — retrieval-based conversational search is cheaper, faster, easier to evaluate, and carries almost no operational risk. When the volume is high but the variety is low, a well-tuned chatbot with a handful of paths outperforms an agent on both cost and reliability. And when regulatory exposure means the system must never take independent action, a read-only conversational layer is the appropriate architecture, not a compromise.
A useful heuristic: if the desired outcome is a user knowing something, build a chatbot. If the desired outcome is something having changed, you need an agent.
When You Actually Need an Agent
Agents earn their cost in three conditions, and preferably all three at once.
The work spans multiple systems. If answering a request requires checking three applications and correlating what they say, no amount of retrieval quality will produce the answer — something has to go and look.
The path varies by case. Where each instance needs a slightly different investigation, enumerating branches becomes impossible. This is where run-time planning stops being a novelty and starts being the only viable approach.
The end state is an action. Submitting, approving, updating, scheduling, correcting. If the interaction is not finished until something has changed in a system of record, a chatbot can only ever hand off.
Employee-facing HR service is a clear example of all three. A question about a paycheck discrepancy requires payroll, time tracking, and policy data; the investigation differs every time; and the resolution is a correction, not an explanation. That combination is exactly why the current generation of AI assistants for HR automation is built on agent architecture rather than on the intent-matching chatbots that preceded them.
The Hybrid Pattern Most Organizations Should Build
In practice the strongest deployments are not one or the other. They are a single entry point that classifies the request and routes it appropriately: informational queries go to fast, cheap retrieval; transactional requests go to an agent with the tool access to complete them.
This matters economically. Informational traffic typically dominates volume, and running every one of those interactions through a multi-step planning loop is slow and expensive for no benefit. Routing them to retrieval keeps latency low and cost predictable, while reserving agent capacity for the work that justifies it.
It also matters for adoption. Users do not care which architecture answered them; they care whether the thing worked. A hybrid front door means the common questions feel instant and the complex requests actually get resolved — a combination that a pure chatbot cannot deliver and a pure agent delivers slowly. Layering this over an existing employee self-service portal is a natural fit, because the portal already defines what employees are permitted to do and provides the transactional surface the agent needs.
Questions That Cut Through Vendor Positioning
If a demo leaves you unsure which you are being sold, four questions settle it. Can it write to our systems, and what permissions does it need to do that? What happens when the information it needs is missing — does it stop, or does it try something else? Does it maintain state across a task that pauses for approval? And can you show the audit log of every action taken in a single run?
Vendors selling a chatbot will answer the first question with a qualified no and the fourth with a conversation transcript. That is not a disqualification. It is simply clarity about what you are buying, which is worth having before the implementation rather than after.
If your requirement genuinely involves completing work rather than answering questions, the Workisy team builds AI agents with scoped tool access and audited action logs, and our employee self-service platform provides the transactional foundation those agents operate against.
