Session Boundary Detection Prompt Template

This prompt is for platform teams and AI engineers who need to manage the lifecycle of persistent chat sessions. Its job is to analyze a conversation's recent history and the latest user turn to detect explicit or implicit signals of session start, session end, or session restart. The primary reader is a developer integrating this detection into a state machine that controls session creation, archival, or context reset. Use this when your application must programmatically decide to spin up a new session, gracefully close an active one, or re-initialize state based on user behavior, not just timeouts.

Deploy this template when you need a structured boundary event to drive backend logic, such as resetting a context window, writing a final session summary to a database, or presenting a 'start new conversation' UI element. It is designed for text-based chat, but the logic applies to voice transcripts as well. The prompt is most effective when the conversation history provided includes at least the last 3-5 turns to capture the transition. Do not use this prompt for detecting topic shifts within a single session; that requires a different classification target. This prompt is for lifecycle events that have durable side effects on the session's existence.

Avoid using this prompt in isolation without a validation harness. A false positive on session end can prematurely terminate a user's workflow, while a false negative on session restart can pollute a fresh context with stale information. The output must be treated as a signal with a confidence score, not an absolute command. For high-stakes applications, always pair this prompt with a confirmation step or a human-in-the-loop review for low-confidence detections before executing a destructive action like deleting session state.

This prompt template is designed to be the core instruction set you send to the model for session boundary detection. It accepts a conversation history and the latest user turn, then outputs a structured boundary event classification. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into a production application where history and user input are injected at runtime.

textCopy
You are a session boundary detection classifier. Your task is to analyze the provided conversation history and the latest user turn to determine if the user intends to start a new session, end the current session, or restart/resume a previous session.

## INPUT
[CONVERSATION_HISTORY]
[LATEST_USER_TURN]

## CLASSIFICATION TAXONOMY
Classify the user's intent into exactly one of the following boundary event types:
- `session_start`: The user is initiating a new conversation or task, with no dependency on prior context. This includes initial greetings and fresh topic introductions.
- `session_end`: The user is signaling they want to conclude the current interaction. This includes farewells, confirmations of completion, and explicit closing statements.
- `session_restart`: The user is returning to a previous session or asking to resume an earlier conversation. This includes phrases like "let's continue where we left off" or "I'm back."
- `no_boundary`: The user's turn is a normal continuation of the current session with no boundary intent.

## OUTPUT_SCHEMA
Return a valid JSON object with the following fields:
- `boundary_event` (string, required): One of `session_start`, `session_end`, `session_restart`, `no_boundary`.
- `confidence` (float, required): A score between 0.0 and 1.0 indicating your confidence in the classification.
- `evidence_spans` (array of strings, required): Short quotes from the user's turn that support the classification. Empty array if `no_boundary`.
- `rationale` (string, required): A one-sentence explanation of the classification decision.

## CONSTRAINTS
- Do not classify a turn as `session_start` if the user is clearly continuing an existing topic.
- Ambiguous greetings (e.g., "hello" after a long pause) should be classified as `session_start` only if the prior context shows a completed or timed-out session.
- Resumption phrases like "I'm back" or "continuing from yesterday" must be classified as `session_restart`.
- If the user corrects or contradicts prior turns, this is `no_boundary` unless they explicitly signal a fresh start.
- Do not hallucinate evidence spans. Only quote text present in [LATEST_USER_TURN].

## EXAMPLES
[EXAMPLES]

Return only the JSON object. Do not include any other text.

To adapt this template, replace each square-bracket placeholder with your application's runtime data. [CONVERSATION_HISTORY] should contain the prior turns formatted consistently—preferably as a list of role-content pairs. [LATEST_USER_TURN] is the single most recent user message. [EXAMPLES] should be populated with 3–5 few-shot demonstrations covering each boundary type, especially the ambiguous cases like post-pause greetings and mid-correction resets. If your application uses a specific session timeout threshold, add that as a [TIMEOUT_DURATION] constraint. Before deploying, run this prompt against a golden eval set that includes false positives (e.g., topic shifts misclassified as session restarts) and false negatives (e.g., genuine endings missed). Wire the output through a JSON validator and a confidence threshold gate—any classification below 0.7 should either trigger a clarification question or fall back to no_boundary.

The Session Boundary Detection prompt is designed to sit at the entry point of your conversation processing pipeline, before any domain-specific routing or state updates occur. It should be invoked on every user turn, receiving the full conversation history and the latest user message as input. The output—a boundary event type (session_start, session_end, session_restart, or no_boundary) with a confidence score—determines whether your application should initialize a new session context, persist and close the current session, reload a prior session state, or continue processing normally. This prompt is not a standalone decision-maker for high-stakes session lifecycle actions; it is a signal that your application harness must validate, threshold, and combine with other system-level checks such as explicit user logout commands, session timeout timers, and idle detection.

Wire this prompt into your application by placing it behind a lightweight API endpoint or a serverless function that accepts a session ID, the full turn history, and the latest user input. The harness must enforce a minimum confidence threshold before acting on any boundary event. For session_end and session_restart events, require a confidence score of 0.85 or higher before triggering state serialization or session teardown; for session_start, a threshold of 0.75 is typically sufficient. When the confidence falls below the threshold, log the ambiguous boundary event for review and treat the turn as no_boundary to avoid premature session termination. Implement a retry strategy with a single retry using a slightly modified prompt variant that asks the model to explain its reasoning before classifying, which often resolves low-confidence edge cases. All boundary decisions must be logged with the session ID, timestamp, model version, prompt version, input token count, output classification, confidence score, and the raw model response for auditability.

For session restart detection—where a user says something like 'let's start over' or 'new topic, same issue'—the harness must distinguish between a full session reset and a topic shift. The prompt outputs a session_restart event, but your application logic should check whether there is an active session with unresolved state (pending actions, unfilled slots) before deciding to archive the old session and start fresh versus simply clearing the topic context. Persist the old session state with a termination reason and a reference to the new session ID. For session_end detection, trigger a session summarization prompt to produce a structured summary before closing, and set a session expiry timestamp. For session_start, initialize a new session record with the detected start trigger and any context carried over from a prior restart. Avoid wiring this prompt directly to destructive session operations without a confirmation step for high-confidence but potentially ambiguous boundary events, such as 'goodbye for now' which could be a temporary sign-off rather than a terminal session end.