AI Support Agent vs Chatbot: What the Word “Agent” Actually Changes
September 15, 2026 · 10 min read · by the hiy team
The short answer
A chatbot produces a reply. An AI support agent produces a reply and takes responsibility for what happens when the reply is wrong or missing. Concretely, four things separate them: where the answer comes from (your documentation, retrieved per question, rather than a script or the model's general memory), what it does when the material runs out (says so, instead of improvising), what happens to the customer who is still stuck (a handoff to a person, with the conversation attached), and what happens afterwards (the miss becomes a question you answer once, and the agent knows it from then on). If a product does all four, "agent" is earned. If it does the first and skips the other three, it is a chatbot with a newer model.
The word does not mean the thing acts on its own in the wider world. In support, the autonomy that matters is the authority to refuse and the authority to hand off — not the ability to book a flight.
What is a chatbot, precisely?
Three things get called a chatbot, and it helps to name them.
The first is the scripted bot: a decision tree of buttons and canned replies. It cannot be wrong, because it cannot say anything you did not type in advance, and it cannot help with anything you did not anticipate. Most people's frustration with "the bot" is with this one.
The second is the general model in a widget: a large language model with a system prompt that says "you are Acme's helpful assistant". It is fluent on everything and grounded on nothing. Ask it about your refund window and it will answer from what refund windows usually are.
The third is the doc-chat widget: the model plus retrieval over your help centre. This is the one most often sold as an agent, and it is genuinely better — the answer usually starts from your material. The gap between this and an agent is entirely in what it does at the edges: when retrieval comes back thin, when the customer needs a person, and when the same question comes back tomorrow.
What makes an AI support agent different?
The differences are all at the edges, and each one can be checked in a demo.
| The job | A chatbot | A support agent |
|---|---|---|
| Where the answer comes from | A script, or the model's general knowledge with your docs as a hint | Passages retrieved from your documentation for this question, with the passage shown so the customer can read it |
| When the material runs out | Fills the gap with something plausible, in your product's name | Says it doesn't have that, in so many words, and offers a person |
| What happens to a stuck customer | The conversation ends, or a form goes somewhere nobody watches | A handoff that carries the whole conversation to a person, recorded the moment it happens |
| What happens afterwards | Nothing; the same gap opens again tomorrow | The missed question waits in a queue; you answer once and the answer becomes a source |
| Whether any of it can be checked | You take the transcript's word for it | The citation opens the passage; the refusal shows what was searched |
Your docs, imported as they are — limits, steps, known issues.
help centre · PDFs · lists
Retrieved for this question, with the passage the customer can open.
citation on every plan
Nothing covers it, so it says so instead of improvising.
“I don’t have that”
Email plus the whole conversation, recorded the second it happens.
Inbox
You answer once. It is a cited source from then on.
one answer, permanent
Where does the answer come from?
For an agent, from your material and from nothing else — retrieved per question, so a question about export limits pulls the export page, not a paragraph that happens to mention exports. The tell is the citation. Not a label naming a document, which any widget can print, but the passage itself, open and readable beside the answer, so a customer deciding whether to trust the reply can read what it stands on. There is a longer treatment of the difference between a label and a receipt in an AI chatbot that cites its sources.
Some material should not be paraphrased at all. A plan limit, an error code, a price, a known bug and its workaround are things a customer needs exactly, and an agent that keeps them as rows in a list and quotes the row is doing something a chatbot does not: it is looking the fact up rather than remembering it. In hiy, that is what lists are for — a Known issues list, a Common questions list — and the agent reads the row rather than describing it from memory.
What does it do when the material runs out?
A chatbot answers anyway. That is not malice; a language model is a completion engine, and a confident paragraph is its most natural completion. Give it three loosely related passages and an instruction to be helpful and it will stitch an answer out of them. About your product. In your name.
An agent has the authority to refuse. The refusal has to be real — enforced by what reaches the model, not just requested in a prompt — and it has to be visible, so a customer can tell "there is nothing on this" from "nobody looked". The mechanics of making a refusal enforceable are in a chatbot that only answers from your documents; the reason a refusal is worth designing at all is in why AI twins should say "I don't know". A hiy Support Agent starts on the strictest scope setting any variant has, because a confident guess about your own product is the most expensive kind of wrong.
What happens to the customer who is still stuck?
This is where most doc-chat widgets stop being agents. The customer has asked something the docs do not cover, the widget has said so (or, worse, has not), and the conversation simply ends. A form may appear. It may go to an inbox nobody checks.
An agent treats a stuck customer as a live obligation. It offers a person, takes an email, and the handoff is recorded the moment it happens — with the whole conversation attached, so whoever picks it up reads what the agent already tried rather than one line of context. In hiy the handoff lands in the agent's Inbox whatever your notification settings say, because someone is stuck right now. What a handoff must carry, and the two ways it most often fails, is a post of its own: when a support agent should hand off to a human.
What happens afterwards?
Nothing, for a chatbot. The same question that had no answer today has no answer tomorrow, and the only record is a transcript somebody might read.
For an agent, the miss is data. The question it could not answer waits in a queue; you answer it once, in your own words; the answer becomes a cited source, and the next person who asks gets it. The agent improves because it was used, not because you rebuilt it. That queue is only useful if it fills with genuine misses — a queue full of questions the agent did in fact answer is a queue nobody reads — which is why hiy writes it only when the reply reads as a decline in the wordings the model actually produces, checked against a corpus of real stored answers, rather than inferring a miss from weak retrieval scores.
Is "agent" the same as "agentic"?
No, and the conflation causes bad purchases. "Agentic" usually means the system can do things — call an API, change a subscription, open a ticket in another tool. Some support agents can, and it is useful: hiy's actions let an agent notify someone or call your endpoint when a conversation meets a condition you wrote.
But that is not what makes it an agent for support. A widget that can change a plan and also invents your refund policy is a liability with a button. The autonomy that matters in support is the authority to refuse and the authority to hand off. Get those two first; add actions once you trust the answers they would act on.
What "agent" does not change
Three things stay true whichever word is on the box:
- It cannot know what is not written down. An agent answers from your documentation. If the documentation is thin, contradictory or stale, the agent's answers will be too, and the honest ones will be refusals. How to write help docs an agent can answer from is most of the work.
- It is not a person, and should not act like one. A support agent should say it is the product's support and that it may make mistakes, and should never carry a borrowed voice. In hiy a Support Agent has no persona layer at all — the part that carries a person's phrasing is never built for it.
- It does not sell. A support conversation that turns into a pitch is a broken one. The hiy Support Agent has the catalogue removed before the prompt is assembled and the booking link withheld from every answer, as a bound rather than a rule it could be talked out of.
Five questions to ask any demo
- Ask something the docs answer, then open the citation. Is it the passage, or a document name?
- Ask something adjacent to the product that the docs do not cover. Do you get a refusal, or a fluent paragraph?
- Ask to speak to a person. What exactly happens, and where does it land?
- Ask for a specific number — a limit, a price. Is it quoted from a row, or reconstructed?
- Ask what happens to the question it could not answer. Is there a queue, and does answering it change the next reply?
Two out of five is a chatbot. Five out of five is an agent.
The honest version
An agent is not correct by construction. A well-cited, confidently worded misreading of your own passage passes every test above, because something was retrieved and it did score well. Refusal stops invention from thin air; it does not stop misinterpretation of real material. If your domain needs guaranteed-correct answers rather than sourced ones, no support agent gets you there, and neither does a human on a bad day.
And the loop only closes if someone is on the other end of it. A handoff nobody reads and a queue nobody answers turn an agent back into a chatbot within a week.
Where to start
If you are evaluating tools, run the five questions on each one's demo before you read a feature list. If you would rather see the four differences working on a product's real docs, the hiy agent on the Support Agent page answers from a sample product's documentation — open a citation, ask it something the docs do not cover, and watch what it does with the gap.
Questions people ask
Is an AI support agent just a chatbot with a better model?
No. The model matters less than what surrounds it: retrieval from your documentation per question, a visible citation, an enforced refusal when the material runs out, a handoff that carries the conversation to a person, and a queue that turns misses into new sources. A better model inside a widget that skips those is a more fluent chatbot.
Does an AI support agent need to take actions to count as an agent?
Not for support. Actions — calling an API, opening a ticket — are useful once the answers are trustworthy, but the autonomy that defines a support agent is the authority to refuse and the authority to hand off. A widget that can change a subscription and also invents your refund policy is not an agent, it is a risk with a button.
Can a support agent answer things that are not in the documentation?
It should not. An agent answers from your material and refuses otherwise; the refusal is the feature. What it can do is record the question so you answer it once, after which the answer is a source like any other.