AI Basics

How AI chatbots answer questions (they do not answer, they continue)

Press Enter and it feels like a conversation. Under the surface the model is doing one job. Guess the next token. Then the next. Then the next. Knowing that changes how you use it, govern it, and trust it.

By Zakir Hoosen, Director, Fuzzelogic Solutions. Board-level guidance in plain English.

You type a question. You press Enter. Text appears that looks like an answer. It is easy to believe something inside the model “heard” you, “understood” the ask, and then “decided” to reply.

That is not what is happening.

What happens is closer to this. Your words are turned into a long block of context. That block is fed into a language model. The model predicts the most likely next piece of text. Then it predicts the next. Then the next. Your chat app collects those pieces and shows them as a reply. Something else, usually a stop token or a hard limit, decides when to stop.

If you sit on a board, buy AI tools, or ask staff to use ChatGPT-style systems at work, this is not trivia. It is the difference between treating the output as a colleague and treating it as a high-speed autocomplete with a chat costume.

This guide walks through that process in plain English. No code. No maths you need to do by hand. Just the mechanics that matter for judgement, risk, and use.

The wrong mental model

Most people carry a mental model that looks like this.

1. The user asks a question.
2. The model understands the question.
3. The model thinks about the answer.
4. The model writes the answer.
5. The model decides it is finished.

That sequence matches how humans talk. It does not match how large language models generate text.

A better mental model is this.

1. The app builds a prompt from your message, prior turns, and system instructions.
2. That prompt becomes the start of a document.
3. The model extends the document one token at a time.
4. The extension is trained to look like a helpful assistant reply.
5. Generation stops when a stop signal appears or the app cuts it off.

The product experience is conversation. The engine is continuation.

That sounds pedantic until something goes wrong. Then it becomes useful. Hallucinations, confident wrong answers, and “it ignored my instruction halfway through” are easier to explain once you stop expecting a person in the box.

What a token is

A token is a chunk of text the model reads and writes. Sometimes a token is a whole word. Sometimes it is part of a word. Sometimes it is punctuation or a space.

You do not need the exact splitting rules. You need one idea. The model does not “think in sentences.” It advances text in small pieces. Each piece is chosen from a huge list of possible next pieces, using probabilities learned during training.

So when people say “next-word prediction,” they are close enough for board-level understanding. Strictly it is next-token prediction. The point is the same. The system is always answering one tiny question: given everything so far, what comes next?

What happens when you press Enter

Pressing Enter does not “send a question to an answering brain.” It triggers your app to assemble context.

That context usually includes some mix of:

• a system message (rules, tone, role, safety policy)
• earlier turns in the chat
• your latest message
• markers that say whose turn it is (user vs assistant)
• sometimes tool results, retrieved documents, or form data your company wired in

All of that is flattened into one sequence the model can read. Then generation starts from the point where the assistant is expected to speak.

This is why the same question can get different replies in different products. The visible question may match. The invisible wrapper around it may not. One product may include a long policy. Another may include your company handbook. Another may include nothing but your short prompt. The model continues whatever document it was given.

For business use, that means the product design around the model matters as much as the model name on the invoice.

It is not answering. It is continuing

Here is the core claim, stated plainly.

The model is not separately “answering the question.” It is continuing the text.

If the text so far looks like a chat where a user asked something and an assistant is about to reply, the continuation will usually look like an answer. That is because the model was trained on huge amounts of text where that pattern appears, and then further trained or tuned so that assistant-style replies are preferred in that setting.

If you start a sentence with “Once upon a time,” the continuation tends to sound like a story. If you start with a Python function header, the continuation tends to look like code. If you start with a customer complaint and an “Assistant:” marker, the continuation tends to look like customer service.

Same machinery. Different opening. Different continuation.

So your intuition was right. The click does not flip the model into a special “answer mode” that is different in kind from writing the next word of a story. The chat product frames the context so that the next words are likely to be a reply.

Why it feels so much like understanding

If it is only predicting tokens, why does it feel intelligent?

Because language is packed with structure. To predict the next token well on hard text, a model has to track grammar, facts that often co-occur, common reasoning patterns, and the style of the conversation so far. From the outside, that tracking looks like understanding.

From the inside of the product, there is still no separate “belief store” you can inspect like a human memory. There is a forward pass over the current context and a distribution over what token should come next.

That distinction matters when the model:

