Vendors now describe almost everything as an agent. A chat window that answers questions is an agent, a tool that sends emails is an agent, and a workflow that calls three apps in a row is an agent too. For a buyer or a team lead, the labels are confusing and the decision underneath them is real: do you need something that talks, something that acts, or both?
In this guide you will learn a practical way to choose between a chatbot and an agent. You will see what each one does well, where each one fails, how to score your own use case, what controls to put around an agent that can take actions, and how to start small. It is written for non-technical readers and avoids product claims, so you can apply it to any tool you are considering.
Key takeaways
- A chatbot mainly converses and answers; an agent pursues a goal by deciding steps and using tools, such as sending a message or updating a record.
- Choose a chatbot when the job is answering questions or drafting text and a person stays in charge of every action.
- Choose an agent only when the task has clear steps, clear limits and a safe way to undo or review what it does.
- The more an agent can do on its own, the more you need permissions, approvals, logging and a human escalation route.
- Start with the least powerful option that solves the problem and add autonomy only after it has proved reliable.
Chatbot and agent in plain terms
The simplest distinction is about action. A chatbot responds to what a person says. An agent is given a goal and works toward it, deciding which steps to take and using connected tools along the way.
What a chatbot does
A chatbot takes a message and produces a reply. It may answer questions from a set of documents, explain a policy, draft a paragraph or guide someone through a form. It does not, on its own, change anything in the outside world. A person reads the reply and decides what to do.
What an agent does
An agent takes an objective such as “sort this week’s incoming enquiries and book follow-ups” and breaks it into steps. It can look things up, call other software, write to a calendar, update a spreadsheet or send a message, and it can decide what to do next based on what it finds. If you want a fuller background, see AI agents explained for non-technical readers.
Why the difference matters
When a chatbot is wrong, someone usually reads the wrong answer before anything happens. When an agent is wrong, the wrong action may already have been taken. That single difference drives most of the advice that follows.
A spectrum, not two boxes
In practice there is a ladder of capability, and many products sit between rungs. Thinking in levels helps you pick the right amount of autonomy.
| Level | Description | Who acts? |
|---|---|---|
| 1. Answering assistant | Answers questions or drafts text on request. | The person does everything. |
| 2. Guided assistant | Follows a script or flow, collects information, suggests next steps. | The person confirms every step. |
| 3. Assistant with tools, read-only | Looks up information in connected systems to answer. | The person acts on the answers. |
| 4. Assistant that proposes actions | Prepares an action such as a drafted email or a suggested booking and waits for approval. | The person approves each action. |
| 5. Agent with limited autonomy | Takes defined low-risk actions on its own, within set limits, and reports back. | The system acts; the person reviews. |
| 6. Broad autonomous agent | Pursues open-ended goals with wide access to tools. | The system acts, often with little oversight. |
Where most organisations should start
Levels one to four cover a large share of useful work with modest risk. Level five suits narrow, well-tested tasks. Level six is rarely a sensible first step for a business, because open-ended goals combined with wide access make mistakes harder to predict and contain.
Side-by-side comparison
| Feature | Chatbot | Agent |
|---|---|---|
| Main purpose | Conversation, answers, drafting | Completing tasks and goals |
| Takes actions in other systems | Usually not | Yes |
| Decides its own steps | No, follows the conversation | Yes, within limits |
| Typical failure | A wrong or invented answer | A wrong action, or a chain of actions built on one wrong step |
| Oversight needed | Review of answers | Permissions, approvals, logs and monitoring |
| Setup effort | Lower | Higher, with integrations and testing |
| Ease of testing | Easier; outputs are text | Harder; many paths and side effects |
| Best for | Support questions, internal help, drafting | Repeatable multi-step processes with clear rules |
Hybrid products
Many products start as a chatbot and add actions over time. When you evaluate one, look past the label and ask exactly what it can do in other systems, and who must approve each action.
Seven questions to ask first
Before comparing products, answer these questions about the job itself. They usually make the choice obvious.
- What is the outcome? Is it a good answer, or something done, such as a booking made, a record updated, a message sent?
- Are the steps predictable? If you can write the steps down as a checklist, the task suits automation. If the path changes a lot, autonomy is riskier.
- What is the cost of a mistake? A slightly wrong draft costs a minute. A wrongly issued refund or a message sent to the wrong customer costs more.
- Can the action be undone? Reversible actions are safer to automate than irreversible ones.
- Who is affected? Internal tasks are lower risk than anything that touches customers, money or personal data.
- How often does it happen? A rare task may not justify the build; a frequent one might.
- Who will watch it? If nobody can review the results, do not give it power to act.
Reading the answers
If the outcome is an answer, choose a chatbot. If the outcome is an action but the cost of a mistake is high, choose an assistant that proposes actions and waits for a person. Only when the steps are predictable, mistakes are cheap and reversible, and someone will review the results should you consider an agent acting on its own.
Scoring your use case
A simple scoring exercise helps teams agree. Rate your use case on each factor from one to three, add up the scores and use the result as a conversation starter, not a verdict.
| Factor | 1 point | 2 points | 3 points |
|---|---|---|---|
| Task predictability | Varies a lot | Some variation | Same steps every time |
| Cost of a mistake | High | Moderate | Low |
| Reversibility | Cannot undo | Hard to undo | Easy to undo |
| Data sensitivity | Personal or confidential | Some sensitive data | Non-sensitive |
| Availability of review | No reviewer | Occasional review | Every result reviewed |
| Clarity of rules | Vague | Mostly clear | Written and testable |
How to read the total
- 6 to 9: Keep to a chatbot or an assistant that only suggests. Autonomy is not safe yet.
- 10 to 14: An assistant that proposes actions for approval is a good fit. Consider limited autonomy for the safest sub-tasks.
- 15 to 18: A limited-autonomy agent may be reasonable, with logging, limits and regular review.
Be honest about the scores
Teams tend to rate rules as clearer and mistakes as cheaper than they really are. Ask someone who does the work every day to check your scoring, and look at real past errors for evidence.
Example scenarios
These invented scenarios show how the decision plays out.
Scenario 1: website questions about opening hours and returns
The outcome is an answer, the content is stable, and there is no action to take. A chatbot working from approved policy text is the right fit. Plan it carefully using how to plan an AI customer support chatbot.
Scenario 2: triaging a shared inbox
The task is to read incoming messages, label them and draft replies. Labelling and drafting are low risk, while sending replies may not be. An assistant that proposes labels and drafts, with a person approving sends, gives most of the benefit with little risk. After some months of clean results, auto-labelling alone could become autonomous.
Scenario 3: weekly reporting
Every Friday, someone copies figures from three systems into a template and writes a short commentary. The steps are predictable and the output is reviewed before it is shared. A limited agent that collects the figures and prepares the draft is a fair candidate, as long as a person checks it before it goes out.
Scenario 4: issuing refunds
Money moves, mistakes are costly and some actions cannot be easily reversed. Keep a person in the approval seat. An assistant can gather facts and recommend a decision, but a person confirms.
Scenario 5: open-ended research with purchasing
“Find the best supplier and order what we need” combines an open goal, wide search and spending. This is a poor first candidate for autonomy. Split it: let an assistant research and compare, and keep the buying decision with a person.
Risks that grow with autonomy
As systems gain the ability to act, the kinds of failure change. Knowing them helps you design around them.
| Risk | What it looks like | Why it grows with autonomy |
|---|---|---|
| Compounding errors | One wrong early step leads every later step astray. | The agent builds on its own output without a human check. |
| Unintended actions | It does something you did not mean to allow. | Broad permissions give it more ways to act. |
| Misread instructions | It pursues the wrong goal because the request was ambiguous. | Open goals leave more room for interpretation. |
| Data exposure | It reads or sends information it should not. | Access to several systems widens the reach. |
| Manipulation | Text in an email or web page tricks it into acting. | Content it reads can contain instructions it may follow. |
| Loops and runaway use | It repeats actions or consumes resources. | It decides when to continue. |
| Weak accountability | Nobody knows what it did or why. | Actions happen out of sight without logs. |
The hallucination problem, multiplied
Language models can state false things confidently. In a chatbot that produces a wrong answer. In an agent it can produce a wrong action. See what AI hallucinations are and how to reduce them for background.
Instructions hidden in content
If an agent reads emails, web pages or documents, those can contain text that tries to steer it. Treat anything the agent reads from outside as untrusted, and limit what it is allowed to do on the strength of that content alone.
Controls for agents
If you do decide to use an agent, build safety around it from the start. These controls work for most use cases.
The core controls
- Least privilege. Give access only to the systems and actions the task needs, and no more.
- Read before write. Start with read-only access. Add write access to one system at a time.
- Approval gates. Require a person to approve actions that spend money, contact customers, delete data or cannot be undone.
- Limits. Cap the number of actions, the value of any transaction and the time the agent may run.
- Logging. Record every action, the input behind it and the outcome, in a place people can review.
- Kill switch. Make it easy to pause or stop the agent immediately.
- Escalation. Define when the agent must hand over to a person, such as low confidence, an unusual case or an upset customer.
- Testing. Run it on realistic and awkward cases in a safe environment before live use.
Do not rely on instructions alone
A written instruction such as “never delete records” is guidance, not a lock. Enforce important limits with real permissions in the connected systems. For how instructions behave, see how to write better prompts.
Protect the data it touches
Give the agent access only to data it needs, and understand where that data goes. The principles in how to protect company data when using AI tools apply with extra force when software can act on the data.
Put it in your policy
Write down which tasks an agent may perform, who approves new ones and who reviews the logs. A team policy, as described in how to write an AI use policy for your team, is the natural home for these rules.
Cost and effort
Agents are not only riskier but usually more work. Be realistic about the total effort.
Hidden costs of agents
- Integration. Connecting systems and managing permissions takes time.
- Testing. Many possible paths need many test cases.
- Monitoring. Someone has to read logs and handle exceptions.
- Maintenance. Connected systems change, and the agent must keep working.
- Usage-based charges. Running many steps can add up, so understand how the tool charges. See how to read an AI tool’s pricing page.
Value comparison
| Question | Chatbot answer | Agent answer |
|---|---|---|
| Time saved per task | Moderate: faster answers and drafts | Potentially larger: whole tasks done |
| Effort to set up | Lower | Higher |
| Effort to oversee | Lower | Higher |
| Impact of failure | Contained | Can spread |
| Speed to first value | Faster | Slower |
A fair test of value
Measure the current time and error rate for the task, estimate the saving, and subtract the time spent overseeing the tool. If the net gain is small, the simpler option is usually the better one.
How to run a small pilot
Do not roll out an agent widely on day one. A staged pilot lets you learn at low risk.
Pilot steps
- Pick one narrow task. Choose something frequent, predictable and low risk.
- Write the steps and the rules. If you cannot describe the process, the agent cannot follow it reliably.
- Start in suggestion mode. Let it propose actions that a person approves.
- Record results. Track accuracy, time saved, exceptions and any near misses.
- Review and adjust. Fix rules, add examples and tighten limits.
- Expand slowly. Allow autonomy for the safest sub-tasks only after a stable run of good results.
- Keep a rollback plan. Know how to go back to the manual process.
Signs you should not proceed
- The team cannot agree what a correct result is.
- There is no reviewer, or reviewers lack time.
- Errors have been serious and hard to detect.
- The data involved is sensitive and the tool’s handling is unclear.
If you want to begin with simple automation before agents, see how to build your first AI workflow without code.
Templates and checklist
Decision template
| Item | Your answer |
|---|---|
| Task | [describe] |
| Desired outcome | [answer, draft, or action] |
| Steps written down? | [yes or no] |
| Cost of a mistake | [low, moderate, high] |
| Reversible? | [yes or no] |
| Data involved | [types and sensitivity] |
| Who reviews? | [name or role] |
| Level chosen (1 to 6) | [level] |
Vendor questions
- What exactly can this tool do in other systems, and can we limit that per action?
- Can we require approval before certain actions?
- Are all actions logged, and can we export the logs?
- How do we pause or stop it immediately?
- What happens to our data, and can we control retention?
- How does it handle cases it cannot manage?
Go-live checklist
- Task is narrow, predictable and documented.
- Permissions follow least privilege.
- Approval gates exist for risky actions.
- Limits on volume and value are set.
- Logging is on, and someone reads it.
- There is a kill switch and a rollback plan.
- Testing included awkward and unexpected cases.
- A named person owns the system.
Frequently asked questions
Is an agent just a better chatbot?
Not exactly. An agent can take actions, which brings extra power and extra risk. A chatbot that answers well may be the better choice when you only need answers.
Can a chatbot become an agent later?
Yes. Many teams start with a chatbot, add read-only lookups, then proposed actions, and later limited autonomy. Moving up in stages lets you build trust.
Do I need technical skills to use an agent?
Some tools are designed for non-technical users, but setting limits, permissions and testing still requires care. Involve someone who understands the connected systems.
What should I never let an agent do on its own?
As a rule, avoid unsupervised actions that move money, delete data, contact people in sensitive situations or make decisions affecting individuals’ rights. Keep a person in approval of those.
How do I know if the label “agent” on a product is meaningful?
Ignore the label and ask what it can do, which systems it can touch, how it decides steps and where a person can intervene. The answers tell you where it sits on the spectrum.
Which is cheaper?
Chatbots are usually cheaper to set up and oversee. Agents can save more time on suitable tasks, but oversight and integration add cost. Compare net benefit, not headline features.
Conclusion
The choice between a chatbot and an agent comes down to what you need done and what happens when it goes wrong. If the outcome is an answer or a draft, a chatbot is simpler, cheaper and easier to control. If the outcome is a completed task, go up the ladder one rung at a time, from suggestions to approvals to limited autonomy, and add each rung only when the one below has proved itself.
Whichever you choose, put permissions, approval gates, logging and an escape route around it, and keep a person accountable for results. To continue, read AI agents explained for non-technical readers and how to choose an AI tool.
