How Chatbots Really Work: Rules, Retrieval, LLMs, Tools, and Human Handoff

A chatbot conversation can feel effortless right up to the moment it fails. You ask where a parcel is. The bot repeats a generic delivery policy. You provide the order number. It asks for the order number again. After three loops, the small chat bubble that promised convenience has become a locked door between you and the answer.

The opposite experience is almost invisible. The chatbot recognizes that you want to track an order, captures the correct number, checks a current record, explains the result in one sentence, and offers a person if the case is unusual. The difference is not simply that one bot has more artificial intelligence. It is that one conversational system has a clearer task, better state, reliable tools, safer boundaries, and a planned way to recover.

This guide looks behind the chat bubble. It explains the major kinds of chatbot, follows one message through a real architecture, and shows why fluent language is only one part of a dependable conversation.

What is a chatbot?

A chatbot is software that exchanges messages with a person through text, voice, or another conversational channel. It interprets an input, decides what should happen next, and returns a response or action. That broad definition includes a fixed menu in a support widget, a voice flow that collects an account number, a knowledge assistant that searches documents, and a language-model system that can draft open-ended replies.

The conversation is the interface, not the underlying technology. Two chatbots can look identical while working in completely different ways. One follows a decision tree. Another matches an intent and calls a webhook. A third retrieves documents and asks a large language model to write an answer. The most useful systems often combine several approaches.

A lesson from ELIZA, sixty years later

In 1966, Joseph Weizenbaum published ELIZA, a program for natural-language conversation. Its well-known DOCTOR script used patterns and transformations to turn parts of a user's statement into a response. A sentence such as “I am unhappy” could be matched, rearranged, and reflected as a question. The exchange could feel attentive even though the program had little information about the person's life and no modern language model.

ELIZA remains relevant because people respond to language socially. A timely question, a sympathetic phrase, or a confident answer can create an impression of understanding that exceeds the machinery underneath. Modern models are far more capable, but the interface still invites the same mistake: judging what a system knows by how natural it sounds.

A professional chatbot should therefore earn trust through correct task completion, visible limits, and recoverable errors. Personality can improve an interaction. It cannot replace access to the right information or a safe process.

Three main chatbot architectures

Chatbots are easier to understand when we separate three architectural families. These are not strict generations where each new one makes the others obsolete. They are tools with different strengths.

1. Rules and conversation flows

A rule-based chatbot follows paths designed in advance. It may show buttons, match keywords, fill a form, or move between states when conditions are satisfied. The logic can be explicit: if the user wants to change a delivery date, collect the order number, check whether the parcel is eligible, show available dates, and ask for confirmation.

Rules are valuable when the process is narrow and the acceptable actions are known. They make compliance steps and destructive actions easier to control. Their weakness appears when people phrase requests in unexpected ways or move outside the designed path. A good rules system needs fallbacks, corrections, and escape routes, not only a perfect happy path.

2. Intent matching and retrieval

An intent-based system estimates what the user is trying to do, then extracts useful details called entities or parameters. “Track order 4821” may map to a track-order intent and an order-number parameter. Google Cloud's Dialogflow intent documentation describes this pattern as comparing an input with training phrases to find a match.

Retrieval adds a search layer. Instead of answering from a fixed response alone, the system finds relevant passages, policy entries, help articles, or records. A retrieval chatbot can quote a known answer directly or pass selected material to a generator. Its quality depends on what was indexed, how the query was formed, whether the source is current, and whether the system found the right passage.

3. Language models, tools, and hybrid systems

A large language model can interpret varied phrasing and produce natural responses across a much wider range of inputs. It can summarize, explain, translate, ask a clarifying question, or turn structured tool output into readable language. For a deeper explanation of token generation and model limits, see What Is AI, Really?.

The model still needs help with live facts and actions. It cannot know the current location of order 4821 unless the application supplies that information through context, retrieval, or a tool. It cannot safely issue a refund merely because it can write the sentence “Your refund is complete.” The application must connect the model to authorized services and verify the outcome.

This is why many modern chatbots are hybrids. Rules protect critical transitions. Retrieval supplies current knowledge. A language model handles flexible language. Tools read or change external state. Conventional code validates permissions and outputs. A human takes cases that require judgment or authority.

What happens during one chatbot turn

