A customer types an order number into a support chat, gets a clear answer, then asks, "So when will it arrive?" The reply: "Which order are you asking about?" Nothing was forgotten in the human sense. The system simply never carried the number forward. Understanding why that happens, and how to stop it, comes down to two ideas working together: the context window and state.
What the Context Window Really Holds
Every reply is generated from a single bundle of text assembled at that moment. Nothing is stored in the model's head between messages. The bundle usually contains the system prompt with persona and rules, the visible conversation so far, any documents or search results the application injected, and the newest message from the user.
That bundle has a size limit, measured in tokens, which run roughly three-quarters of an English word each. When the limit approaches, something has to go, and the oldest turns usually go first. This is why a chatbot can stay sharp for the first twenty exchanges and then quietly lose the thread around exchange forty.
Position matters as much as volume. Material buried in the middle of a long bundle tends to receive less attention than the opening and the end. If a rule is critical, such as "always ask for the account number before quoting a delivery date," put it in the system prompt and repeat it close to the user's latest turn.
Four Kinds of Memory a Chatbot Can Use
"Memory" is an umbrella term for several different mechanisms, each with its own cost and failure mode:
- Working memory. The context window itself. Exact, fast, and temporary.
- Rolling summary. Every few turns, the application rewrites the history as a compressed recap. Gentle on space, lossy on detail.
- Profile memory. Facts stored against a user ID outside the conversation: name, timezone, plan, preferred language. Survives across sessions and goes stale quietly.
- Retrieved memory. A search step pulls relevant snippets from past conversations or a knowledge base and pastes them in. Powerful when the search is good, noisy when it isn't.
Most production assistants combine at least two. A support bot might carry a rolling summary of the current ticket, a profile with the customer's plan tier, and retrieval over help articles.
How State Is Kept Between Turns
Since the model itself holds nothing, the application is the filing cabinet. The common pattern is a set of slots, which are named fields with values, filled as the conversation proceeds. A booking flow might track origin, destination, date, passengers and cabin class. After each message, the application extracts whatever it can, updates the slots, and passes the model only what it still needs.
Slot filling is why a well-built bot asks for your travel dates once, and why it stops asking after you have answered. State generally lives on two levels: session state, valid for this conversation only, and account state, persisted for the user and available next time. Deciding which is which is an editorial decision as much as a technical one. An order number usually belongs to the session. A language preference belongs to the account. Health, payment and legal details deserve a stricter answer than either, so if your chatbot handles that kind of information, speak to a qualified professional about what you may store and for how long.
Where Context Breaks Down
Truncation. The earliest turns drop out mid-task, so the bot asks for information it already has. Users read this as carelessness.
Dangling references. "Make it the same as the last one" arrives with no "last one" still in the window. The model guesses, and the guess sounds confident.
Topic bleed. Two threads share one conversation, and pronouns attach to the wrong subject. A refund question and a delivery question in the same chat is a classic setup for this.
Stale profiles. The user moved city, changed jobs or cancelled a subscription months ago. The stored fact never updated, so the bot greets them with old news.
Confident invention. A slot is empty, but the model fills the gap with a plausible value instead of asking. This is the failure that causes real damage, and it is the one worth designing against first.
Designing Conversations That Remember
- Sort your facts before writing a prompt. Three buckets: must remember, nice to remember, never store. The third bucket is the one people forget to define.
- Echo important details back. "Rome, 14 March, two passengers. Correct?" A confirmation costs one line; a correction after booking costs a support ticket.
- Summarise on a schedule. Every six to ten turns, rewrite the history into a fixed template: goal, decisions made, open questions, constraints. Templates survive compression far better than free prose.
- Keep a short facts block. Three or four lines at the top of the bundle listing what you know, plus the last thing the user asked for. Rewrite it each turn rather than appending to it.
- Use explicit slots for anything transactional. Dates, amounts, IDs, addresses. Inference is fine for tone; it is not fine for a booking reference.
- Let people see and fix what is stored. A plain "here's what I have on file" with an edit or delete option prevents most stale-fact complaints and earns trust quickly.
Testing memory before launch
Replay one conversation and add ten turns of small talk in the middle. Check whether the original request survives. Start a second session with the same account and see whether the bot repeats questions it should already know the answers to. Change a stored fact, then ask a question that depends on it. Ten minutes of this catches more bugs than reading prompts ever will.
Start Small, But Start Specific
You do not need five layers of memory on day one. Begin with a clean system prompt, a handful of well-chosen slots, and a facts block you rewrite every turn. Add summarisation when conversations regularly run long, and add profile storage when the same people come back. Then test the boring cases: the user who changes their mind, the one who types three topics in one message, the one who returns after a week.
Remembering the right details at the right moment is not a party trick. It is the difference between a bot that feels competent and one that feels like it is meeting you for the first time, over and over.
Photo: DeltaWorks / Pixabay
