Types of Chatbots: A Working Taxonomy

Where the six categories actually come from

No ISO, IEEE or W3C document defines chatbot types. The taxonomy is a convention, and it is worth understanding as one, because conventions have edges that formal definitions do not.

Every chatbot in production sits somewhere on two independent axes. Once you can place a product on both, the category name falls out automatically, and you stop needing to trust the vendor's label.

Axis one: where the words come from

Either a human wrote the reply before the conversation started, or a language model composed it during the conversation. That is a hard architectural line with no middle ground. A scripted system can select from thousands of pre-written replies and it is still selecting. A generative system writes a sentence that did not exist a second earlier. Rule-based, keyword-based and menu-based chatbots all sit on the scripted side of this line. The differences between those three are about matching, not about generation.

Axis two: what the user is allowed to do

Either the interface constrains the user to a set of options, usually buttons or a numbered list, or it accepts free text. Constraining input removes the hardest problem in the system, which is working out what somebody meant. That is why button-based bots are so reliable and so limited at the same time.

Plot the two axes and you get four quadrants, not six categories. The extra two labels exist because the scripted, free-text quadrant is large enough to need splitting (keyword matching versus intent and state tracking, which is what contextual means), and because so many real products span quadrants that the industry needed a word for it, which is hybrid. That is the whole derivation. It is useful, it is not law, and any list that presents these six as fixed natural kinds is overselling them.

One further caution about labels. Generative does not mean autonomous. Anthropic's engineering write-up on building effective agents draws the line between workflows, where models and tools are "orchestrated through predefined code paths", and agents, which are "systems where LLMs dynamically direct their own processes and tool usage". Almost every product sold as a chatbot, including ours, is on the workflow side of that line. Gartner went further in June 2025 and coined "agent washing" for vendors relabelling assistants, RPA and chatbots as agentic, reporting that of thousands of vendors making the claim only around 130 were genuine. If you want that boundary in detail, see AI agent vs chatbot.

The six types of chatbots

Read these as descriptions of mechanisms rather than of products. Most products contain two or three of these mechanisms at once.

1. Rule-based chatbot

A rule-based chatbot walks the user through a decision tree that a human designed in advance, returning pre-written replies at each branch.

Someone maps the conversation as a flow chart. Conditions on each branch decide where the conversation goes next, and every reply is a string sitting in the configuration. The bot can carry state through the flow, so it can ask for an order number and then use it, but it can only ever go where the flow chart goes.

Pros: entirely predictable, auditable before launch, cheap to run at any volume, and genuinely good at transactions. Cons: coverage equals whatever the author anticipated, every content change is a manual edit to every affected branch, and building a tree that covers a real support surface is weeks of work that decays. Best for: booking, password resets, returns initiation, qualification questionnaires, and anything where the exact wording is legally significant.

Examples: Landbot flows, ManyChat automations, Tidio Flows, Most IVR phone menus

2. Keyword-based chatbot

A keyword-based chatbot scans the user's free text for trigger words or patterns and returns the reply attached to the first rule that matches.

This is the oldest mechanism in the field and it is closer to a search-and-replace than to understanding. Rules are typically written as keyword lists or regular expressions, with a priority order and a fallback for no match. There is no model of what the sentence means, which is why adding a synonym list is a permanent maintenance job.

Pros: trivial to set up, instant, costs nothing per message, and easy to explain to a stakeholder. Cons: it fails on paraphrase, it fires the wrong rule on unlucky word choices ("cancel" appears in both "cancel my order" and "how do I avoid cancellation fees"), and it degrades as the rule list grows because rules start colliding. Best for: a handful of high-frequency, high-certainty triggers such as opening hours or a pricing link, usually as a fast path layered in front of something smarter.

Examples: AIML-lineage bots in the ELIZA and ALICE tradition, Messenger page auto-replies, Slack keyword responders

3. Menu or button-based chatbot

A menu-based chatbot never asks the user to type, presenting a set of buttons or a numbered list and branching on whichever option is chosen.

Mechanically it is a rule-based bot with the free-text problem deleted. Because input is constrained to a known set, the system's behaviour is completely enumerable. Every path can be tested, and the failure mode is not misunderstanding but absence: the thing the user wants is not on the menu.

Pros: the highest reliability of any type, works on channels with poor text input, accessible, and requires no language coverage work. Cons: it caps depth, since a menu more than three or four levels deep is worse than a search box, and it cannot handle a question the designer did not put on a button. Best for: the first turn of a conversation as a router, mobile and voice channels, and self-service actions where there are genuinely only six things anyone wants.

Examples: Airline flight-status bots, Bank balance and card-freeze menus, Landbot button flows, Messenger persistent menus

4. Contextual chatbot

A contextual chatbot classifies free text into trained intents, extracts entities such as dates and order numbers, and tracks conversation state across turns.

This is the machine-learning generation that dominated from roughly 2016 to 2022, and it is still what most large voice and call-centre deployments run on. You supply training phrases for each intent, the classifier learns to recognise paraphrases of them, and a dialogue manager holds slots until it has everything a task needs. Crucially, the replies are still authored by humans. The learning happens in understanding the question, not in composing the answer.

