Session State Serialization Prompt for Pause-and-Resume

This prompt is designed for platform teams building persistent chat applications where users can pause a session and resume it hours or days later. The core job is to serialize the full conversation state into a structured snapshot that can be stored externally, then used to reconstruct the assistant's context on resume. Use this prompt when you need a single, authoritative state object that captures active intents, filled slots, pending actions, unresolved references, and the minimal conversation context required to continue without replaying the entire history. This prompt is not a per-turn state tracker; it is a checkpoint generator for session lifecycle boundaries. It assumes you already have a conversation history and need a lossless serialization format for storage and restoration.

The ideal user is an AI engineer or backend developer responsible for session persistence in a chat product. You should have access to the full conversation transcript up to the pause point, including user messages, assistant responses, tool call results, and any structured state already tracked in your application. The prompt expects you to supply a target output schema that matches your application's state model—this is not a generic summarizer. You must define what 'active intents,' 'filled slots,' and 'pending actions' mean in your domain. The prompt works best when your conversation history is well-structured with clear turn boundaries and speaker roles. If your history is messy, unlabeled, or interleaved with system events, preprocess it before calling this prompt.

Do not use this prompt for real-time, per-turn state updates. For that, use a turn-by-turn state delta prompt that emits only what changed. Do not use this prompt when you need a human-readable summary for display purposes—this prompt produces machine-readable JSON for programmatic restoration. Do not use this prompt on extremely long conversations that exceed your model's context window without first pruning or summarizing older turns. The prompt is also not a substitute for a proper state machine in your application; it captures inferred state from natural language, which means it can miss state transitions that were never explicitly discussed. Always validate the output against your application's state schema before committing it to your session store.

Before deploying, test round-trip fidelity: serialize a session state, feed it back as context on resume, and verify the assistant behaves consistently with the original session. Common failure modes include dropped pending actions, hallucinated slot values for information the user never provided, and incorrect resolution of ambiguous references. Implement schema validation on the output and consider a secondary validation prompt that checks the serialized state against the source conversation for internal consistency. For high-stakes applications where state loss would cause user harm, always include a human review step or a confidence threshold below which the system requests user confirmation before restoring state.

This prompt template produces a structured JSON snapshot of the current conversation state, including active intents, filled slots, pending actions, and unresolved references. It is designed for platform teams building persistent chat products where sessions must survive disconnections, timeouts, or intentional pauses. The output is a single serializable object that can be stored and later used to restore the assistant's context without replaying the full conversation history.

textCopy
You are a session state serialization engine. Your job is to produce a complete, restorable snapshot of the current conversation state from the provided conversation history. The snapshot must be sufficient to resume the session later without data loss.

## INPUT

[CONVERSATION_HISTORY]

## OUTPUT SCHEMA

Return a single JSON object with the following structure. Do not include any text outside the JSON object.

{
  "session_id": "string (provided or generated identifier)",
  "serialization_timestamp": "ISO 8601 timestamp of snapshot creation",
  "active_intents": [
    {
      "intent": "string (primary or secondary intent label)",
      "confidence": "number between 0.0 and 1.0",
      "status": "active | on_hold | resolved",
      "evidence_turn_ids": ["list of turn indices or IDs supporting this intent"]
    }
  ],
  "filled_slots": [
    {
      "slot_name": "string",
      "value": "string or object (the captured value)",
      "source_turn_id": "string (which turn provided this value)",
      "status": "confirmed | unconfirmed | stale",
      "last_updated_timestamp": "ISO 8601"
    }
  ],
  "pending_actions": [
    {
      "action_id": "string (unique identifier)",
      "description": "string (what needs to be done)",
      "priority": "high | medium | low",
      "status": "pending | in_progress | blocked",
      "blocked_by": ["list of dependencies or missing slots"],
      "source_turn_id": "string"
    }
  ],
  "unresolved_references": [
    {
      "reference": "string (the ambiguous term or pronoun)",
      "possible_resolutions": ["list of candidate entities"],
      "turn_id": "string (where the reference appears)",
      "resolution_required": true
    }
  ],
  "conversation_phase": "string (current phase label, e.g., discovery, troubleshooting, decision, closure)",
  "last_user_intent_summary": "string (one-sentence summary of the user's most recent goal)",
  "context_notes": [
    "string (any additional context needed for resumption, such as user preferences, constraints, or tone)"
  ]
}

