AI Agent vs Chatbot: One Talks, One Gets Things Done

Published 2026-09-07 · Updated 2026-09-07 · 8 min read · AI 工作術 (FreeCo Co., Ltd.)

Chatbots answer questions. Agents call tools, plan steps, and take real actions. Here is how to tell them apart and which one your business actually needs.

A chatbot talks. An AI agent does things. That is the whole difference in one line, and it matters more than most meeting-room conversations admit. When one person says "let's build an AI customer service bot" and another says "let's build an AI agent," they often think they are describing the same project. They are not. The architecture, the cost structure, and the risk profile differ by roughly an order of magnitude.

A chatbot receives a question, works out what you mean, assembles an answer from a knowledge base or from the model's own training, and replies. Language goes in, language comes out. An agent takes a goal, breaks it into steps, calls real systems through APIs, checks the results, and adjusts until the job is done or it hits a wall. One answers "where is my order?" with a link to the tracking page. The other looks up the order, sees it is stuck at a depot, and files the reshipment request.

Here is the honest part: most businesses right now need the chatbot, not the agent. But the ones that get the chatbot right are the ones positioned to add agent capabilities later without rebuilding. We run our own AI tool platform, an AI video-editing engine, and ad-creative tooling, and we have built both kinds. This article walks through what separates them, what an agent costs you in design discipline, and how to decide which one your problem actually calls for.

Chatbots: a question-and-answer layer over what you already know

The modern chatbot is a much better product than the scripted decision trees of five years ago. Put a large language model in front of your documentation, add retrieval so it pulls from your actual policies instead of guessing, and you get something that handles "what are your opening hours," "what is your return policy," "does this model support USB-C," and "what is the procedure for X" reliably. If you have not seen how retrieval works, our plain-language explainer on RAG covers it in ten minutes.

This is mature technology. The risk is low because the worst outcome is a wrong or unhelpful answer. The cost is predictable because every interaction is roughly one model call plus one retrieval. If your support queue is dominated by the same fifty questions asked a thousand different ways, a chatbot with a good knowledge base absorbs most of that volume, and you should build it before you build anything else.

The ceiling is just as clear. A customer asks "where is my order?" and the chatbot says "please check the order tracking page." A customer says "ship it to my office instead," and the chatbot says "please contact a support representative." It knows a lot and can do nothing. Every time your bot has to hand a customer back to a human for a task that is fundamentally a database lookup or a form submission, you are looking at the line where a chatbot ends and an agent begins.

AI agents: tool use, planning, and the ability to try again

Strip away the hype and an agent is defined by three capabilities. If a system has all three, it is an agent. If it has none, it is a chatbot, however sophisticated its conversation.

• Tool use. The model can call your systems: look up an order, change an address, open a return, send a notification. The model's job shifts from "generate a paragraph" to "decide which tool to call right now and with what parameters." The text it produces is often not for the user at all. It is a structured function call.
• Multi-step planning. "Return the order I placed last week" is not one action. The agent decomposes it: find last week's orders, confirm which one the customer means, check return eligibility, create the return request, report back. The result of each step changes what happens next. If eligibility fails, the plan branches into an explanation instead of a return.
• Iteration and self-correction. The lookup returns nothing, so the agent widens the date range and searches again. The API returns a validation error, so the agent fixes the parameter and retries. This loop is the real difference between an agent and a traditional automation script. A script follows a fixed path and fails when reality deviates. An agent notices the deviation and works around it.

We run a concrete example of this in production. When a video lands in our AI clipping engine, the pipeline transcribes the audio, hands the transcript to a language model that picks the strongest segments, then drives the cutting and captioning steps to produce finished clips. Nobody sits watching it. The model makes judgment calls partway through the workflow, invokes tools, and ships an output. That is agent architecture, even though no one ever "chats" with it. The point is not conversation. The point is that the model is inside the process, making decisions that trigger real actions.

More capability means more design responsibility

An agent that can act can act wrongly. That sounds obvious, but teams routinely plan agents with the same casual risk tolerance they used for the chatbot, and the two are not comparable. When a chatbot gets something wrong, you lose one customer interaction. When an agent gets something wrong, you lose real money, real data, or a real relationship. We treat three rules as non-negotiable when we design anything that can take action.

