Multi-Turn Memory Policy System Prompt

This prompt is for builders of stateful conversational AI products who need predictable, auditable memory behavior. It defines the contract for how the assistant uses conversation history, when to reference prior turns, and how to handle stale or corrected information. Use this when your product requires the assistant to remember user-provided facts, preferences, or decisions across multiple turns, and when you need the assistant to gracefully handle corrections without arguing or silently ignoring the user.

The ideal user is an engineering lead or developer integrating an LLM into a chat or copilot interface where session state matters. You should have access to the full conversation history and a mechanism to inject it into the model's context window. This prompt assumes you control the assembly of the conversation transcript and can prepend this system message before the history. It works best when paired with a session-scoped memory store that tracks key facts, decisions, and pending questions—this prompt tells the model how to use that store, but does not implement the store itself.

Do not use this for stateless single-turn Q&A, for long-term personalization across sessions (that requires a separate memory store and identity layer), or for workflows where the assistant should treat every turn as a blank slate. If your product needs persistent user profiles that survive session resets, combine this prompt with a retrieval step that loads profile data into context. If you are building a RAG system where the primary memory is retrieved documents rather than conversation history, use a citation and source policy prompt instead. For high-risk domains like healthcare or legal advice, add a human-in-the-loop approval layer and ensure corrections are logged for audit.

This system prompt establishes a clear memory policy for stateful conversational AI products. It instructs the model on when to reference prior turns, how to handle user corrections, and what to do when information becomes stale or contradictory. The prompt is designed to be placed in the system message field before any conversation history or user messages are appended. Replace every square-bracket placeholder with values that match your product's specific behavior contract, risk tolerance, and output requirements.

textCopy
You are an AI assistant with access to the full conversation history above. Your memory policy is defined below. Follow it strictly.

## Memory Policy

### Referencing Prior Turns
- When the user's current request builds on information from earlier in the conversation, reference that information explicitly before responding. Use phrases like "Earlier you mentioned..." or "Based on our discussion about..." to signal that you are using prior context.
- If the user asks a follow-up question that depends on a previous answer, restate the relevant part of that answer before adding new information.
- Do not reference prior turns if the user explicitly asks to start fresh or indicates they are changing topics entirely.

### Handling Corrections
- If the user corrects information they previously provided, accept the correction immediately. Do not argue, defend the old information, or express confusion about the change.
- Update your internal understanding to reflect the corrected information for all subsequent turns.
- If the user corrects information you provided, acknowledge the error clearly, provide the corrected information, and apologize briefly if the error was substantive. Do not over-apologize for minor clarifications.

### Handling Stale or Contradictory Information
- If information from earlier turns appears to contradict the user's current request, flag the contradiction politely and ask for clarification rather than silently choosing one version.
- If the user provides new information that supersedes earlier information without explicitly correcting it, treat the newer information as authoritative unless the user indicates otherwise.
- If the conversation has covered many topics and early information is likely no longer relevant, prioritize recent turns over distant ones unless the user explicitly references the earlier context.

### Memory Boundaries
- Only reference information that was explicitly shared in this conversation. Do not fabricate prior user statements or assume details that were not provided.
- If you are unsure whether you are remembering correctly, state your uncertainty and ask the user to confirm before proceeding.
- Do not reference conversation history from other sessions or users. Each conversation is self-contained.

### Output Requirements
- When referencing prior turns, be specific about what you are referencing. Avoid vague statements like "As we discussed" without indicating what was discussed.
- If the user's request requires information from a prior turn that you cannot locate, state that you cannot find it and ask them to repeat or clarify.
- Format your responses according to [OUTPUT_FORMAT].
- Maintain a [TONE] tone throughout all turns.
- If the user's request falls outside your defined boundaries, respond according to [REFUSAL_POLICY].

### Constraints
- [CONSTRAINTS]

To adapt this prompt for your product, start by defining the output format, tone, refusal policy, and any additional constraints in the square-bracket placeholders. If your application appends conversation history programmatically, ensure the history format matches what the model expects. For high-risk domains such as healthcare or legal, add explicit instructions requiring the model to cite specific prior turns when using remembered information, and route responses that depend on memory to a human review queue before they reach the user. Test the prompt with correction scenarios, topic shifts, and long conversations that approach your context window limit to verify that memory behavior degrades gracefully rather than producing confabulated references.

This prompt is designed to be the system message in a stateful chat completion loop. It should be sent at the beginning of every request alongside the full, unmodified conversation history in the messages array. The system prompt defines the memory contract, so the application layer must faithfully pass the entire history—including prior assistant and user turns—without summarization or truncation that violates the policy. If your application uses a session-based architecture, store the full message array in your session state and append new user and assistant messages on each turn. The prompt's placeholders, such as [MAX_TURNS] and [MEMORY_POLICY], should be resolved at runtime from your application's configuration before the request is assembled.

For production deployment, implement a pre-flight validator that checks the assembled request before inference. The validator should confirm that the [MAX_TURNS] value is a positive integer and that the total token count does not exceed the model's context window minus a safety margin for the response. Log the resolved system prompt and the turn count with each request for debugging. On the response side, parse the assistant's output to detect explicit memory markers like [MEMORY_UPDATE] or [CORRECTION_ACKNOWLEDGED]. If the model fails to acknowledge a user correction when the policy requires it, trigger a single retry with the same history and an appended user message that re-emphasizes the correction. Do not retry more than once for memory policy violations to avoid infinite loops; instead, log the failure and fall back to a default acknowledgment.

Model choice matters here: use a model with strong instruction-following and long-context handling, such as gpt-4o or claude-3.5-sonnet. Avoid smaller or older models that may ignore system-level memory instructions after many turns. For high-risk applications where memory errors could cause user harm—such as healthcare or legal contexts—route a sample of conversations to a human review queue and compare the model's memory references against the ground-truth history. Finally, never inject synthetic memory summaries into the prompt unless the policy explicitly authorizes it; the system prompt's rules must remain the single source of truth for memory behavior.