Chatbots vs. AI Agents: Which One Does Your Workflow Actually Need?

The Short Answer

Choose a chatbot when the job ends with someone knowing something, and an agent when the job ends with something being done — a record updated, a message sent, a booking made. Between the two sits a third option most teams overlook: a fixed workflow with a language model in one step, which is cheaper and more predictable whenever the steps are the same every time. The rest of this guide is how to tell which of the three you need, and how to test it on your own requests before you build.

The Definition Is Not Your Problem

If you need the definitions, they live one page over in what an AI agent actually is, and that page does the job properly. This one assumes you have read something like it, understood the distinction perfectly well, and are still stuck — because the definition does not tell you which one to put in your product, and that is the decision you are actually facing.

The short version of the difference, so you can carry on: a chatbot converses. An agent acts. A chatbot takes input and returns text; an agent takes input, plans, uses tools, changes something outside itself, and adapts based on what happened. Everything below is about choosing between them.

The Question Is About Actions, Not Intelligence

The most common way this decision goes wrong is treating it as a capability ladder, with agents at the top. They are not two rungs. They are two shapes, and picking the more capable shape for a job that does not need it is a real cost rather than a harmless over-spend.

There is one question that decides it, and it is narrower than it looks:

What does this thing need to change in the world in order to be useful?

If the honest answer is "nothing — it needs to tell someone something", you want a chatbot, and the most sophisticated model in the world does not alter that. If the answer includes any action at all — writing to a record, sending something, booking something, moving a file — you are in agent territory whether or not you use the word.

Everything else people argue about (which model, how good the reasoning is, whether it "understands") is downstream of that one answer.

Where Each Sits

The Third Option: a Workflow

Anthropic's guide Building effective agents (December 2024) draws a line that is useful here. In a workflow, a model and its tools follow code paths a developer wrote in advance; in an agent, the model directs its own process and decides which tools to use. Anthropic's advice is to find the simplest solution that works and add complexity only when it is needed, because agentic systems trade latency and cost for better task performance, and their autonomy brings higher costs and the potential for compounding errors.

In practice that means the "agent" column is often really two columns. If a request always runs the same steps — read the form, look up the customer, draft the reply, send it for approval — an automation tool such as Zapier, Make or n8n with a model in one step does it more cheaply and more predictably. Reserve a true agent for work where deciding the steps is part of the job.

The Cost Asymmetry Runs Both Ways

The usual framing is that agents cost more. That is true of the build, and it is not the interesting half.

Over-building costs you time and surface. An agent needs permissions to be scoped, actions to be logged, loops to be bounded, failures to be visible, and someone to review what it did. Every one of those is real engineering that a chatbot simply does not need. Choosing an agent for a Q&A problem means paying for all of it and getting answers you could have had for far less work.

Under-building costs you the whole use case. A chatbot deployed where the user actually needed something done produces a specific, recognisable failure: it explains, correctly and politely, how the user could do the thing themselves. It is never wrong. It is just never useful, and it takes months to admit that, because every individual answer passes review.

The second failure is the more expensive one and the harder one to see, because nothing in your quality metrics goes red.

Five Questions That Settle It

• What changes if this works? If the honest answer is "the person knows something

• Who fixes it when it is wrong? A wrong answer is absorbed by the reader. A wrong

• Does the task have a fixed shape? If the steps are the same every time, you may

• Can you undo everything it might do? If not, you have not got a technology

• What is the smallest version that would prove this? If you cannot describe one,

The Blurry Middle Is Where Most Real Products Live

Plenty of tools sit in between and it is not evasion — it is the correct design for most commercial problems. A customer-service tool that answers from a knowledge base is a chatbot; give it the ability to look up an order, and it is doing something agent-shaped; let it issue a refund, and it is unambiguously an agent with everything that implies.

The useful observation is that these are usually the same product at different permission settings. Which means the practical question is rarely "chatbot or agent" in the abstract. It is which specific actions do we switch on, and in what order.

That reframing is worth more than any comparison table, because it turns a procurement argument into a sequence you can actually run: ship the read-only version, watch it, add one write action, watch that, and keep going. See how to build an agent workflow for what that sequence looks like in practice. Intercom Fin is a good example of a product that is either one depending on how it is configured.

