← Back to Blog
·10 min read

What Is a Chatbot? How They Work, Types, and Why It Actually Matters

Have you ever typed a question into a website's chat widget and wondered whether something intelligent was actually reading it? Probably not a person. But the a

```html

```

What Is a Chatbot? How They Work, Types, and Why It Actually Matters

Have you ever typed a question into a website's chat widget and wondered whether something intelligent was actually reading it? Probably not a person. But the answer to what it was is more layered than most explainers admit. Chatbots range from brittle rule-following scripts to systems that can hold coherent conversations across hours, synthesize documents, and reason through ambiguity - and knowing the difference changes how you build with them, buy them, or trust them.

The Short Answer Gets Complicated Fast

A chatbot is software that simulates conversation through text or voice. That definition fits everything from a 1966 terminal program called ELIZA - which Joseph Weizenbaum built at MIT to mimic a Rogerian therapist, mostly by reflecting questions back - to GPT-4, Claude, and Gemini, which generate novel text by predicting what should come next across billions of parameters.

The gap between those two things is vast. And yet companies still deploy both, sometimes in the same product, sometimes without knowing which one they have.

Weizenbaum was disturbed by how readily people attributed understanding to ELIZA despite knowing it was a script. He spent years afterward writing about the dangers of anthropomorphizing machines. Fifty years later, that problem hasn't gone away. If anything, it's accelerated.

How a Chatbot Actually Processes Your Words

At the core of any chatbot is a pipeline that converts raw text into something a machine can act on.

Older rule-based systems work through pattern matching. You define intents - "check order status," "request refund" - and map user phrases to those intents using regular expressions or simple keyword lookups. When the user's input matches a pattern, the system returns a predetermined response. Fast, predictable, easy to audit. Also brittle: one unexpected phrasing breaks the whole interaction.

Machine learning chatbots changed the architecture. Instead of hand-coded rules, you train a classifier on labeled examples. The model learns statistical associations between phrases and intents. Natural language understanding (NLU) components - often built on frameworks like Rasa, Dialogflow, or earlier transformer models - parse entities, resolve coreference, and identify the most likely intent with a confidence score.

Then came transformers. Ashish Vaswani and colleagues at Google published "Attention Is All You Need" in 2017, and the field reorganized itself around that architecture almost immediately. The key insight was that attention mechanisms - ways of weighting the relevance of every word in a sequence against every other word - could capture long-range linguistic dependencies far better than recurrent networks. This is the foundation of BERT, GPT, Claude, and essentially every capable language model in production today.

What this means practically: modern large language models (LLMs) don't follow rules or classify intents from a fixed list. They generate responses token by token, sampling from a probability distribution over vocabulary. The "understanding" is distributed across billions of weights tuned during training on massive text corpora. Emily Bender and colleagues, in their 2021 "Stochastic Parrots" paper, raised the uncomfortable question of whether this constitutes meaning at all - or sophisticated pattern completion that mimics meaning. Worth sitting with.

The Four Types Worth Knowing

There's a lot of taxonomic noise online about chatbot types. Most of it creates more categories than the distinctions warrant. Four types do real conceptual work.

Rule-based chatbots are decision trees with a chat interface. Every response is authored by a human. They excel in constrained domains - IT help desks with known issue categories, FAQ systems, booking flows - where the space of valid inputs is small and predictability matters more than flexibility. Implementation is fast, often days. Failure modes are equally predictable: a user phrase outside the pattern library produces a generic fallback, and the experience degrades visibly.

Retrieval-augmented chatbots don't generate responses from scratch. They retrieve relevant content from a knowledge base and surface or lightly synthesize it. Think of a customer support bot backed by a documentation corpus. When you ask something, it searches, finds the three most relevant chunks, and returns them - sometimes verbatim, sometimes summarized. Accuracy depends heavily on the quality of the knowledge base and the retrieval mechanism. Hallucination risk is lower than pure generation because the outputs are grounded in real documents. (Though grounding doesn't eliminate fabrication, it constrains it.)

Generative AI chatbots are the LLM-powered systems most people mean now when they say "chatbot." They produce novel responses from parametric knowledge - what was learned during training - plus any context provided in the conversation window. Claude, ChatGPT, Gemini. The capabilities are remarkable. The failure modes include confident fabrication, sensitivity to prompt phrasing, and behavior that shifts unpredictably under distribution shifts.