Pros: handles paraphrase far better than keyword matching, remembers what was said three turns ago, integrates cleanly with back-end systems for real transactions, and its answers remain exactly reviewable. Cons: every intent needs training data and ongoing curation, out-of-scope questions still fall to a fallback, and building one is a project with specialists rather than a signup. Best for: high-volume, transaction-heavy operations where a defined set of tasks must be completed reliably and integrated with core systems.

Examples: Google Dialogflow CX, Amazon Lex, Rasa, IBM watsonx Assistant, NiCE Cognigy, Kore.ai

5. Generative AI chatbot

A generative AI chatbot passes the question, plus passages retrieved from your own content, to a large language model that composes a new answer at the moment of asking.

The standard architecture is retrieval-augmented generation. Your website, help centre and documents are indexed; when a question arrives the system finds the relevant passages and asks a model such as Claude, GPT or Gemini to answer using them. Nothing is pre-written, no intents are trained, and coverage is a property of your content rather than of your configuration. Update a help article and the bot's answer changes the same day.

Pros: handles phrasings nobody anticipated, combines facts from separate pages into a single reply, works across many languages without rebuilding anything, and setup is hours rather than weeks. Cons: wording varies between runs so it cannot guarantee exact legal phrasing, it costs money per conversation because each answer is a model call, thin source content produces vague or invented answers, and it needs transcript review rather than pre-launch sign-off. Best for: open-ended question answering over documentation, pre-sales questions, and any support surface where customers ask the same things in dozens of ways.

What reduces the invented-answer problem

• Citations. If each answer shows the page it came from, a wrong answer is traceable to content you can fix.
• A strict mode that refuses to answer from outside your indexed material, at the cost of more "I do not know" replies.
• Escalation to a human the moment confidence drops, rather than a second attempt at guessing.

Examples: matram.ai, Fin, the AI agent inside Intercom, Zendesk AI agents, Tidio Lyro, Ada

6. Hybrid chatbot

A hybrid chatbot routes each conversation between scripted flows and a generative model, using deterministic rules where the outcome must be guaranteed and generation everywhere else.

In a typical hybrid, open questions go to retrieval and generation, while specific triggers hand control to a scripted flow: identity verification, refund authorisation, lead capture, escalation to a person. The router itself may be a classifier, a keyword rule, or the model deciding to call a tool.

Pros: you get generative coverage without giving up control of the paths that matter, and you can tighten any individual flow without touching the rest. Cons: two systems to maintain and reason about, harder to debug because the answer depends on which path was taken, and the routing logic itself becomes a thing that can be wrong. Best for: essentially every serious commercial deployment, which is why the pure categories above are increasingly a way of analysing products rather than a way of listing them.

Examples: Zendesk (flow builder plus AI agents), Intercom (Workflows plus Fin), Tidio (Flows plus Lyro), matram.ai (generated cited answers plus deterministic lead capture and escalation)

When no type on this list is the answer

A taxonomy makes every option look like a live option. Sometimes the right pick is none of them, and it saves you a category decision you did not need to make.

At the quiet end, a contact page and somebody who reads it will outperform all six types. If enquiries arrive in ones and twos and get a personal reply the same day, a bot cannot improve the answer, only the hour it arrives. It also adds a surface you now own: content to keep current, transcripts to read, a widget that has opinions about your site's layout. None of that is a good trade for a business whose inbox is already under control.

Friction is the stage where a menu or a keyword bot looks tempting and is usually premature. The tell is repetition: the same question about opening hours or delivery windows, over and over, answered by hand each time. But the first fix is editorial rather than technical. Put the answer on a page, put the page where people look, and see whether the repetition falls away. Plenty of chat widgets exist because nobody wanted to argue about where things live on the site.

It becomes a liability when the volume outruns the person. Queues form. Replies drift to the next working day, which is a real cost if a chunk of your traffic arrives while your team is asleep. Someone senior gets pulled into triage. At that point automating the repetitive slice is genuinely worth doing, and the taxonomy above starts to earn its keep, because the wrong type here means rebuilding in a year.

The case where every type fails

And then there is the business where all six fail, each for its own reason. If nothing anybody asks you is written down, a generative bot has nothing to retrieve and a scripted one has nothing to script. If every question needs live account data, a chatbot of any type can only talk about the system that holds it rather than read it. So the honest sequence puts content first and the category name last. Choosing a type before you know which of those you are missing is how organisations end up with a bot that nobody can explain the purpose of.

The six types compared

Read down the columns to place a product, and across the rows to see what you give up by moving along either axis.

Two of these rows do most of the work. If you need to guarantee wording, you are on the scripted side and no amount of model quality changes that. If you need coverage of questions you cannot enumerate, you are on the generative side and no amount of flow building gets you there. The remaining rows are consequences.

What actually drives cost, by type

Per-type monthly price ranges circulate widely and none of them survive checking, so this table gives drivers instead of figures. The pattern that matters: scripted types front-load cost into human build time and then stay flat, while generative types are cheap to start and scale with conversation volume.

