Session Restart Summary Prompt for Pause-and-Resume

This prompt is designed for products that support long-running, interruptible AI sessions where a user may pause a conversation and return hours or days later. The core job-to-be-done is to generate a concise restart brief that reorients both the assistant and the user without replaying the full conversation history, which is expensive, slow, and often unnecessary. The ideal user is an AI engineer or platform developer building a persistent chat product—such as a customer support copilot, a research assistant, or a task-oriented agent—where session state must be serialized for storage, handoff, or later resumption. The prompt produces two distinct artifacts: a user-facing natural language summary that welcomes the user back and recaps the current state, and a machine-facing structured state payload that the application can use to restore dialogue state, active slots, pending actions, and unresolved questions.

This prompt is specifically scoped for the pause-and-resume lifecycle event. It assumes that the full conversation history is available at the time of summarization but will not be replayed when the session resumes. The prompt should be triggered at the point of session archival or user disconnection, not mid-session. It is not designed for real-time turn-by-turn summarization, where a sliding window of recent turns must be continuously compressed into a running summary. It is also not suitable for compressing history that will be immediately reused within the same context window, as those workflows require different salience-scoring and budget-enforcement prompts that optimize for token allocation rather than human readability and state restoration. Using this prompt for continuous in-session compression will produce summaries that are too verbose for tight context budgets and too focused on user-facing readability rather than dense information preservation.

Before implementing this prompt, confirm that your product architecture supports storing and retrieving the machine-facing state payload alongside the user-facing summary. The prompt's value depends on the application's ability to rehydrate dialogue state from the structured payload—restoring active slots, pending tool calls, and unresolved questions—so the assistant can continue coherently without re-processing the original transcript. If your system cannot consume a structured state object at session restart, you should either extend your session management layer to do so or use a simpler summary-only prompt. Do not use this prompt for agent-to-agent handoff scenarios, which require a different context-packing strategy focused on active goals and constraints rather than user-facing reorientation.

This template is the core engine for a pause-and-resume workflow. It instructs the model to process a raw session transcript and associated metadata, producing two distinct outputs: a friendly, human-readable summary paragraph to greet the returning user, and a strict JSON payload that your application can parse to restore dialogue state, active slots, and pending work. The prompt is designed to be dropped directly into your orchestration layer, with all dynamic values injected via your application code before the API call.

textCopy
You are a session summarization engine for an AI assistant platform. Your task is to generate a restart brief for a paused conversation session. The user will return later and the assistant must resume seamlessly without replaying the full history.

Generate two outputs:
1. A user-facing summary paragraph that greets the returning user, recaps what was discussed, states any decisions made, and lists any open questions or pending actions.
2. A machine-facing state payload in strict JSON format that the application will use to restore dialogue state.

--- SESSION TRANSCRIPT ---
[SESSION_TRANSCRIPT]
--- END TRANSCRIPT ---

Session metadata:
- Session ID: [SESSION_ID]
- Last activity timestamp: [LAST_ACTIVITY_TIMESTAMP]
- Session duration: [SESSION_DURATION]
- Active goals or intents from prior state: [ACTIVE_GOALS]
- Pending actions from prior state: [PENDING_ACTIONS]
- Unresolved questions from prior state: [UNRESOLVED_QUESTIONS]

--- OUTPUT SCHEMA ---
{
  "user_summary": "string (friendly, concise, 2-4 sentences)",
  "machine_state": {
    "session_id": "string",
    "last_activity": "ISO 8601 timestamp",
    "summary_brief": "string (dense factual summary for the assistant, 3-5 sentences)",
    "decisions_made": [{"decision": "string", "made_by": "user | assistant | mutual", "timestamp": "string"}],
    "pending_actions": [{"action": "string", "owner": "user | assistant | unassigned", "priority": "high | medium | low"}],
    "unresolved_questions": [{"question": "string", "context": "string (the turn or topic where it arose)"}],
    "active_slots": {"key": "value"},
    "current_topic": "string | null",
    "sentiment_trajectory": "positive | neutral | negative | mixed",
    "restart_instructions": "string (guidance for the assistant on how to begin the resumed session)"
  }
}

--- CONSTRAINTS ---
[CONSTRAINTS]

Generate the output now.

To adapt this template, replace the bracketed placeholders with live data from your session store. The [SESSION_TRANSCRIPT] should be the full, formatted conversation history. The metadata fields ([ACTIVE_GOALS], [PENDING_ACTIONS], [UNRESOLVED_QUESTIONS]) are optional but highly recommended; they act as hints from your existing state tracker to improve summary accuracy. The [CONSTRAINTS] block is where you inject any additional rules, such as a maximum token length for the summary_brief field, domain-specific terminology requirements, or instructions to exclude PII. For high-stakes domains like healthcare or finance, add a constraint requiring the summary_brief to cite specific line numbers or turn IDs from the transcript for every factual claim.

Before deploying, you must implement a post-generation validation step. Parse the model's output and validate the machine_state against the defined JSON schema. Check that sentiment_trajectory is one of the allowed enum values and that all timestamps are valid ISO 8601 strings. If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block. For production systems, log the generated user_summary and machine_state alongside the [SESSION_ID] to build an audit trail of state transitions. The next step is to wire this prompt into your session lifecycle handler, ensuring it fires on session timeout or explicit user pause, and that the resulting restart_instructions field is injected as the first system message when the session resumes.

Integrate this prompt into your application's session lifecycle management layer. The trigger points are explicit user pause commands, session timeouts, or periodic auto-save checkpoints during long-running conversations. When triggered, construct the prompt call with the full conversation transcript and any known state variables such as active task IDs, user preferences, or pending approvals. The prompt returns a structured machine_state JSON payload containing restart_instructions, summary_brief, and user_summary. Store this payload in your session database keyed by session ID, alongside a timestamp and the model version used. When the user resumes, load the machine_state and inject restart_instructions and summary_brief into the assistant's system prompt or as the first user turn. Render the user_summary field directly to the user as a greeting message that reorients them without replaying the full history.

Implement a validation step that checks the output against the expected schema before storage. Define a strict schema with required fields: restart_instructions (string), summary_brief (string), user_summary (string), pending_actions (array of objects with action, owner, status), and open_questions (array of strings). If validation fails, retry once with a repair prompt that includes the original transcript, the malformed output, and the specific validation errors. If the session transcript is very short—fewer than three substantive turns with actual task content—skip this prompt entirely and store the raw transcript instead. This prevents unnecessary summarization overhead for trivial interactions. Log every generated summary with the session ID, timestamp, model version, and token counts for debugging and evaluation. For regulated domains such as healthcare or finance, flag the machine_state for human review before it is used to resume the session. The reviewer should confirm that no critical decisions, commitments, or clinical facts were dropped or hallucinated in the compression step.

Choose a model with strong instruction-following and structured output capabilities for this prompt. The task requires precise schema adherence and factual faithfulness to the source transcript, making it a poor fit for smaller or less reliable models. If your application already uses a validation and retry harness for other structured outputs, reuse that infrastructure here. Avoid storing the machine_state without validation—an invalid or hallucinated summary will corrupt the user's session on resume and erode trust. Test this prompt with transcripts of varying lengths, including edge cases with rapid topic shifts, user corrections, and multi-step task dependencies. The most common production failure mode is a summary that drops a pending action item the user explicitly asked about, so focus your evaluation on action item completeness and factual consistency with the original transcript.