Session Summary Injection Prompt for State Preservation

This playbook is for AI engineers and platform teams building long-running assistants, copilots, or support bots that must survive context window truncation. When a conversation exceeds the model's context limit, you need a compression-safe summary that preserves active instructions, unresolved items, user preferences, and critical state. This prompt produces that summary and validates it after re-injection so the assistant resumes without losing its operational contract. Use this when your application manages its own conversation history and you control the point where summarization occurs. Do not use this as a generic chat memory prompt; it is designed for explicit state handoff across context window boundaries.

The ideal deployment scenario involves a stateful application orchestrator that monitors token consumption and triggers summarization before the context window is exhausted. The orchestrator calls the summarization prompt, stores the compressed state, clears or archives the full history, and then re-injects the summary as the first turn of a new context window. This workflow is critical for copilots that maintain multi-hour sessions, support bots handling complex troubleshooting flows, and any assistant where losing mid-session state—such as an unresolved user question, a pending tool execution, or an active instruction override—would degrade the user experience or violate a compliance requirement. The prompt template includes placeholders for [CONVERSATION_HISTORY], [ACTIVE_INSTRUCTIONS], [UNRESOLVED_ITEMS], and [USER_PREFERENCES] so you can feed structured state objects directly from your application state manager.

Do not use this prompt when your application relies on the model's native context management, when sessions are short enough to fit entirely within the context window, or when you are using a third-party framework that handles summarization opaquely. This prompt also assumes you have a reliable mechanism to detect context window pressure; without accurate token counting and a safety margin, you risk triggering summarization too late and losing critical turns. Before deploying, validate that your re-injection logic correctly positions the summary as a system-level message that the model treats as authoritative state. Test for common failure modes: summary truncation that drops unresolved items, preference leakage where user corrections from early turns are lost, and instruction flattening where layered priority rules collapse into a single undifferentiated block. If your use case involves regulated domains, ensure your evaluation suite includes checks that safety policies and refusal conditions survive the compress-and-rehydrate cycle intact.

The following prompt is designed to be injected into a summarization step before the context window is truncated. Its job is to produce a structured summary that preserves active instructions, unresolved user requests, stated preferences, and critical state—not just a conversational recap. The output is intended to be re-injected as a system message after truncation, allowing the assistant to continue without losing its behavioral contract or task context. Use this template as a starting point and adapt the placeholders to match your application's specific state schema and instruction hierarchy.

textCopy
SYSTEM: You are a state-preservation summarizer. Your output will replace the truncated conversation history and be injected as a system message for the next turn. The summary must be structured, compression-safe, and sufficient to restore the assistant's full operational context.

INPUT:
- [CONVERSATION_HISTORY]
- [ACTIVE_SYSTEM_INSTRUCTIONS]
- [ACTIVE_TOOL_DEFINITIONS]
- [USER_PREFERENCES]

OUTPUT_SCHEMA:
{
  "session_state": {
    "active_instructions": ["list of system instructions still in effect"],
    "unresolved_tasks": [
      {
        "task_id": "string",
        "description": "string",
        "status": "pending | in_progress | blocked",
        "blocking_reason": "string | null"
      }
    ],
    "user_preferences": {
      "explicit": ["preference strings"],
      "inferred": ["preference strings"]
    },
    "critical_context": ["facts, decisions, or constraints that must survive truncation"],
    "last_tool_calls": [
      {
        "tool_name": "string",
        "arguments": {},
        "result_summary": "string"
      }
    ],
    "pending_confirmations": ["actions awaiting user approval"],
    "conversation_summary": "A dense, factual summary of the last N turns, preserving user goals and assistant actions."
  },
  "rehydration_instructions": "Instructions for the assistant on how to use this summary when it is injected as a system message in the next turn."
}

CONSTRAINTS:
- Do not omit any active system instruction. If an instruction was active before truncation, it must appear in `active_instructions`.
- For each unresolved task, capture what is blocking progress.
- Distinguish between explicit user preferences (stated directly) and inferred preferences (derived from behavior).
- The `conversation_summary` must be factual and avoid interpretive commentary.
- `rehydration_instructions` must tell the assistant to treat this summary as its new system-level context and to prioritize `active_instructions` over any conflicting information in the summary.

To adapt this template, start by replacing the OUTPUT_SCHEMA with the exact state fields your application needs to persist. If your assistant uses a specific instruction hierarchy, ensure the active_instructions field captures the full priority-ordered list. For tool-augmented agents, expand last_tool_calls to include error states and partial results. The rehydration_instructions field is critical: it tells the assistant how to interpret the summary when it reappears as a system message. Without it, the model may treat the summary as conversational history rather than operational context. Before deploying, validate the summary output against your rehydration logic by running a multi-turn simulation and checking that instruction fidelity and task state are restored correctly after injection.

The Session Summary Injection Prompt is not a standalone artifact; it is a component in a state-preservation pipeline. The typical integration point is a context window management layer that triggers summarization when the conversation approaches the model's token limit. The application should maintain a rolling summary object that is updated after each significant turn or when a context budget threshold is crossed. This summary becomes the [SESSION_SUMMARY] placeholder injected into the system message of subsequent requests. The prompt template itself should be stored as a versioned configuration, not hard-coded, to allow independent iteration on the compression format without redeploying application code.

To wire this into an application, implement a pre-request hook that checks the current token count against a defined budget (e.g., 80% of the model's context window). When the threshold is breached, call the summarization model with the full conversation history and the current active instructions. The output must be validated against the expected schema before it replaces the active summary. Key validation checks include: presence of active_instructions, unresolved_items, and user_preferences fields; non-empty instruction_fidelity_notes; and a compression_ratio that indicates meaningful reduction. If validation fails, retry once with a more explicit schema constraint in the prompt. If it fails again, log the failure, preserve the previous summary, and alert the ops channel. Do not inject a malformed summary into the context window.

After injecting the summary, the next user-facing turn should be treated as a rehydration checkpoint. Run a lightweight eval prompt that asks the model to restate its active instructions and list any unresolved items. Compare this output against the pre-summarization state. If the model cannot reproduce critical constraints or drops an unresolved item, trigger a correction prompt or escalate for human review. For high-stakes assistants in regulated domains, require a human to approve the summary before it is injected. Log every summary generation event with the pre-summary token count, post-summary token count, validation status, and rehydration check result. This audit trail is essential for diagnosing instruction drift and proving governance compliance.