Chatbot Types: Rule-Based, NLP and LLM, and How to Pick One

"Chatbot" is not the name of one technology. A 3-screen menu that repeats the same options is a chatbot. So is a language model wired into every document a company owns. The distance between those two is the distance between a pocket calculator and an accounting system.

Most disappointing chatbot projects start with someone buying the first while picturing the second.

There are 3 working types, and each fails in its own way. Below: what separates them, what each one costs in setup and upkeep, and the 6 situations where the right decision is to skip the bot entirely.

Every chatbot runs the same 4-step loop

Every chatbot, whatever it is built on, runs the same 4 steps. It takes input, works out what was asked, goes to a source for the answer, and writes a reply. The differences between the types sit entirely in steps 2 and 3.

Step 1 belongs to the channel, not to you. On the web, voice input goes through the layer defined in the Web Speech API specification. In messaging, the platform sets the shape of the conversation before a single answer is written: the WhatsApp Cloud API closes the free-form reply window 24 hours after the customer's last message and requires pre-approved templates after that, and the Telegram Bot API does not let a bot open a conversation at all until the user starts one.

Step 4 adds the thing cheap builds skip: holding context. A bot that treats every message as a fresh question loses the thread the moment someone asks "what about the other one?" Those conversations break around the 3rd message.

Rule-based chatbots follow a script and never leave it

A rule-based chatbot walks the user down a decision tree that somebody drew in advance. Options are offered, a choice moves you to the next node, and anything outside the tree hits a wall marked "I did not understand that."

What you get in exchange is total predictability. You know every sentence the bot will ever say, because you wrote all of them. A 10 to 20 step flow goes live in 1 to 3 days.

These are not obsolete, and treating them as obsolete is how teams end up paying model costs to run a booking form. Appointment slots, tracking-number lookups and structured intake are still the places where a decision tree beats a language model outright. Nobody wants their reservation time generated.

NLP chatbots match sentences against a fixed list of intents

An NLP chatbot maps what the user typed onto a pre-defined intent. "Where is my parcel" and "when does my order arrive" land in the same box: order status. The user is off the menu and back to writing in their own words.

The bill arrives as maintenance. Somebody has to write the intent list and 15 to 30 example sentences for each intent, then keep feeding it as the business changes what it sells and how it words things. Bring a topic with no matching intent and the bot stalls exactly like a rule-based one. An NLP bot left unfed for 6 to 12 months has quietly turned into a rule-based bot with a larger bill.

LLM chatbots write the answer instead of retrieving it

An LLM chatbot is what people mean by "AI chatbot" now. Built on large language models, it needs no intent list at all: it reads language in general and composes the reply sentence by sentence. Done properly it is grounded in your own documents and takes its facts from there, using the retrieval pattern set out in the 2020 paper that introduced retrieval-augmented generation.

You buy that flexibility with predictability. An LLM bot not tied to a solid source produces wrong answers that sound completely right, and those cost far more than a bot saying "I did not understand." The customer leaves satisfied with bad information, and you find out months later.

Grounding is not the only thing to get right. The OWASP Top 10 for LLM Applications puts prompt injection and the leaking of sensitive information into output near the top of the list, and both apply the moment a bot can read your internal files.

Your own inbox picks the type faster than any vendor demo

Your own support inbox settles most of this before a tool is chosen. Open it, read the last 3 months, and the questions collapse into 20 to 25 headings. Those 20 to 25 headings are the entire job description of the bot, and how varied they are decides the type.

What the takeover then does to a support queue - cover outside working hours, lead capture, the handover rules - is the subject of our piece on AI-powered chatbots in customer service. This one is about choosing the engine underneath.

Four questions that decide the chatbot type

The chatbot type comes out of 4 answers. Answer all 4 clearly and the decision has already been made for you.

• What are people actually asking, and how varied are those questions?
• Where do the answers live, and is that source current?
• What does a wrong answer cost?
• Where should the bot stop and hand over to a person?

