> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open.cx/llms.txt
> Use this file to discover all available pages before exploring further.
# Conversation Sessions
> Understand how the AI Chat Widget handles conversation history, returning visitors, handoff, resolution, and session continuity.
Use this page when you need to answer questions like: "Will visitors see old chats?", "What happens after handoff?", or "Why does history behave differently for anonymous and signed-in users?"
If you have not decided how the widget should identify visitors yet, read **[Authentication](/widget/authentication)** first.
Want to try single-session mode and other session behaviors in one click? Open the **[Playground](/widget/playground)** and flip the toggles live.
## How A Conversation Flows
```mermaid theme={"dark"}
flowchart LR
A([Visitor opens widget]) --> B[Start or resume conversation]
B --> C[AI responds in the same thread]
C --> D[Issue resolved or needs more help]
D -->|Resolved| E([Conversation can be resolved])
D -->|Human| F([Human handoff in the same thread])
style A fill:#1a5c20,color:#fff,stroke:#267a2e
style E fill:#1a5c20,color:#fff,stroke:#267a2e
style F fill:#1a5c20,color:#fff,stroke:#267a2e
```
Whether the AI keeps the conversation, resolves it, or hands it to a person depends on your support setup and escalation rules. For the policy side, see [Human Handoff](/handoff/introduction).
## What Counts As A Session
A **session** is one conversation thread inside the widget. Visitors can have open and resolved sessions, and the widget can show a list of earlier conversations when that fits your setup.
A new session starts when the visitor opens a new thread and sends a message.
Returning visitors can reopen existing threads instead of starting from scratch, as long as the widget can still identify them.
Resolved sessions remain part of the visitor's history, but they are no longer active chat threads.
## How Returning History Works
History access depends on how you identify the visitor:
Best for low-friction support. History stays tied to the same browser session.
Good for personalization, but not strong identity across devices.
Best when signed-in customers should keep conversation history across devices.
Verified and non-verified conversation histories are treated differently. If a user sometimes loads the widget with a verified identity and sometimes without one, the history experience will not be the same across those cases.
## Session Rules That Affect The Visitor Experience
These configuration choices change what visitors can do:
**Default:** Visitors can have multiple open conversations.
**What changes:** `oneOpenSessionAllowed: true` hides the new-conversation option while an open thread already exists.
**Choose this when:** You want visitors to stay focused on one active issue at a time.
**Default:** The widget can show a sessions list before entering chat.
**What changes:** `router.chatScreenOnly` removes the sessions browser and lands the visitor directly in the chat experience.
**Choose this when:** You want the widget to feel like a single-thread support chat instead of a small inbox.
**Default:** First-time visitors may pass through the sessions logic before entering chat.
**What changes:** `router.goToChatIfNoSessions` takes first-time visitors directly into the chat flow when there is nothing to resume.
**Choose this when:** You want less friction for brand-new visitors.
**Default:** Visitors continue using the conversation until your flow or team closes it.
**What changes:** Adding the `resolve-session` header button gives the visitor a direct way to close the conversation from the widget itself.
**Choose this when:** You want visitors to explicitly mark an issue as done.
## What Handoff Looks Like In The Widget
When the AI hands off, the conversation stays in the same thread. Your visitor does not need to start over somewhere else.
The thread stays open, but the AI is no longer the active responder for that issue.
Your visitor keeps talking in the same conversation instead of being pushed into a separate support flow.
The full conversation remains available to your team so the visitor does not have to repeat everything.
Use `onHandoff` to trigger your own banner, form, or next-step UI when handoff happens.
```javascript theme={"dark"}
const options = {
token: '',
onHandoff: (payload) => {
console.log('Conversation handed off:', payload.summary);
},
};
```
Need the decision rules behind handoff? See [Human Handoff](/handoff/introduction) for when the AI escalates, what triggers a human takeover, and how that policy works across channels.
## Feedback And Resolution
Two common post-conversation patterns are available:
`thisWasHelpfulOrNot` controls the built-in prompt that asks whether the latest AI answer solved the issue. Use it when you want a lightweight “resolved vs still need help” check before the conversation moves on.
Use `thisWasHelpfulOrNot` when you want the widget to ask whether the latest AI answer solved the issue.
The widget can show CSAT when your workflow requests it, and headless builds can control the experience with the CSAT hooks.
***
## Related Documentation
Choose the identity model that controls history access.
Session rules, routing, prompts, and resolution controls.
Configure when the AI should escalate to a person.
Missing history, repeated prompts, and handoff confusion.