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

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 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.

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.

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?