Low variety with settled answers: a rule-based or NLP build is enough and stands up in 3 days to 2 weeks. Unpredictable questions with the knowledge spread across internal documents: LLM-based is the better call, and the timeline belongs to your content rather than to the model. A tidy knowledge base puts you at 2 to 3 weeks. Starting from nothing puts you at 6 to 8 weeks, of which 4 to 5 go on content and only the remaining 3 to 4 on the model and the integrations.

Six situations where a chatbot is the wrong answer

In 6 situations a chatbot is the wrong answer, and the least-asked question in these projects is whether the bot should be built at all.

• The real problem is the process. If deliveries are genuinely late, a bot explaining that politely makes nobody happier. It routes the complaint to you faster.
• There is no tidy source of knowledge. If the answers live in people's heads, scattered folders and old email, there is nothing to feed.
• A mistake is expensive. Anything legally, medically or financially binding does not go out without a person signing off on it.
• Volume is low. Our threshold: under roughly 300 to 500 messages a month, and under about 25 genuinely repeating question headings, setup and upkeep do not pay for themselves.
• The conversation is emotional. A serious complaint, a cancellation, a crisis - the person wants a human, and the bot should not fight that.
• The expectation is that the job gets finished rather than answered. That is past the chatbot line entirely.

The 2nd item earns its own paragraph, because it is what we walk into most. Our position, stated plainly: most small and mid-sized businesses should spend the first half of the chatbot budget organising their own knowledge rather than on the bot. We know how that sounds coming from an agency. But a company that cannot put the answers to its 20 to 25 most common questions in one place does not fix that by installing a bot. It moves the problem in front of the customer.

Then there is the handover, which is the single setting that changes results most. After 2 failed attempts the bot must not go for a 3rd; it passes the conversation to a representative with the history attached. Most conversations that reach a 3rd attempt end with the tab closing instead. And when the transcript does not travel with the handover, you give back everything the bot earned, because the customer explains the problem for a 2nd time.

Where the chatbot line ends and an AI agent begins

Chatbot and AI agent get used interchangeably, and the difference between them is a scope decision more than a technical one. A chatbot is an information desk: it answers, and it stops there. An AI agent plans the steps toward a goal, uses the systems it needs and produces the outcome. A single return request handled by an agent touches 4 separate systems - it opens the record, books the collection, updates the stock line and writes back to the customer.

The plumbing an agent needs has started to standardise. The Model Context Protocol defines which tools a model is allowed to call, which resources it can read and where its permissions stop. A chatbot has no use for that layer; in an agent build it is most of the work. If that is where your requirement points, our guide to AI agents covers the ground.

Frequently Asked Questions

What are the main types of chatbot?

There are 3: rule-based, NLP-based and LLM-based. A rule-based bot follows a fixed flow tree, an NLP bot matches sentences to a defined list of intents, and an LLM bot reads free-form language and composes the answer from a source you connect it to.

What is the difference between an AI chatbot and a regular chatbot?

A rule-based chatbot repeats pre-written flows and cannot step outside them. An AI chatbot works on the meaning of the sentence, so it handles questions asked in the user's own words and writes the reply itself instead of selecting one from a list.

How long does it take to build a chatbot?

A rule-based flow of 10 to 20 steps is ready in 1 to 3 days. For an LLM-based build your content sets the timeline: 2 to 3 weeks if the documents are in order, and 6 to 8 weeks if the knowledge has to be gathered from scratch.

Do you need to write code to build a chatbot?

Simple builds are done with off-the-shelf tools and no technical background. Connecting the bot to your own data, your order system or your CRM turns it into an integration project, and that stage needs software work.

Will a chatbot replace human agents?

No. A chatbot takes the repeated questions with settled answers. Complex, exceptional and emotional cases stay with people. In a well-built setup the bot hands over after 2 failed attempts and passes the full conversation history to the representative.

Before the type, the tool or the budget, one question settles the project: is the knowledge you already have in a state that can feed a bot? To work through the type, the sources and the chatbot-or-agent boundary together, see what we build or ask for a quote.