Follow a simple message: “Where is order 4821?” A real implementation may combine or rename the steps, but the underlying responsibilities remain recognizable.

1. Receive and normalize the input. The channel may provide typed text, transcribed speech, button selections, language, or session metadata.
2. Identify the goal. The system determines whether the request concerns tracking, cancellation, payment, another topic, or something unsupported.
3. Extract required details. In this case, the order number is 4821. If it is missing or ambiguous, the bot should ask rather than invent it.
4. Check conversation state. The system determines what it already knows, what it is permitted to retain, and which step is active.
5. Retrieve knowledge or call a tool. A tracking service returns the current status. The chatbot should not create that status from language patterns.
6. Compose and validate the response. The application turns the result into clear language, checks required fields, and avoids exposing internal or personal data.
7. Reply, recover, or hand off. A normal result returns to the user. An error, unsupported case, or request for a person follows a different route.

Google Cloud uses the term fulfillment for the part of a conversational turn that returns a static response, calls a webhook for dynamic information, sets parameters, or takes an action. Its Dialogflow fulfillment documentation makes an important distinction: understanding the request and fulfilling it are separate responsibilities.

Conversation state is not human memory

A chatbot needs enough state to avoid starting over on every turn. Session state might record that the current task is parcel tracking, the order number is 4821, and the user has already confirmed a postcode. Without state, “What about the second package?” has no usable reference.

That state is engineered data, not a human recollection. Some systems keep only the current session. Others store conversation history, summaries, preferences, or account information. A model may also receive only part of a long conversation because its context has a finite capacity or because the application deliberately limits what is sent.

Users should not assume a chatbot forgets when a window closes or remembers because it speaks as if it does. Retention, account linkage, training use, and deletion depend on the specific service. Before sharing sensitive information, inspect the service's privacy explanation and use the minimum information needed for the task.

How retrieval-augmented generation works

A language model's parameters are a poor place to keep a frequently changing returns policy. Retrieval-augmented generation, usually shortened to RAG, addresses this by searching an external collection for relevant material and placing selected passages into the model's context before it writes the answer.

The original Retrieval-Augmented Generation paper combined a pretrained generator with explicit non-parametric memory retrieved from an index. The broad pattern now appears in many knowledge assistants: search first, generate second.

A useful RAG pipeline has at least four opportunities to fail. The source collection may be incomplete. The document may be stale. Retrieval may select an irrelevant passage. The generator may misread or embellish what it received. Citations help only if they point to the exact supporting source and the user can inspect it.

RAG therefore improves access to current, inspectable knowledge but does not guarantee truth. It should be evaluated end to end: did the correct source enter the index, did the search find it, did the answer stay within the evidence, and did the citation support the claim?

Answers and actions require different levels of control

A chatbot that explains a refund policy is not the same as a chatbot that issues a refund. The second system can change external state. It may call an account service, calendar, payment system, messaging tool, or device control. That capability is sometimes described as agency, but the practical question is simpler: what can this application do beyond producing text?

A safe action path should keep important checks outside the model's prose:

• Authenticate the user and confirm that the account or resource belongs to them.
• Authorize the specific action rather than giving the chatbot broad access.
• Validate tool arguments, amounts, destinations, and allowed ranges with conventional code.
• Require explicit confirmation before irreversible or costly actions.
• Return a verified tool result instead of assuming an action succeeded.
• Record enough information to investigate failures without exposing unnecessary sensitive data.

The illustration shows a target architecture, not a promise about any particular chatbot. A language model can suggest which tool to call, but the surrounding application should decide whether the call is permitted. More autonomy increases the value of permission boundaries, rate limits, confirmation, monitoring, and human review.

Prompt injection: when content tries to become an instruction

A tool-using or retrieval chatbot may read text supplied by users, websites, emails, or documents. Some of that text can contain instructions aimed at the model, such as telling it to ignore prior rules, reveal hidden information, or call a tool in an unintended way. This is prompt injection.

The OWASP GenAI Security Project lists prompt injection as a leading risk for language-model applications. The core problem is that models process instructions and ordinary content through the same language channel. An untrusted document can look grammatically similar to an instruction from the application.

No prompt can replace system-level controls. Applications should treat retrieved and user-provided content as untrusted, restrict available tools, apply least privilege, validate tool calls, isolate sensitive operations, and ask for confirmation where consequences matter. The model should not receive a master key merely because the interface is conversational.

