It’s nine in the evening. A potential guest is browsing rooms on a hotel website, opens the chat, and types a six-word question: “Can I bring my dog to the room?”
A few seconds later, they get a correct answer, including the allowed dog sizes and any extra fee. From the outside, the process looks simple: the user asks, artificial intelligence answers. Two steps, no mystery.
But between that question and that answer, a well-designed business AI assistant does quite a lot. And the part handled by the language model — what almost everyone simply calls “the AI” — is only one piece of it.
This article walks through that process step by step, without assuming technical knowledge. We’ll use the dog question as our thread, and where useful we’ll pair it with examples from e-commerce, professional services, and customer care.
An AI chatbot is not simply “question → ChatGPT → answer”
The most common way people picture an AI assistant is as a straight line: a question comes in, the model generates an answer. It’s an understandable simplification, because that’s exactly what we see when we use a general-purpose assistant like ChatGPT: we type something and get a piece of text back.
An assistant installed on a company website, however, works in very different conditions. It doesn’t need to produce a generally plausible text: it needs to answer about that specific company, with its policies, prices, opening hours, exceptions, and edge cases. And it has to do that for a customer who may later show up at the hotel with a dog on a leash.
To do that, a business assistant typically has to understand what the user is asking, take into account what has already been said in the conversation, find the relevant company information, tell what it knows from what it doesn’t know, build a coherent reply, follow the rules the company has set, in some cases interact with external systems, and recognize when it’s time to involve a person.
That’s a lot. In the next sections, we’ll go through it one step at a time, in the order it usually happens.
First step: understanding what the user is asking
People don’t write in chat the way they search, and even less the way website pages are written. The same request can take very different forms:
- “How much is shipping?”
- “Do you charge for delivery?”
- “Is shipping included?”
Three phrasings, one topic. A system that simply looked for the words in the question inside a text archive would already struggle here: in the second sentence the word “shipping” doesn’t appear, and in the third the structure changes completely. Yet the user wants to know the same thing.
Understanding the request therefore means getting back to the intent, that is, the person’s real goal, beyond the words they used. This is the first point where a modern assistant clearly differs from old rule-based chatbots, the ones that recognized a keyword and returned a canned reply.
The same applies to our starting question. “Can I bring my dog to the room?”, “Are you pet-friendly?” and “Do you accept small pets?” are different ways of asking for the same information, even though the third already includes a detail that could change the answer.
Context: a question does not always live on its own
In most cases, the question doesn’t arrive in isolation, but inside a conversation. Let’s imagine this exchange:
User: “Do you accept pets?”
Assistant: “Yes, small and medium-sized dogs are allowed.”
User: “And how much does it cost?”
On its own, the last question means almost nothing. How much does what cost? The room, breakfast, parking? Inside the conversation, though, it’s perfectly clear: the user is asking whether there’s an extra fee for the pet.
An assistant that can hold a conversation keeps that thread. A system that treats every message as if it were the first forces the user to repeat the full context every time, and the experience falls apart in just a few turns.
Context, however, should not be used blindly. If after ten messages about pets the user asks, “And what time is breakfast?”, the topic has changed: dragging the previous subject along would lead to off-target answers. In a well-designed system, context management also means knowing when an earlier detail is no longer relevant, and not letting a long conversation contaminate later replies.
The Knowledge Base: the information the company makes available
At this point, the assistant has understood what it’s being asked. Now it has to find the answer. And this is where the component that matters most for reliability comes into play: the Knowledge Base.
The Knowledge Base is the set of approved company sources from which the assistant can retrieve information. Depending on the business, it may include website pages, FAQs, documents and PDFs, price lists, internal procedures, product sheets, terms and conditions, or information entered directly by the company in question-and-answer form.
In our hotel example, the Knowledge Base might contain a line like this:
“Small and medium-sized dogs are allowed, with an extra charge of €15 per night.”
This sentence is the factual basis for the answer. It’s not a stylistic preference: it’s the data the company stands behind, and it can update whenever the fee changes.
There’s a principle worth isolating here, because it’s the one most often misunderstood: the AI model does not know your company’s real information. A language model has been trained on huge amounts of generic text and has learned how language works and what information in the world usually looks like. It does not know your price list, your opening hours, or your pet policy. If you ask it to answer without sources, it will tend to produce something plausible — and plausible does not mean correct.
Company-specific information must therefore come from controlled sources that the company can update. That’s also why the quality of the Knowledge Base has such a big impact on the final result: an assistant cannot be more accurate than the information it has been given.
Retrieval: finding the right information among everything available
Having the information somewhere is not enough. You have to pull it out at the right moment.
A company Knowledge Base can contain hundreds or thousands of items: a product catalog, years of FAQs, dozens of documents. It would make no sense — and would not even be technically practical — to feed all of that material into the model for every question. The system has to select the few pieces of information that are truly relevant to the current request.
This operation is called retrieval. It works a bit like a good colleague in the admin office: when you ask whether dogs are allowed, they don’t hand you the entire procedures binder, they go straight to the right page. The difference is that the system doesn’t just look for exact words, but for information that matches the same meaning — which is why “are you pet-friendly?” can still lead to the line about the pet policy.
The combination of this retrieval phase and the later generation of the reply is commonly referred to as RAG, Retrieval-Augmented Generation: generating a response with the help of retrieved information. Put less technically: first the system looks in the company sources, then it writes the answer based on what it found.
The practical point is this: if an information item is in the Knowledge Base but the system cannot retrieve it, it is as good as invisible to the user. Many cases where an assistant “doesn’t know how to answer” are not caused by the model itself, but by a retrieval problem or by sources written in a confusing way.
Only now does the language model come into play
We’ve reached the part everyone imagines at the start of the process, even though it actually comes near the end.
The language model — the LLM, or Large Language Model — typically receives a set of elements: the user’s question, the useful part of the previous conversation, the relevant information retrieved from the Knowledge Base, and the instructions that define the assistant’s behavior (who it represents, what tone it uses, what it can and cannot do).
With that material, the model builds a natural-language reply: it rewrites the pet policy in a sentence that fits the context, connects it to the specific question, writes it in the user’s language, and adds a clarification if needed.
The difference is worth keeping in focus. The model’s job is not to “know the answer,” but to interpret the request and phrase a response using the information and rules it has been given. The company knowledge comes from the retrieval system; the model contributes language understanding and the ability to build a coherent text. Keeping those two roles separate makes it much easier to understand where problems come from when something doesn’t work.
One important note: not every implementation organizes the steps in the same order, and some architectures involve several back-and-forth passes between the model and the other components before the final answer is produced. The sequence described here is a logical and functional representation, not the only possible one.
Rules and guardrails: knowing something does not mean you can say or do anything
Let’s go back to the hotel, with a twist. The Knowledge Base says small and medium-sized dogs are allowed. The user writes:
“I have a 150-pound Saint Bernard. Can I bring him anyway?”
The available information does not cover this case. It does not say that large dogs are absolutely forbidden, and it does not say the property makes exceptions. It only says what is normally allowed.
If an assistant were to invent a policy here — one way or the other — it would create a real problem: a guest arriving with a dog that is too large, expecting approval nobody gave, or a booking lost because something was denied that the hotel might have accepted.
That’s why a business system does more than generate text: it applies rules that decide, for example, when to answer and when to say the information is not available, when to ask for clarification instead of moving ahead, which topics to avoid, which decisions not to make on its own, and when to suggest contacting a person.
This set of limits and expected behaviors is what is called guardrails: literally the barriers that keep a vehicle in its lane. They are not there to make the assistant timid, but to make sure it behaves predictably even in cases nobody had anticipated. It’s a broad enough topic to deserve a separate article.
The result does not have to be an answer
There’s an implicit idea in many chatbot evaluations: that their goal is to answer as many questions as possible. That’s misleading. The goal is to handle the request correctly, and sometimes handling it correctly means not giving an answer.
A well-designed assistant typically has several possible outcomes.
Answer, when the available information is sufficient. That’s the case with the medium-sized dog question: the policy exists, and the answer can be given precisely, extra fee included.
Ask a question, when the request is ambiguous. A “I’d like to cancel” message on a service website is missing essential information: which contract, from when, with what notice period. Asking for clarification is more useful than guessing.
Collect information, when it’s needed to move forward. A user asking for a quote on a B2B website is opening a sales process: the assistant can collect industry, need, and contact details, then pass everything on to the right person. That’s the classic lead qualification case.
Take an action, when it is connected to external tools: check an order status, verify an appointment slot, open a support request.
Hand off to a person, when the situation calls for it. A dispute over a charge, a complaint, a delicate request, or simply a user who is getting frustrated are all cases where pushing automation further makes things worse. A good handoff carries the conversation so far, so the user does not have to start over.
When the AI assistant can also take action
So far we’ve talked about static information: text the company prepared in advance. Some questions, however, involve data that changes constantly and lives inside other systems.
“Is the double room available from the 12th to the 14th?” is not something a website page can answer. The answer exists, but it lives in the booking system. The same goes for shipment status, appointment availability, or product stock.
When an assistant is connected to external tools and services, it can query those systems and use the result: retrieve an order status, check appointment availability, open a ticket, save a lead in the CRM, or start a company-defined process. It’s worth stressing that these are explicit configurations: without a connection to the booking system, no assistant can know the real room availability, no matter how well the Knowledge Base is written.
The difference between generating text and taking action is substantial. An inaccurate reply can be corrected; an appointment booked by mistake, a duplicated ticket, or data entered into the wrong system has real consequences. That’s why actions require tighter controls than answers, and one rule should always apply: the assistant should not tell the user that something has been completed unless it has received confirmation from the system involved. If the request fails, the user needs to know, and they need a way forward.
Why two chatbots using the same AI model can be very different
Put two assistants side by side on the websites of two companies in the same industry. They use the exact same language model. One works well: it answers accurately, admits its limits, and hands the conversation to a person when needed. The other gives generic replies, gets prices wrong, and sometimes makes things up.
The difference is not in the AI. It’s in everything built around it: the quality and organization of the Knowledge Base, the ability to retrieve the right information at the right time, the management of conversational context, the instructions that define behavior, the rules and guardrails, the way missing information is handled, the integrations with company systems, the fallback procedures when something goes wrong, and more broadly the design of the experience.
“Which AI model does this chatbot use?” is still a fair question. Models are not all the same, and their capabilities matter: a stronger model understands complex requests better, follows instructions better, and handles nuance better. But it’s only part of the picture. Alongside it, it’s worth asking where the information comes from, how it is updated, what happens when there is no answer, and how the conversation is handed over to a person.
A complete example: following a question from start to finish
Let’s put the whole path back together using the question we started with: “Can I bring my dog to the room?”
- The assistant interprets the request and recognizes the topic: pet policy.
- It considers the conversation context, to see whether the user was already talking about a room or specific dates.
- The retrieval system searches the Knowledge Base for relevant information.
- It finds the policy: small and medium-sized dogs are allowed, with an extra charge of €15 per night.
- It passes the question, the useful context, the retrieved information, and the assistant behavior instructions to the model.
- The model formulates a clear reply that matches the source.
- The rules check that the answer stays within the expected boundaries.
- If useful, the assistant suggests a next step: check availability, contact the property, or receive the full conditions.
Now let’s change the question: “I have a 150-pound Saint Bernard. Can I bring him anyway?”
The first steps are the same. The assistant recognizes the same topic and retrieves the same policy. But the path ends differently, because the available information does not cover this case: it does not authorize the exception, and it does not rule it out.
The correct handling here is to state clearly what is known — that the standard policy allows small and medium-sized dogs — explain that larger dogs require a decision from the property, and offer a direct contact. The user doesn’t get a yes, but they do get something more useful: a clear picture and a real way to solve the issue. And the hotel doesn’t end up with a Saint Bernard at reception without warning.
From a simplification to a more realistic picture
Let’s go back to the diagram we started with. The simplified (and completely wrong) version of how an AI chatbot for websites works:
Question → AI → Answer
A representation that is closer to how a business assistant actually works:
Question → Intent → Context → Knowledge Base → Retrieval → AI Model → Rules → Answer / Question / Action / Human contact
Not every system follows exactly this architecture or this exact order: there are different implementations, and some organize the steps differently. But the diagram makes one thing obvious that the simplistic version hides completely: a business AI assistant is much more than access to a language model.
It’s also why IKIbrain does not simply put an AI model inside a chat widget. The assistant is built around the company’s Knowledge Base, conversation management, the instructions that define its behavior, the rules that set limits and fallback cases, and any integrations with existing systems. The goal is not to have a chatbot that answers everything, but an assistant that handles the requests of that company’s visitors correctly — including the cases where the right answer is to hand the conversation over to a human operator.