Vendor pricing follows the same split and is much harder to compare than it looks. Fin, the AI agent in Intercom, bills $0.99 per outcome with a 50-outcome monthly minimum. Contextual platforms are usually quoted rather than published: as of 20 July 2026 both cognigy.com/pricing and kore.ai/pricing return 404, and ada.cx/pricing shows a consultation link rather than rates, so the only public figures are marketplace listings such as Kore.ai's $0.015 to $0.20 per session. Flat monthly SaaS pricing like ours sits at the other end. To compare like with like, put your own volumes into the chatbot ROI calculator, and if you are weighing a custom build see the chatbot development cost breakdown.

Which type fits which job

Start from the job rather than from the technology. In most organisations the honest answer is more than one type, deployed on different surfaces.

For most small and mid-sized businesses the practical answer is a hybrid weighted towards generation: let it answer questions from your existing content, and keep deterministic rules for lead capture and human handover. That is what a small business chatbot usually needs, and the same shape works for a SaaS support surface. If you are comparing specific vendors rather than categories, the alternatives comparisons and the Intercom alternative page are the more useful reading.

Why the pure categories are becoming analytical

The taxonomy still explains how things work. It is getting worse at describing what you can buy.

Ten years ago you bought a flow builder or you bought an NLU platform and the two were different companies. Today the flow-builder vendors have added language models and the model-first vendors have added flow builders, so almost every mainstream product is a hybrid whatever its marketing says. Zendesk now describes its AI agents as "autonomous systems designed to understand and autonomously resolve complex issues on any channel" that, "unlike traditional chatbots", "can reason across multi-step requests", while continuing to ship the deterministic flow builder alongside. Consolidation has pushed the same way: Salesforce announced in June 2026 that it is acquiring Fin, the company formerly known as Intercom, for around $3.6bn, and reports that Fin resolves on average 76% of support volume end to end across 30,000-plus customers.

So the useful question when you evaluate a product is not "which of the six is this". It is a set of mechanical questions the categories are shorthand for.

Questions that place any product on the map

• Is this answer generated at request time, or selected from text a human wrote? Ask directly, because both are marketed as AI.
• If it is generated, what is it grounded in, and does it show me the source page for each answer?
• What happens to a question nobody anticipated? Fallback message, escalation, or an attempt at an answer?
• Which paths are deterministic, and can I see the list? Escalation and lead capture should be on it.
• What is the unit of billing: message, conversation, session or resolution? This is where cost comparisons quietly break.
• Can it act on external systems, or only talk about them? That is the real line between a chatbot and an agent.

Being able to answer those six about a product tells you more than any category name, and it is the only reliable defence against a label that has been chosen for its marketing value. If you want the two most common pairwise comparisons in detail, see rule-based vs AI chatbot and chatbot vs conversational AI.

What picking the wrong type costs you later

Nobody budgets for the second-order costs, and they are the ones that decide whether the project is remembered as a success.

Pick a scripted type for an open-ended support surface and the cost lands as maintenance nobody scheduled. Somebody inherits the tree. Every price change and policy revision means hunting down the affected branches, and the branches nobody remembers stay wrong until a customer quotes one back at you. It never throws an error, so nothing tells you it's drifted. Meanwhile the person who built it moves teams, and what they knew about why a branch exists leaves with them.

Pick a generative type without grounding it and the cost is confidence, which takes far longer to rebuild than a bot does. One invented answer in front of the wrong person and the project is paused, and the conclusion drawn internally is rarely narrow. And the habit that forms around a bad tool outlasts the tool: once a team decides the bot is unreliable, they stop reading its transcripts, which removes the one feedback loop that would have fixed it. The bot then gets worse, which proves them right.

The quiet expense underneath both is the migration you pay for twice. Knowledge typed into a vendor's canvas has to be retyped to go anywhere else, and you'll discover that some of your best answers were never written down outside it. Knowledge that lives on your own pages moves for nothing, because the next tool simply reads it again. So which of these six would leave you with something usable on the day you stop paying for it?

Frequently asked questions

Sources

• Anthropic, "Building effective agents" (19 December 2024) - The distinction between workflows orchestrated through predefined code paths and agents that direct their own processes.
• Gartner press release, 25 June 2025 - The term "agent washing" and the finding that only around 130 of thousands of vendors claiming agentic AI were genuine.
• Zendesk, AI agents product documentation - Zendesk's own definition of its AI agents as autonomous systems that reason across multi-step requests, unlike traditional chatbots.
• Salesforce investor relations, 15 June 2026 - The agreement to acquire Fin (formerly Intercom) for approximately $3.6bn, Fin's average 76% end-to-end resolution rate, and its 30,000-plus customers.
• Fin pricing page (accessed 20 July 2026) - $0.99 per outcome with a 50-outcome monthly minimum, one outcome billed per conversation.
• AWS Marketplace vendor listings (accessed 20 July 2026) - Kore.ai per-session rates of $0.015 to $0.20 by module, the only public pricing available for several contextual platforms.