An AI chatbot answers questions from your own content and changes nothing outside the conversation. An AI agent is given tools, functions your code exposes, and the model decides which to call and in what order, so it can look up an order, reply to a ticket or change a record. Start with a chatbot, and add agent actions only for tasks that are bounded and easy to undo.
What is the difference between an AI chatbot and an AI agent?
A chatbot only talks, and an agent can also act. The line is not how capable the model is, but whether anything outside the conversation changes.
A chatbot takes a question, searches your help articles and policies for the relevant passages, and writes an answer from them. That search step is usually called retrieval. When it works, the answer is grounded in your documents and can link the one it used.
An agent is built on what OpenAI calls function calling and Anthropic calls tool use. Both describe the same round trip:
- Your application sends the request with a list of tools, each with a name, a description and a JSON schema for its inputs.
- The model replies with a tool call: the tool it wants and the arguments it chose.
- Your code runs the function, or refuses to.
- Your application sends the result back to the model.
- The model answers, or asks for another tool.
The model never runs your function. It proposes, and your code decides. Anthropic's server tools, such as web search, are the exception and run on Anthropic's infrastructure. Anything that touches your systems runs in your code, where your permissions and checks belong.
Is there an option between a chatbot and an agent?
Yes, a workflow, and it is often the right choice. Anthropic's engineering post Building effective agents separates workflows, where models and tools are orchestrated through "predefined code paths", from agents, where the model directs its own process and tool usage. The same post recommends the simplest solution that works, which "might mean not building agentic systems at all", and warns that autonomy brings higher costs and compounding errors.
| Point | Chatbot | Workflow | Agent |
|---|---|---|---|
| Who decides the next step | Nobody. It answers and stops. | Your code, in a fixed order. | The model, one step at a time. |
| What it can change | Nothing, apart from a hand-off ticket. | Only what each fixed step does. | Anything its tools allow. |
| Typical job | Answer from the help center. | New ticket: classify it, draft a reply, wait for staff. | Investigate an open-ended problem across several systems. |
| Main failure | A wrong or invented answer. | A step that fails the same way each time, which is easy to spot. | A wrong action reached by a path nobody planned. |
| Cost per request | Lowest and fairly steady. | Steady: one model call per step. | Varies with the number of turns. |
Many requests I scope as "an agent" turn out to be workflows: the model classifies a new ticket and drafts a reply, and a person sends it. That is easier to test and cheaper to run.
What does a chatbot need to answer well?
It needs current content, retrieval that finds the right passage, and a way out when it does not know. The model is the smaller part of the work.
- Current content. If two help articles disagree, the bot will repeat either one with confidence. Fix the source first.
- Retrieval tested on real questions, including badly worded ones.
- Source links. The customer can check the answer, and you can find the article to fix.
- A refusal path. "I am not sure; here is how to reach a person" is a good answer. A guess is not.
- Identity from the login session. Account-specific answers must use the logged-in session, never an email address typed into the chat.
What does an AI agent need that a chatbot does not?
It needs narrow permissions, checked inputs, human approval, logs and limits, because it can change things. The OWASP GenAI Security Project lists excessive agency among its top risks and splits it into excessive functionality, excessive permissions and excessive autonomy. Each control below answers one of those.
- Few tools, each doing one job. "Add a ticket note" is a tool. "Run any API command" is not.
- Its own credentials, scoped down. Start read-only and add each write permission separately.
- Inputs checked in code. OpenAI recommends strict mode so that calls match your schema. A call that matches the schema can still name the wrong customer, so check the values as well.
- Human approval for consequential actions. Money, deletion and any message a customer will treat as official wait for a person.
- A log of every call. Record the request, the tool, its inputs, the result and who approved it.
- Limits. Cap the steps per request, the actions per hour and the spend per day.
- Outside text treated as data. OWASP's entry on prompt injection describes indirect injection, where a web page or file the model reads changes its behavior. A support ticket written by a stranger is exactly that kind of input.
How are AI chatbots and AI agents billed?
Both are billed by usage, and an agent uses more per request. A tool that runs in your own code has no separate fee, but it adds tokens. OpenAI's guide says function definitions "count against the model's context limit and are billed as input tokens". Anthropic's says tool-use requests are priced on input tokens, including the tools parameter, plus output tokens, that a tool-use system prompt is added automatically, and that server tools such as web search carry their own usage charges.
| Cost driver | Chatbot | Agent |
|---|---|---|
| Model calls per customer question | Usually one | One per step, until the model stops calling tools |
| Input sent each time | The question and the retrieved passages | The conversation so far, the tool definitions and every tool result |
| Other charges | Hosting for the search index | The same, plus server tools if you use them |
| Predictability | Fairly steady | Depends on how many turns a task takes |
I quote no prices, because they change. Read each provider's current pricing page, set a spending limit in the provider's console, and measure the cost per conversation in a pilot.
What can go wrong with each?
A chatbot fails by saying something wrong, and an agent fails by doing something wrong. The second costs more to repair.
| Aspect | AI chatbot | AI agent |
|---|---|---|
| Typical failure | A wrong, outdated or invented answer. | The wrong record, the wrong customer, or an action taken twice. |
| Who notices | The customer, often after acting on the answer. | Possibly nobody, until a bill or a complaint arrives. |
| Undo | Correct the answer or the article. | Needs a deliberate undo path, and some actions have none. |
| Extra risk | Revealing private data if identity is not checked. | Instructions hidden in text it reads, and side effects in other systems. |
Which one does your business need?
Choose by the job and the cost of a mistake, not by which sounds more advanced.
| Your situation | Start with | Why |
|---|---|---|
| Customers ask questions your documentation already answers | Chatbot | Retrieval does the job and nothing outside the chat can break. |
| Answers depend on the customer's own plan or invoice | Chatbot with read-only lookups | It uses account data without changing it. Identity comes from the session. |
| Staff write the same replies again and again | Workflow that drafts, with a person sending | You save time and a person still owns every message. |
| A routine task with clear rules, low cost if wrong and an easy undo | One agent action behind approval | A safe first action, kept behind approval until the logs earn trust. |
| Refunds, deletions or contract terms | Chatbot or drafts only | The cost of a mistake is too high to remove the person. |
| Thin or outdated documentation | Fix the content first | Every option repeats what you give it. |
How do you move from a chatbot to an agent safely?
Add one action at a time and let the logs decide when to loosen control.
- Chatbot on public content, with source links and a hand-off to a person. Read the logged questions every week at first.
- Read-only lookups for logged-in customers. It still changes nothing.
- Drafts for staff. A person edits and sends each one, which tests the model's judgment on real cases cheaply.
- One low-risk action behind approval, chosen because it is the most repetitive and the easiest to undo.
- Relax approval for that action only, once the error rate in the logs is one you accept.
- Repeat for the next action, each with its own permission, test cases and log review.
Money-moving actions can stay behind approval for good. That is sound design.
What does this look like for a hosting company?
Take a customer who writes "my email is broken". A chatbot answers from your articles on mailbox limits and DNS. With read-only lookups it can first check whether the service is suspended for an unpaid invoice, using WHMCS API actions such as GetClientsProducts and GetInvoices. A workflow can save a suggested reply as a staff-only note with AddTicketNote. Sending it with AddTicketReply, or unsuspending with ModuleUnsuspend, are bigger steps that I keep behind approval.
The WHMCS AI chatbot page compares the routes to building this, and what a WHMCS-aware AI chatbot needs to do turns the requirements into tests you can run on any product.
When should you build neither?
Build neither when your documentation is thin, when you cannot name the first three questions or tasks you want handled, or when the plan needs broad admin credentials or unattended control of payments. And do not measure success by tickets closed. Track whether customers come back with the same question.
If you know your first questions, AI chatbot development covers that build, and AI agent development covers workflows and agents that take actions.
Last reviewed 12 October 2026. Disclosure: I sell AI chatbot and AI agent development, so I am not neutral. I am CTO at ElySpace, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI, an AI chatbot and live chat. Tool-calling and billing details come from the OpenAI and Anthropic documentation as I read it on that date.