• invents a citation that looks real
• mixes two similar policies into one wrong rule
• follows the shape of a good answer while getting a number wrong
• agrees with a false premise you accidentally planted in the question

Those behaviours are awkward if you think the system “knows.” They are expected if you think the system is completing a plausible document.

The research framing has been consistent for years. Chat interfaces came later. The underlying job stayed next-token prediction.

Temperature, sampling, and why the same question can get two replies

If the model only predicted the single most likely next token every time, many chats would look more repetitive. Products often sample from the probability distribution instead. Settings with names like temperature change how adventurous that sampling is.

At low temperature, the model sticks closer to high-probability tokens. Replies look steadier and more repeatable. At higher temperature, lower-probability tokens get more chances. Replies look more varied, and sometimes more inventive in the bad sense.

Boards do not need to tune temperature. They do need to know that “the AI said X” is not always a fixed property of the model. It can be a property of the model plus the sampling settings plus the prompt wrapper plus the random draw.

If your organisation uses AI for anything that must be reproducible, ask whether the vendor can run at deterministic or near-deterministic settings for that workflow. If they cannot explain that, they do not understand their own product well enough to sell it into a governed process.

How the model “knows” when to stop

This is the second half of the question people get wrong.

The model does not feel finished. It does not check a box labelled “I have answered enough.” Stopping is almost always one of these:

1. A stop token or end-of-turn token

Chat models are trained with special tokens that mark the end of an assistant turn. When the model predicts that token, the app stops generating and shows everything before it as the reply.

That is the closest thing to “the model decided to stop.” Even then, it is still token prediction. The stop token is just another item on the list of possible next pieces. Training made that token likely when a reply looks complete.

2. A hard limit set by the app

Every serious product has a maximum number of tokens it will generate for one reply. If the model has not emitted a stop token by then, the app cuts the stream. You have seen this as a reply that ends mid-sentence or feels truncated.

3. Stop strings and safety filters

Some systems stop if certain phrases appear, if a policy classifier fires, or if a tool call boundary is reached. Those are product rules sitting on top of generation.

4. User or client abort

You hit stop. The network drops. The browser tab closes. Generation ends for reasons that have nothing to do with the model’s “intent.”

So the honest answer to “how does it know when to stop?” is: it predicts a stop marker, or the software around it forces a stop. There is no inner sense of completion.

Why chat models look like they take turns

Turn-taking is taught by format.

Training and fine-tuning expose the model to conversations laid out with roles. User. Assistant. Sometimes Tool. The model learns that after a user block, assistant-looking text is what usually comes next. After an assistant stop marker, it should not keep talking unless a new user block appears.

Your Enter key is the product saying, “append this user message, then generate assistant tokens until stop.”

That is also why jailbreaks and prompt injection exist as risk classes. If an attacker can smuggle instructions into the context, those instructions become part of the document the model is continuing. The model does not have a separate moral referee that sits outside the text. Guardrails are extra systems and training pressures, not a person saying no.

For company deployments, that is why untrusted text (emails, web pages, uploaded PDFs) must be treated as hostile input when it is pasted into a prompt. It is not “just data.” It is future context the model may continue as if it were instruction.

Retrieval, tools, and agents do not change the core story

Many business systems wrap the model with extras:

• search over your documents
• database lookups
• calculators
• ticket systems
• multi-step “agent” loops

Those wrappers matter. They can make outputs more grounded. They can also create new failure modes.

They do not replace next-token prediction. They change what text is sitting in the context when prediction runs.

A retrieval system finds passages and pastes them into the prompt. The model then continues a document that includes those passages. An agent loop may run many generate-stop-tool-generate cycles. Each generation step is still next-token prediction.

If a vendor says their agent “reasons” in a way that sounds like a separate mind, ask them to show the traces. In most production stacks you will see prompts, tool calls, and more prompts. Useful. Powerful. Still continuation under the hood.

What this means for trust

If the system is continuing text, trust has to be earned at the workflow level, not assumed from fluent English.

Fluent English is cheap for these models. That is the product. Correctness is expensive. Correctness needs:

• the right context in the prompt
• limits on what the model is allowed to decide
• human review where the cost of error is high
• evaluation on your real cases, not demo scripts
• logging so you can see what context produced a bad reply

A board that understands continuation will ask better questions of vendors.

Not: “Does it understand our business?”

Better: “What context do you put around each request, how do you stop generation, how do you evaluate accuracy on our documents, and who is accountable when fluent text is wrong?”