Hybrid systems combine retrieval and generation, or layer rule-based guardrails around generative cores. Most serious enterprise deployments end up here by necessity - you want the fluency and range of an LLM, but you also want it to stay within your data, your policies, your tone. The architecture gets complex fast. The deployment surface for errors expands with it.

From ELIZA to Transformers: A Compressed History

1966. ELIZA. Pattern matching, no memory, no model of the world.

1995 brought ALICE (Artificial Linguistic Internet Computer Entity), built by Richard Wallace using AIML - a scripting language for pattern-response pairs. Technically more sophisticated than ELIZA, still fundamentally a lookup system. ALICE won the Loebner Prize three times. The Loebner Prize, in retrospect, measured how well you could fool judges in short exchanges, not how useful the systems actually were.

The 2010s changed everything. Statistical methods gave way to neural approaches. Sequence-to-sequence models built on LSTMs showed that machines could learn to map inputs to outputs in surprisingly flexible ways when trained on enough data. Siri (2011), Google Now (2012), Cortana (2014) - consumer voice assistants hit mainstream before the architecture underlying them was remotely ready for what users expected.

The transformer era began in earnest around 2018-2019. GPT-2 raised alarm at OpenAI because it generated coherent paragraphs at a quality that felt different. GPT-3 in 2020 demonstrated few-shot learning: give the model a couple of examples in the prompt, and it generalizes. ChatGPT in late 2022 put a conversational interface on top of that capability and created the fastest consumer product adoption in history - 100 million users in two months.

Where we are now is messier than the trajectory suggests. Capability is unevenly distributed. Many deployed "AI chatbots" are still thin wrappers around rule engines with a generative component grafted on. The glossy press releases don't distinguish them from frontier model deployments. You have to ask.

Measuring Whether a Chatbot Is Actually Working

Most chatbot projects fail quietly. The system launches, ticket volume doesn't drop as projected, users route around it to reach a human agent, and the product gets deprioritized. No one writes the postmortem.

The metrics that matter are not the ones most vendors emphasize.

Containment rate measures how often the chatbot resolves a conversation without human escalation. A number in isolation means nothing - 80% containment sounds good until you learn the other 20% are your most valuable customers with complex problems, and the 80% are people who gave up rather than getting help. Pair containment with user satisfaction scores to see which.

Task completion rate is more honest. Did the user accomplish what they came to do? Measuring this requires you to define tasks and track outcomes, which is harder than it sounds, which is why most teams don't do it.

Deflection cost per conversation matters for the business case but tends to crowd out quality signals. Cheap deflection of unhappy users is a worse outcome than a smaller volume of genuinely resolved conversations. The ROI math looks better in the first case. The customer relationship looks worse.

Dan Jurafsky and James Martin's textbook on speech and language processing dedicates significant attention to evaluation frameworks - perplexity for language models, intent accuracy and entity F1 for NLU components, BLEU scores for generation. These are useful as engineering benchmarks. They don't tell you whether your chatbot is making users' lives better.

Security, Bias, and the Parts Nobody Likes Talking About

There's a category of chatbot failure that doesn't show up in containment rate dashboards.

Prompt injection attacks - where a malicious user crafts inputs that override the system's instructions - are a genuine threat in any deployment where the chatbot takes actions or accesses systems on behalf of users. "Ignore all previous instructions and..." is the classic formulation, and while frontier models have gotten better at resisting it, the attack surface hasn't disappeared.

Bias is structural. Models trained on internet text inherit the statistical regularities of that text, including its demographic skews, its cultural assumptions, its blind spots. A customer service bot trained predominantly on English-language data will perform worse for non-native speakers. A mental health chatbot trained on clinical notes from one patient population may not generalize. These aren't hypothetical edge cases. They're documented failure modes that require active intervention - curated training data, adversarial testing, ongoing monitoring - not one-time fixes at launch.

The data handling question is often underspecified in enterprise evaluations. What happens to the conversations users have with your chatbot? Where are they stored? Who trains on them? Most SaaS chatbot platforms have answers in their terms of service. Fewer buyers read those terms carefully before signing.