Conversation State Reset Prompt Template

This prompt is designed for a specific job: explicitly resetting the conversational context of a RAG assistant when a user signals a new, unrelated topic or begins a fresh session. The ideal user is an AI engineer or product developer building a multi-turn chat copilot where stale dialogue history, prior retrieved evidence, or unresolved follow-up questions can corrupt the answer to a new query. The required context includes the user's reset signal (e.g., 'new topic', 'forget the last question', or a UI 'New Chat' button event) and the new user question. The prompt's job is to produce a clean-state acknowledgment, discard all prior context dependencies, and answer the new question solely from fresh retrieval.

Do not use this prompt for detecting topic shifts automatically—that is a separate classification task handled by a Topic Shift Detection Prompt. Do not use it when the user's new question is a logical follow-up that depends on prior answers; that requires a Follow-Up Answer Synthesis Prompt. This prompt is also inappropriate for managing gradual context expiration or staleness, which is the domain of the Stale Context Expiration Prompt. It is a hard, explicit reset triggered by a user action or a clear session boundary, not an inferred state change. Using it for subtle topic drift will result in a jarring user experience where the assistant forgets useful context prematurely.

Before wiring this into production, confirm that your application layer can reliably detect the reset signal. A UI-driven 'New Chat' button is the cleanest trigger. If you rely on natural language detection (e.g., classifying 'let's start over' as a reset intent), you must validate that classifier's precision to avoid false-positive resets that discard valuable context mid-session. After deploying, monitor for two failure modes: incomplete resets where the assistant still references prior turns, and over-resets where the assistant loses benign session preferences like the user's name or preferred output format. The next section provides the copy-ready template to implement this behavior.

This prompt template is designed to be injected into a RAG assistant's system instructions or used as a standalone message when a topic shift is detected. Its job is to force the model to discard accumulated conversational context, stop referencing prior answers, and begin a new, clean interaction with the user. Use this template as the core instruction set that your application layer triggers when a topic boundary is identified by an upstream classifier or explicit user command.

textCopy
SYSTEM: You are a conversation state manager for a RAG assistant. Your task is to execute a full context reset. You must:
1. Acknowledge the user's new topic or session start.
2. Explicitly state that prior context has been cleared.
3. Do not reference, cite, or rely on any previous user messages, assistant responses, or retrieved documents from earlier turns.
4. Treat the following user message as the start of a brand-new conversation.
5. Respond only to the new topic using the provided [RETRIEVED_CONTEXT] if available.

[RETRIEVED_CONTEXT]
[EVIDENCE_CHUNKS]

USER MESSAGE: [USER_INPUT]

CONSTRAINTS:
- [CITATION_STYLE]
- [OUTPUT_FORMAT]
- [ABSTENTION_POLICY]

RESPONSE:

To adapt this template, replace the square-bracket placeholders with your application's specific values. [RETRIEVED_CONTEXT] should be populated with fresh evidence retrieved for the new user query. [EVIDENCE_CHUNKS] is where you insert the actual text passages. [USER_INPUT] is the new message from the user. The [CONSTRAINTS] block is critical for maintaining behavioral consistency across resets; wire in your standard citation style, output format requirements, and abstention rules. Do not carry over any dynamic few-shot examples or conversation summaries from prior turns. The next step after implementing this template is to pair it with a robust topic-shift detection mechanism and log every reset event to monitor for false positives that might disrupt a coherent multi-turn workflow.

The Conversation State Reset prompt is not a standalone feature; it is a state machine transition triggered by a topic shift classifier or an explicit user command. In a production RAG assistant, this prompt should fire when the topic shift detection prompt returns a confidence score above your threshold (typically 0.85) or when the user sends a reset signal such as '/reset' or 'new topic'. The prompt's output must be parsed for a reset_acknowledgment string and a state_cleared boolean before the application layer clears the conversation history array, the evidence cache, and any unresolved question tracker. Do not rely on the model's acknowledgment alone to perform the actual state wipe—the application must own the destructive operation.

Wire the prompt into a state management module that handles three concrete actions: (1) Pre-reset snapshot: serialize the current conversation state to a cold-storage log before clearing, so debugging and eval traces remain available. (2) Prompt execution: send the reset prompt with the last N turns of conversation context and a [RESET_TRIGGER] indicating whether the reset was user-initiated or system-detected. Use a low temperature (0.0–0.2) and a short max_tokens limit (150 tokens) since the output is a structured acknowledgment, not a generative answer. (3) Post-reset validation: parse the response and confirm state_cleared is true. If the model returns false or malformed JSON, retry once with an explicit error message injected into the prompt. If the retry also fails, log the failure, fall back to a hard-coded acknowledgment message, and clear state anyway—never block the user on a reset failure.

For observability, log every reset event with the trigger source, the snapshot reference, the model's acknowledgment text, and the validation result. This is critical for debugging incomplete resets, where the model acknowledges the reset but the application fails to clear evidence or unresolved questions. In high-stakes deployments (healthcare, legal, finance), add a human-review queue entry when the reset was triggered by a topic shift classifier with confidence between 0.70 and 0.85—this is the gray zone where the system suspects a topic change but isn't certain. A reviewer can confirm the reset or re-anchor the conversation before state is destroyed. Finally, wire the reset acknowledgment into the user-facing UI immediately so the user sees a clear 'Starting fresh' signal, and disable any 'regenerate with prior context' buttons to prevent accidental re-contamination of the new session.