Why chatbots give wrong or frustrating answers

They misunderstand the request

Language is ambiguous. “Close my account” could mean log out, delete a profile, cancel a subscription, or close a financial account. A dependable chatbot recognizes when the cost of guessing is higher than the cost of one clarifying question.

They lack the required information

A model may know general shipping vocabulary but lack the user's order record. Retrieval may miss the relevant policy. A tool may be unavailable. The correct response is to state the limitation or use a fallback, not fill the gap with a plausible story.

They generate a confident falsehood

NIST calls confidently presented false or erroneous generative content confabulation. Its Generative AI Profile notes that this behavior can include fabricated logic or citations. Fluency makes these failures harder to notice, not less likely to matter.

They lose state or carry the wrong state forward

A session can forget a detail, confuse two orders, preserve an incorrect assumption, or apply information from one task to another. State should be visible enough to correct and scoped narrowly enough to avoid unintended mixing.

They have no graceful exit

The most painful loop is often a design failure. The bot has reached the edge of its ability but keeps rephrasing the same answer. A fallback should change the path: ask for one missing detail, show a supported option, create a case, or transfer the conversation.

Human handoff is part of the system, not an admission of defeat

Some requests are ambiguous, emotional, exceptional, or consequential. Others require authority the chatbot should not have. A human specialist can interpret context, negotiate an exception, take responsibility, or recognize that the documented process does not fit the case.

A handoff works only if context travels with it. The person should receive the user's goal, confirmed details, relevant tool results, and the reason for escalation. Forcing the user to repeat the entire conversation turns a technically successful transfer into a poor experience.

Dialogflow's live-agent handoff documentation treats handoff as an explicit transition. That design principle is broader than one platform: escalation should be a tested route with ownership, not a sentence the bot improvises when stuck.

How to judge whether a chatbot is good

A convincing demo is easy to stage. A dependable chatbot must handle ordinary variation and visible failure. Evaluation should start with the job the user came to complete.

• Task completion: did the user obtain the answer or complete the action correctly?
• Grounding: did factual claims follow the supplied source or verified tool result?
• Recovery: did missing information, no-match events, and tool failures lead to a useful next step?
• Safety: did authorization, confirmation, data handling, and tool boundaries hold under adversarial inputs?
• Handoff quality: did the conversation reach the right person with enough context?
• Language and accessibility: did the flow work across supported languages, typing styles, speech conditions, keyboard navigation, and assistive technology?
• User effort: how many turns, repetitions, and corrections were required to finish the task?

Test conversations should include more than the happy path. Use missing order numbers, two numbers in one message, spelling errors, unsupported requests, stale documents, tool timeouts, requests to change topics, direct requests for a person, and malicious instructions hidden in retrieved content. Google Cloud's agent design guidance similarly recommends iterative design and test cases rather than attempting to design every path at once.

How to use a chatbot without surrendering judgment

1. State the goal and the minimum relevant context. A precise request reduces unnecessary turns.
2. Do not paste passwords, authentication codes, payment credentials, private keys, or sensitive records unless the specific trusted service explicitly requires and protects that input.
3. Distinguish an explanation from a live result. Ask whether the answer came from a current record, a cited source, or general model knowledge.
4. Open citations and verify consequential claims. A source link can be irrelevant, outdated, or inconsistent with the answer.
5. Review every action before confirming it. Check the account, amount, destination, date, and whether the change can be reversed.
6. Ask for a person when the bot repeats itself, lacks authority, misunderstands a sensitive issue, or cannot show where the answer came from.

The mental model worth keeping

A chatbot is not a personality living inside a bubble. It is a conversational interface connected to some combination of flows, classifiers, search, language models, records, tools, policies, safety checks, and people. The response you see is the last step of that larger system.

The best question is not “Does this bot sound human?” Ask whether it understood the task, used the right evidence, respected its permissions, recovered honestly, and left you with control. Natural language makes the system easier to approach. Sound engineering makes it worth using.

Primary and technical references

• Joseph Weizenbaum, ELIZA: A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, 2020.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
• Google Cloud, Dialogflow CX documentation for intents, fulfillment, agent design, and human handoff.
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection.