Why AI gives different answers to the same question, and why it does not know tonight’s rates

A language model, a program that writes text by predicting what comes next, does not look up a stored answer: it composes a new one each time, so wording and sometimes facts vary. Its knowledge stops at a training date, and it cannot see your rooms or rates without a connection to your hotel system.

A receptionist asks the same question twice in one shift and gets two different sentences. Then she asks about tonight's availability and receives a confident answer that is simply wrong. Neither moment is a malfunction: both come from how these tools work. This article explains the mechanism in plain words, then turns it into practice: which answers need a template, which need a live connection, and how to notice when a tool changes under you.

Why does AI give different answers to the same question?#

Because the answer is written fresh on every request, not fetched from a stored page. The tool predicts the next small piece of text, chooses one plausible option, then predicts again from there.

A language model is a program that produces text by predicting what comes next, one small piece at a time. It holds no answer key to look up. At each step, several continuations are plausible; the tool picks one, and every later sentence is built on that choice. Two runs can therefore take different paths: a different opening line, a different order of points, occasionally a different conclusion.

Many assistants expose a randomness setting, often called temperature, that widens or narrows the range of choices. Lowering it makes answers more alike. It does not make them identical, and it does not make them correct.

A new chat usually starts blank. The tool remembers only what sits in the current conversation or what the surrounding software passes to it, so the same question asked tomorrow is a new composition, not a continuation. Small changes in phrasing pull a different shape of answer: "Do you have a room tonight" and "any availability this evening" are not the same prompt to the model.

None of this is a fault. It is the mechanism, and it is the reason a general assistant is good at drafting and unreliable as a record. For the deeper picture of how these models produce text, see why fluent text is not the same as a correct answer.

When is a different answer a problem, and when is it just wording?#

Different wording is normal and often useful. A different claim is the problem, and the test is simple: does the answer contain something a guest or an accountant could hold you to?

Separate paraphrase from drift. Paraphrase says the same thing in new words. Drift says a different thing: another number, another date, another policy, another promise. Treat as a claim anything with a number, a price, a date, a name, a cancellation term, a legal statement or a commitment to a guest. Those need a source outside the assistant.

Treat as wording a draft apology, a translation, a summary of a text you supplied, or three ways to phrase the same internal note. Variation there costs nothing.

A practical check: run the same question three times and compare the claims, not the sentences. If the facts move, stop using the tool for that fact and find the record it should have read. An answer that names its source, a document, a record or a timestamp, can be checked in seconds. An answer that names nothing cannot be checked at all.

Staff judgement matters more than tool settings here. The person who knows the hotel can spot a wrong rate in one glance, and that person should be the one who sends. For the related failure mode, see why AI assistants invent facts and how to catch them.

Why does AI not know tonight's rates?#

Because a model's knowledge ends at the date its training material was collected, and even a model trained this morning has never seen your property management system. Live figures require a live connection.

Training material is a snapshot. Anything that happened after it was gathered is outside the model's knowledge, and the tool will often answer anyway, in the same confident tone it uses for things it does know. Knowing about the world is not knowing your hotel: your room types, closed rooms, group blocks, minimum-stay rules and tonight's no-shows exist only in your own system.

A connection, in plain words, is a fixed channel between two systems. The assistant asks a defined question, your system answers with the record. Technically this is usually called an API. The channel has to return the exact thing asked: availability for a date range, a rate for a room type and occupancy, and the rules attached to it. A general answer with no date and no room type is not availability.

A hold is not a booking. An assistant that finds a room should place a short hold that expires and returns the room to inventory if nobody confirms, otherwise it quietly blocks sellable rooms. Without a connection, the only honest answer is that live availability cannot be seen. Any number produced in that state is invented, however specific it looks. For the middle path, supplying your own documents to the assistant, see answering from your own documents with retrieval.

Why does the same tool behave differently after an update?#

Because the model behind the interface is replaced from time to time, and the interface rarely announces it. Same login, same prompt, different behaviour.

Providers retrain and swap models to improve general performance. Your specific task is not what the update was measured on. An update can improve reasoning and still break something small you depended on: a format, a phrase, a step it used to take, the way it asked a clarifying question.

You usually do not choose which version you get, and a change notice is not guaranteed. Behaviour you discovered by accident is undocumented behaviour, not a feature. Write down the prompts that matter, with the answer you expect, so a change is visible instead of felt. Ten to twenty real questions from your own front desk is enough to start.

Keep the test set small and boring: real questions, expected answers, one person responsible for running it after any noticeable shift. Model choice itself is a separate decision: some tools let a provider pin a version, others do not, and that difference belongs in the contract conversation, not in a prompt. The trade-offs are covered in open and closed AI models and what a hotel can control.

In practice: how do you keep AI answers stable where it matters?#

Fix the wording where wording carries risk, require a source and a date on every fact, and retest after updates. Stability comes from the process around the tool, not from the tool.

Use templates with slots for anything with a consequence: booking confirmations, cancellation terms, complaint replies, payment reminders. The assistant fills the slots; the sentences are yours. Ask for the source and the time on every figure: a rate without a record and a reading time is a guess with a currency symbol in front of it.

Separate drafting from sending. The assistant drafts, a person sends, because a message already delivered to a guest cannot be undone. Keep a short retest list and a named owner, and after a visible change in behaviour, run the list before the shift starts relying on the tool again. Record the date of any behaviour change you notice, so a later complaint can be traced to a moment rather than to a vague feeling.

Review the list weekly rather than annually. Prompts drift, staff invent new shortcuts, and the questions guests ask change with the season. A fuller routine is in a weekly review checklist for a hotel AI assistant.

What should you ask a vendor about versions and change notices?#

Ask what runs the tool, when it changes, and how you will be told. No vendor can promise identical answers, so the useful promises are notice, traceability and a way to test.

The questions are short. Which model or version does the tool use today, and will you tell us in writing when that changes? Can we pin a version, and for how long? If not, what is the notice period before a swap? Where does the knowledge stop, and how is live data supplied: a connection to our system, an uploaded file, or nothing?

Then test the claims. When the assistant states a rate or availability, can it show the record it read and the time it read it? What happens to our templates and saved prompts when you update the underlying model? Is there a change log, and who do we contact when behaviour shifts overnight?

Be suspicious of any answer that promises the same output every time. The honest answer is about notice and checking, not sameness.

What to do next#

Pick the three questions your team asks an AI tool most often, ask each one three times, and note whether the claims move or only the words. That single exercise tells you which answers need a template, which need a live connection to your hotel system, and which are safe to leave as drafting. The rest follows from the same idea: the tool composes, so the hotel supplies the facts and the checks.