What this means for staff using AI day to day

Staff do not need a research paper. They need a few working rules.

1. Treat the reply as a draft until checked, especially for numbers, legal wording, medical advice, and anything that will be sent to a client as fact.
2. Put the constraints in the prompt. The model continues the document you give it. If “use only this policy” is not in the context, do not expect it to obey a policy sitting in someone’s head.
3. Short, clear asks beat vague ones. Vague context produces vague continuation.
4. If the reply must follow a template, provide the template. Continuation loves patterns.
5. When something is wrong, ask what was in the context. Often the bug is missing files, stale chat history, or a bad system prompt, not “the model is stupid.”

What this means for Isle of Man boards and regulated firms

On the Island, AI is already in inboxes, helpdesks, coding tools, and draft workflows. The JFSC’s direction of travel on AI governance is clear enough that “we thought it was just a chatbot” is a weak answer after an incident.

If a customer-facing assistant invents a fee, misstates a cooling-off right, or fabricates a source, the legal and reputational problem is yours. The fact that the model was “only predicting tokens” does not shrink the accountability. It clarifies the control problem.

Controls that match the real mechanism look like this:

• approved use cases, not free-for-all staff accounts with client data
• prompts and system instructions under change control
• retention rules for chat logs
• human sign-off for regulated advice
• red-team tests for prompt injection on any tool that reads external text
• a named owner for each assistant

You are not governing a person. You are governing a text-continuation service plugged into your processes.

A simple walkthrough you can use in a meeting

Use this script when someone oversells “the AI answers questions.”

“When the user presses Enter, the application builds a context pack. The model predicts the next token repeatedly. The reply is that stream of tokens. It stops when a stop token appears or the app hits a limit. It does not have a separate answering mind. If we need reliability, we control the context, the limits, the evaluation, and the human checks.”

If the room can repeat that back, you have shared vocabulary. Shared vocabulary is the start of governance.

Common objections

“But it followed my complex instructions. That must be understanding.”

Following instructions is what you would expect from a model trained and tuned to continue instruction-shaped text with compliant-looking completions. It can still fail on edge cases, long constraints, or conflicting rules. Instruction following is a behaviour, not proof of a mind.

“But it apologised and corrected itself.”

It continued a new turn where the context included your correction. The “apology” is a likely textual pattern in assistant data. Useful. Not remorse.

“But multimodal models see images now.”

They map images into the same kind of next-token process, or a close cousin of it. The chat still ends up as generated tokens. The core caution stands.

“Surely the newest models are different.”

Newer models are often better at long context, tool use, and hard benchmarks. Many still generate by predicting tokens. Architecture details change. The product lesson for boards stays stable: fluent continuation is not the same as verified truth.

Practical checklist before you approve a chatbot project

Before budget lands on an “AI assistant,” ask for written answers to these.

1. What exact context is sent on each request?
2. What is retained from prior turns, and for how long?
3. How does generation stop?
4. What is the maximum reply length?
5. Which decisions are forbidden to the model?
6. How do you test accuracy on our documents?
7. What happens on low-confidence or contradictory context?
8. Who can change the system prompt?
9. Where do logs live, and who can read them?
10. Who is accountable when the fluent text is wrong?

If those answers are vague, the project is not ready. The demo can still look excellent. Demos are continuations under ideal context.

The honest summary

Your reading of the mechanism was right.

It is not that the model “answers the question” as a separate act. When the user clicks Enter, the context goes in, and the model continues by predicting the next token again and again. It stops because a stop token becomes likely, or because the application forces a stop.

That fact does not make the tools useless. It makes them usable with clear eyes. Used with retrieval, process limits, and human review, next-token systems can draft, classify, summarise, and speed up real work. Used as oracles, they create fluent risk.

You already have AI in your business. You just do not know where. The question is whether you understand what it is doing when staff press Enter. If the honest answer is no, start there before you scale chatbots into client work.

Start with the assessment. Two to four weeks, fixed price, and you own the verdict and the roadmap whether or not we build any of it. When you are ready to talk AI, call Fuzzelogic Solutions and ask for Zak. www.FuzzelogicSolutions.com | info@FuzzelogicSolutions.com | +44 (0)1624 618950

For a board-level primer on what AI is and is not, read What is AI? A plain English guide for boards. For why demos fail to become systems, read Why 95% of AI pilots return nothing. The full library is on our index. Our site explains how Fuzzelogic approaches AI for business.