Session Context· Conversation design concept
Session Context — Definition, How Chatbots Use It, and Examples (2026)
Quick answer: Session context is everything a chatbot carries forward inside one conversation so it can answer the next message in light of the last. It holds the recent message history, any details the bot has pulled out (an email, a product, an intent), and the user's position in a flow. Without it, every message is an island and the bot feels amnesiac. With it, the conversation feels like one continuous exchange rather than a sequence of disconnected questions.
What session context means
When a person types "the blue one" or "actually, make it two," those messages only make sense against what was said a moment earlier. Session context is how a chatbot holds onto that "moment earlier." It is the working memory of a single conversation: the running transcript, the structured facts the bot has captured, and the state of whatever flow the user is in.
The word session is doing real work here. A session is one continuous conversation — it starts when the user opens the chat and ends when they leave, time out, or finish. Session context lives and dies with that session. It is distinct from long-term memory, which persists across separate visits, and from the model's context window, which is a technical token limit rather than a design concept. Confusing the three is the most common source of muddled thinking about chatbot memory, so the distinctions are worth pinning down.
What session context actually holds
A useful way to picture session context is as three layers the bot maintains in parallel:
- Conversation history — the recent back-and-forth, in order. This is what lets the bot resolve references like "it," "that one," or "the second option."
- Extracted entities and slots — structured details the bot has captured so far: a name, an order number, a date, a chosen product. These are pulled out by entity extraction and held so the bot does not have to ask twice.
- Flow and intent state — where the user sits in a multi-step process (step 2 of a return request) and the current intent driving the exchange. This is what lets a bot pause, handle a side question, and return to where it was.
A fourth, often-overlooked element is user identity: whether this is a known customer, their channel, their language. That identity frame shapes every reply even though it is not part of the literal transcript.
Session context vs context window vs long-term memory
These three terms get used interchangeably and they should not be. The distinction decides what a bot can and cannot do.
| Concept | Scope | Lifespan | What it is |
|---|---|---|---|
| Session context | One conversation | The session only | The design-level working memory: history, entities, flow state |
| Context window | One model call | A single request | The token budget an LLM can read at once |
| Long-term memory | Across conversations | Persistent | Profile and history a bot recalls on the user's next visit |
The relationship matters in practice. Session context is the intent — "remember this conversation." The context window is one constraint on delivering it: an LLM-driven bot usually realizes session context by replaying recent turns into the model's context window on every call, so a long conversation can outgrow the window and force the bot to summarize or drop older turns. A button-driven bot, by contrast, holds session context in plain variables with no token limit at all. Same concept, very different mechanics — the deeper plumbing is covered in the companion chatbot memory guide.
Why it decides whether a bot feels intelligent
Session context is the single biggest factor in whether a conversation feels coherent. A bot with weak session handling produces the classic frustration loop: it asks for an order number, the user gives it, and three messages later it asks again because the value fell out of context. Each repeat erodes trust and pushes the user toward a human handoff — or out the door.
Strong session context also underpins genuine multi-turn understanding. Natural language understanding on a single message can only classify that message; resolving "yes, the cheaper plan" requires the bot to know what two options it just offered. That is session context, not raw NLU. It is also what lets a conversational AI bot handle interruptions gracefully — a user asking a tangential question mid-checkout and then saying "okay, back to my order" only works if the flow state survived the detour. Designing those returns deliberately is the heart of good conversation design.
How platforms implement it
Approaches split along the same line as the rest of the chatbot world.
Flow-driven platforms like Manychat store session context as explicit variables attached to the contact. A captured email or product choice is written to a field and stays available for the rest of the flow. This is predictable and easy to audit, but the "memory" is only as good as the variables the builder thought to define — the bot remembers exactly what you told it to store and nothing more.
LLM-driven platforms like Botpress and Voiceflow typically assemble session context by feeding recent turns (plus a system prompt and any retrieved knowledge) into the model on each call. This handles open-ended reference resolution far better, but it is bounded by the context window and costs tokens on every turn, so long sessions need summarization strategies.
Support-desk platforms such as Intercom and Tidio tie session context to a conversation object that both the bot and a human agent can see, which is what makes a clean handoff possible — the agent inherits the full session rather than starting cold.
A worked example
A customer messages a store bot: "Do you have the running jacket in medium?" The bot confirms stock. The customer follows with "great, and in blue?" then "add two to my cart."
Here is what session context is doing across those three turns:
| Turn | User says | Session context carries | Why it works |
|---|---|---|---|
| 1 | "running jacket in medium?" | product = running jacket, size = M | Entities captured into slots |
| 2 | "and in blue?" | + color = blue, product still = jacket | "in blue" resolves against held product |
| 3 | "add two to my cart" | quantity = 2, item = jacket/M/blue | "two" and "my cart" need all prior slots |
Strip out session context and turn 2 becomes "blue what?" and turn 3 fails entirely. The intelligence the user perceives is almost entirely the bot's ability to carry those slots forward.
Common failure modes
- Context loss mid-flow. A captured value is not persisted to a durable slot, so the bot re-asks. The most common and most damaging failure.
- Stale context. The bot keeps acting on an intent the user has moved on from, because nothing reset the flow state when the topic changed.
- Window overflow. An LLM bot in a long session silently drops the early turns that held the key detail, then contradicts itself.
- Session bleed. Context from a previous, separate conversation leaks into a new one because the session boundary was not reset — the bot "remembers" something it should have forgotten.
Each of these shows up in the metrics as rising repetition, abandoned flows, or unexplained handoffs, which is why session quality is worth watching alongside the headline numbers in the chatbot metrics guide.
Related terms
- Conversational AI — the broader category that session context makes coherent.
- Natural language understanding — interprets each message; session context spans across them.
- Large language model — its context window is the technical constraint on LLM-based session handling.
- Human handoff — works cleanly only when the full session transfers to the agent.
- System prompt — the standing instruction layered alongside session context on each LLM call.
FAQ
What is session context in a chatbot?
It is the information a bot keeps and reuses during one conversation — the recent message history, captured details like an order number, the user's identity, and their position in a flow — so each reply accounts for what came before instead of treating every message in isolation.
What is the difference between session context and the context window?
Session context is a design concept: "remember this conversation." The context window is a technical limit: the number of tokens a large language model can read in one call. An LLM bot often delivers session context by replaying recent turns into its context window, so the window can constrain how much session context survives — but they are not the same thing.
Is session context the same as chatbot memory?
It is one kind. Session context is short-term, single-conversation memory that ends with the session. Long-term memory persists across separate visits. A bot can have strong session context and no long-term memory at all, which is common and often appropriate for support bots.
How long does session context last?
For the length of the session — from when the user opens the chat until they leave, time out (often 15-30 minutes of inactivity), or complete the task. After that the session closes and its context is cleared unless the platform promotes specific values to long-term storage.
Why does my chatbot keep asking for the same information?
Almost always a session-context failure: a captured value was not written to a durable slot, or the flow state reset unexpectedly. It is the most common session bug and the fastest to erode user trust. The fix is to persist key entities explicitly and test multi-turn flows, not just single messages.
Sources
- Chatbotscape Academy. Chatbot memory guide and Chatbot metrics guide. /academy/chatbot-memory-guide, /academy/chatbot-metrics-guide (verified 8 June 2026).
- Chatbotscape platform reviews — conversation and analytics sections. /reviews (continuously updated).
- Chatbotscape evaluation methodology. /methodology (continuously updated).