Intercom's own pricing page shows how fine those settings get. It charges for Fin "from $0.99 per Fin outcome" and counts an outcome when a customer confirms the issue is resolved, stops asking for help after Fin replies, or when Fin completes a workflow — handoffs to a human included — charging once per conversation (pricing page, 16 October 2026). The same product answers questions, takes actions in external systems and hands off to the inbox; what you switch on decides which side of the line it sits, and how you measure success decides whether the bill reflects real resolutions.

How to Test Before You Commit

Take twenty real requests from the last month — real ones, with their mess intact, not the tidy examples in your requirements document. Sort them into two piles: ones that end with somebody knowing something, and ones that end with somebody doing something.

If the first pile is almost everything, build the chatbot and stop. If the second pile is substantial, you need agent capability for that pile specifically, and quite possibly a chatbot for the rest — which is a completely respectable answer and one that almost nobody proposes, because it is less exciting than picking a side.

For the first pile, building the chatbot rarely means building one from scratch any more. CustomGPT.ai, for example, answers from your own content — it lists 1,400+ supported file types plus integrations — includes citations and sources on every plan, and deploys on a website, a help centre or internally. Its Standard plan is $99 a month for 1,000 queries, with a 7-day free trial (as listed on its pricing page on 1 October 2026), which is long enough to run those twenty real requests through it before you commission anything bigger.

The Counter-Argument: Start With the Agent Anyway

There is a serious case against all of the above, and it is worth stating properly.

If you are confident the roadmap ends in actions, building the chatbot first can be a detour rather than a step. The architectures genuinely differ — an agent needs tool definitions, a permissions model, an execution log and a rollback story, and none of those retrofit cleanly onto something designed to return a paragraph. Teams that "start simple" sometimes spend a year building the simple thing well and then rebuild it entirely.

The honest test between the two positions is whether you know the actions are coming, or merely suspect it. If a specific action is already on the roadmap with a named owner, design for the agent. If it is a hypothesis about what users might want later, build the chatbot — most of those hypotheses do not survive contact with real usage, and the ones that do will have taught you which action actually matters.

What Goes Wrong With Each

Chatbots fail quietly. They answer confidently from a stale knowledge base, escalate too late, and accumulate a reputation for uselessness one interaction at a time. The fix is almost never the model. It is the source of truth behind it.

Agents fail loudly, which is genuinely better. They loop, they take an action twice, they act on a misread instruction. The mitigations are known and unglamorous: a step limit, a log of what was actually done rather than only the final output, a stop condition, and a human on anything irreversible or outward-facing.

→ Browse all agents by capability | Intercom Fin profile

Related: What Is an AI Agent? | How to Build an AI Agent Workflow | Will AI Agents Replace Your Job?

Frequently asked questions

What is the real difference between a chatbot and an AI agent?

The difference is actions, not intelligence. A chatbot receives input and returns text. An agent plans, uses tools and changes something outside itself — writing a record, sending a message, booking something — and adapts based on what happened.

How do I decide whether my workflow needs a chatbot or an agent?

Ask what the tool must change in the world to be useful. If it only needs to tell someone something, use a chatbot. If it must take any action, you are in agent territory — and if the steps are identical every time, a fixed workflow with a model in one step may be the cheaper answer.

What is the difference between an AI agent and an AI workflow?

In a workflow, a developer writes the sequence of steps in advance and the model follows it. In an agent, the model decides the steps and tools while it works. Anthropic recommends starting with the simplest option that works, because agents trade cost and latency for flexibility.

What happens when you deploy a chatbot where users need something done?

It explains, correctly and politely, how users could do the task themselves. The answers pass review, so the failure is easy to miss for months, but the tool never actually solves the problem.

How do chatbots and agents fail differently?

Chatbots fail quietly, answering confidently from a stale knowledge base and escalating too late. Agents fail loudly — looping, repeating an action, acting on a misread instruction — which is easier to spot and is controlled with step limits, action logs, stop conditions and human approval for anything irreversible.