1. Least privilege, always. Give the agent only the APIs the task needs, and separate read permissions from write permissions. Being able to look up an order does not mean being able to modify it. Being able to change a shipping address does not mean being able to issue a refund. Scope each capability independently and grant the minimum.
2. Humans confirm irreversible actions. Refunds, deletions, anything sent to an external party. Design these so the agent prepares everything and a person presses the final button. If full automation is genuinely required, put hard caps on amount and scope so a bad decision has a bounded cost.
3. Log every tool call. Every invocation, with its inputs and outputs, gets recorded. When something goes wrong, and it will, you need to reconstruct exactly why the agent did what it did. Without that trail you cannot debug, you cannot audit, and you cannot explain the failure to the customer it affected.

A chatbot error costs you an experience. An agent error costs you a transaction. The more hands you give an AI, the stronger the reins need to be.

These rules interact with model quality too. An agent that hallucinates an order number and then acts on it is worse than a chatbot that hallucinates the same number in a reply, because the action is real. The guardrails we describe in our production hallucination defense apply doubly here, and you should have automated evaluation of agent decisions running before the system touches anything a customer can see.

Which one do you actually need?

Skip the technology question and start with the pain. Where is the time going, and what would have to happen for it to stop?

• If your pain is "the same questions, asked a hundred times a day," a chatbot with a solid knowledge base is the answer. Do not build an agent for this. You would be paying for tool-calling infrastructure and permission design to solve a problem that retrieval alone handles.
• If your pain is "every query ends with a human doing the actual task," that is an agent scenario. The workflows that fit best share four traits: clear steps, systems that expose APIs, errors that can be undone, and volume high enough that automation pays for itself. If any of those is missing, the case gets weaker fast.
• If you are honest, it is probably both. The mature pattern is a chatbot as the foundation, with two or three high-frequency tasks upgraded to agent capabilities: order lookup, rescheduling, status checks. Not a do-everything assistant. A support layer that answers well and can complete a short list of specific jobs.

The do-everything assistant is the trap. It sounds like the vision, and it is how most agent projects fail. Every additional capability multiplies the permission surface, the failure modes, and the test matrix. Three tasks done reliably beat thirty tasks done unpredictably, every single time.

A practical order to build in

Here is the sequence we recommend, and the one we follow ourselves.

1. Get knowledge-base Q&A stable first. This step alone absorbs a large share of support volume, and it forces you to clean up your documentation, which pays off regardless of what you build next. Measure deflection rate and answer accuracy before moving on.
2. Add one read-only task. Connect a single lookup API: order status, booking details, account balance. Read-only means the worst case is a wrong display, never a wrong change. This is where you learn how the model behaves with tools, how often it picks the wrong parameters, and what your logging needs to look like.
3. Only then open write operations. Once the read-only task has run stably for weeks and you trust the logs, add a single low-risk mutation with confirmation and caps. Expand from there one task at a time, each with its own permission scope.

Do not skip steps. Teams that jump straight to write-capable agents almost always end up rolling back to step two after the first incident, having lost time and some trust with the people who use the system. An AI that gets things done is genuinely compelling. Just make sure that, for every single thing it does, you would be comfortable putting your name on the result.

FAQ

Q: Is ChatGPT a chatbot or an agent?
Out of the box, a chatbot. It takes text in and gives text out. When you enable tools like web browsing, code execution, or connected apps, it starts taking actions and behaves like an agent for those tasks. The label depends on whether the model can call tools and act on the results, not on the product name.

Q: Do I need an agent framework to build an agent?
Not necessarily. The core loop is simple: the model picks a tool, your code runs it, the result goes back to the model, repeat until done. Frameworks help with orchestration, retries, and observability at scale, but many production agents start as a few hundred lines of plain code around a model API with function calling.

Q: Are agents much more expensive to run than chatbots?
Yes, usually. A chatbot answer is roughly one model call. An agent task can take five to twenty calls as it plans, calls tools, reads results, and re-plans. Budget for it, cap the number of steps per task, and check the official pricing pages of whichever models you use.

Q: Can a chatbot be upgraded into an agent later?
Yes, and that is the recommended path. A well-built chatbot already has the knowledge layer and the conversation handling. Adding tool access on top for one or two tasks is an incremental change, as long as you design permissions and logging properly when you add them.

Q: How is an agent different from workflow automation tools?
Traditional automation follows a fixed path you define in advance. An agent decides the path at runtime based on what it observes, and can recover when a step fails unexpectedly. If your process never varies, fixed automation is cheaper and more predictable. Agents earn their cost when the process has judgment calls in it.

← AI Knowledge Base · 中文版