## CONSTRAINTS

[CONSTRAINTS]

- Only include information explicitly present or directly inferable from the conversation history. Do not hallucinate slots, intents, or actions.
- If no active intents exist, return an empty array for `active_intents`. Apply the same rule to all array fields.
- For `filled_slots`, mark a slot as `stale` if a later user turn explicitly contradicts or updates the value.
- For `pending_actions`, deduplicate actions that appear across multiple turns. If an action is completed, do not include it.
- For `unresolved_references`, only include references that genuinely prevent understanding. Do not flag resolved pronouns.
- If the conversation phase is unclear, set `conversation_phase` to `"unknown"`.

## EXAMPLES

[EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with actual values before sending to the model. [CONVERSATION_HISTORY] should contain the full turn history, ideally with turn IDs or indices for traceability. [CONSTRAINTS] can include domain-specific rules such as slot schemas, intent taxonomies, or compliance requirements. [EXAMPLES] should provide one or two few-shot examples of correct serialization output to anchor the model's behavior. [RISK_LEVEL] should be set to high if the session contains regulated, financial, or clinical data, which triggers additional validation and human review requirements downstream.

After generating the snapshot, validate the output against the schema before storing it. Check that all source_turn_id and evidence_turn_ids values reference actual turns in the input history. Reject snapshots with hallucinated turn references. For high-risk domains, route the serialized state to a human reviewer or a secondary validation model before committing it to persistent storage. Never restore a session from a snapshot that fails schema validation or contains unresolved contradictions.

The session state serialization prompt is not a standalone utility; it is a state persistence contract that sits between your conversation engine and your session store. The harness must treat the prompt output as a structured artifact that will be written to a database, validated for integrity, and later deserialized to restore a paused session. This means the application layer is responsible for providing the full conversation history as [CONVERSATION_HISTORY], the current active state schema as [STATE_SCHEMA], and any pending action definitions as [PENDING_ACTIONS_DEFINITION]. The prompt itself handles the compression logic, but the harness owns the lifecycle: capture, validate, store, retrieve, restore.

The validation layer is the most critical harness component. Before any serialized state is committed to storage, run a schema validator against the output to confirm that all required fields from [STATE_SCHEMA] are present, that slot values conform to their expected types, and that no hallucinated fields have been injected. A second validation pass should compare the serialized state against the source conversation history using a state consistency check: for every filled slot, verify that the value can be traced back to an explicit user utterance or a legitimate inference from the history. If the state references entities or actions not present in the source turns, flag the output for review or trigger a retry with a stricter [CONSTRAINTS] block that demands source grounding for every filled field. For high-stakes applications, route flagged serializations to a human review queue before they are committed to the session store.

Storage design must treat the serialized state as an immutable append-only record. Each serialization event should be versioned with a timestamp, a session identifier, and the model version that produced it. This enables audit trails, rollback to prior states, and debugging when restoration produces unexpected behavior. The harness should also store the raw prompt input and model output alongside the validated state so that production issues can be diagnosed without reconstructing the full request context. When restoring a session, the harness must deserialize the state back into the active context window, but it should also include a freshness check: if the serialized state is older than a configurable TTL, trigger a re-verification prompt that asks the user to confirm key facts before the assistant proceeds. This prevents stale state from driving confident but wrong responses after long pauses.

Model choice matters for this workflow. The serialization task requires strong instruction-following and schema adherence, so prefer models with proven structured output capabilities. If you are using a model that does not support native JSON mode or structured output constraints, the harness must include a repair-and-retry loop: parse the output, validate against the schema, and if validation fails, feed the parse error and the malformed output back into a repair prompt with the original [STATE_SCHEMA] as a constraint. Limit retries to a maximum of two attempts before escalating to a human operator or falling back to a simpler state snapshot that preserves only confirmed slots. Log every retry event with the failure reason for prompt debugging and model performance tracking over time.