Structured Session Summary Prompt Template

This prompt is designed for AI engineers and platform teams who are building chat assistants, copilots, or support agents that must survive long-running sessions. The core job-to-be-done is a context window boundary handler: you have a transcript that is about to exceed the model's token limit, and you need to compress it into a structured, machine-readable state object before pruning the history. The ideal user is someone who already has a working multi-turn system and is now hitting production limits on context length, cost, or latency. You should have a complete transcript segment ready for compression, along with a defined output schema that your application can parse and inject into the next context window as a session state preamble.

Use this prompt when you need to persist resolved decisions, pending actions, open questions, and key facts across context window boundaries. It is particularly effective in task-oriented assistants where dropping a commitment or forgetting a user preference has a direct product consequence. For example, a customer support copilot that has gathered troubleshooting steps over 20 turns can use this prompt to produce a JSON summary containing the issue type, steps taken, and unresolved questions before the history is truncated. The output is designed to be injected into the next context window as a session_state object, allowing the model to continue without replaying the full history. This prompt assumes you have a complete transcript segment and a defined output schema; it does not make real-time decisions about when to summarize.

Do not use this prompt for real-time turn-by-turn dialogue state tracking. It is a summarization step, not a dialogue state tracker. If you need slot-filling, intent tracking, or immediate reference resolution, use a dedicated state management prompt from the Turn History and Dialogue State Tracking group instead. Additionally, do not use this prompt on partial or streaming transcripts; it requires a complete segment to produce a faithful summary. For high-risk domains such as healthcare or legal workflows, you must pair this prompt with a faithfulness verification step that compares the generated summary against the source transcript and flags any hallucinated facts or dropped critical information. The companion prompt 'Summary Faithfulness Verification Prompt' in this content group provides a ready-to-use evaluation harness for this purpose. If your session contains PII or sensitive data, ensure redaction occurs before the transcript reaches the model, or use a local deployment where data does not leave your environment.

This prompt template is designed to be copied directly into your application code. It instructs the model to analyze a full conversation transcript and produce a structured JSON summary capturing resolved decisions, pending actions, open questions, and key facts. The output is intended for machine consumption—serialized into your session store, passed to downstream agents, or used to prime the system prompt when the context window resets. Before using this template, ensure you have a complete transcript and have defined your token budget for the summary itself.

textCopy
System: You are a precise session summarization engine. Your task is to read the provided conversation transcript and produce a structured JSON summary. The summary must be factually grounded in the transcript only. Do not infer, assume, or embellish information not explicitly present.

Input Transcript:
[FULL_TRANSCRIPT]

Output Schema:
{
  "session_id": "[SESSION_ID]",
  "summary_created_at": "[CURRENT_TIMESTAMP]",
  "participants": [
    {
      "role": "user | assistant | system",
      "identifier": "[PARTICIPANT_ID]"
    }
  ],
  "resolved_decisions": [
    {
      "decision": "[CLEAR_DECISION_TEXT]",
      "agreed_by": ["[PARTICIPANT_ID]"],
      "evidence_turn_ids": ["[TURN_ID]"]
    }
  ],
  "pending_actions": [
    {
      "action": "[ACTION_DESCRIPTION]",
      "owner": "[PARTICIPANT_ID | 'unassigned']",
      "deadline": "[DEADLINE_IF_MENTIONED | null]",
      "status": "pending | in_progress",
      "source_turn_id": "[TURN_ID]"
    }
  ],
  "open_questions": [
    {
      "question": "[QUESTION_TEXT]",
      "asked_by": "[PARTICIPANT_ID]",
      "status": "unanswered | partially_answered",
      "source_turn_id": "[TURN_ID]"
    }
  ],
  "key_facts": [
    {
      "fact": "[FACT_STATEMENT]",
      "stated_by": "[PARTICIPANT_ID]",
      "source_turn_id": "[TURN_ID]"
    }
  ],
  "conversation_summary": "[DENSE_1-3_SENTENCE_SUMMARY]",
  "unresolved_conflicts": [
    {
      "description": "[CONFLICT_DESCRIPTION]",
      "conflicting_turn_ids": ["[TURN_ID]", "[TURN_ID]"]
    }
  ]
}

Constraints:
[CONSTRAINTS]
- Only extract information explicitly stated in the transcript.
- If a category has no items, return an empty array.
- Use the exact turn IDs provided in the transcript.
- Do not alter the wording of decisions, facts, or questions unless necessary for clarity; preserve original meaning.
- The conversation_summary field must not introduce new information.

Examples of Good Extraction:
[FEW_SHOT_EXAMPLES]

Risk Level: [RISK_LEVEL]

To adapt this template for your application, replace the square-bracket placeholders with concrete values. [FULL_TRANSCRIPT] should contain the entire conversation, with each turn prefixed by a unique [TURN_ID] and the participant's role. [CONSTRAINTS] can be extended with domain-specific rules, such as 'prioritize safety-related decisions' or 'flag any mention of a legal agreement.' The [FEW_SHOT_EXAMPLES] placeholder is critical for production reliability—provide at least two examples of correctly extracted summaries from representative transcripts to anchor the model's behavior. Set [RISK_LEVEL] to high if the summary will drive automated actions (e.g., creating tickets, sending emails) and low if it is only for human review. For high-risk deployments, always run the output through a schema validator and a faithfulness verification step before acting on the extracted actions.

The Structured Session Summary prompt is designed to be called at a defined trigger point—typically when the conversation context window reaches a threshold (e.g., 80% of the model's limit) or when a session is explicitly paused. The application layer is responsible for assembling the full transcript, injecting it into the [FULL_TRANSCRIPT] placeholder, and providing the [OUTPUT_SCHEMA] as a strict JSON schema. Do not rely on the model to remember the schema from a system prompt; always include the schema inline in the user message or as a structured output constraint via the API's native JSON mode. The model should be instructed to output only the JSON object with no surrounding text or markdown fences.

After receiving the model's response, the application must run a validation pass before accepting the summary as the new session state. First, parse the JSON and validate it against the expected schema—reject any output missing required fields like resolved_decisions, pending_actions, or open_questions. Second, run a faithfulness check: for each claim in the summary, verify it has a corresponding span in the original transcript. A lightweight approach is to use a second LLM call with the Summary Faithfulness Verification Prompt from this pillar, but a deterministic check for hallucinated entity names or dates can catch common failures faster. If validation fails, retry the summarization call once with the error message appended to the prompt, instructing the model to correct the specific violation. If the retry also fails, log the raw transcript and the failed summary for human review and fall back to retaining the full transcript with a truncation warning.

The validated summary must be persisted as the new canonical session state, replacing the full transcript in the active context window. Store the full transcript in cold storage for audit and future fine-tuning data preparation. The application should also update the session's metadata with the summary timestamp, the compression ratio achieved, and the count of pending actions and open questions. This metadata enables downstream monitoring: track the average compression ratio over time to detect drift in summarization aggressiveness, and alert if the count of open questions grows monotonically across summaries, indicating the assistant is failing to resolve user queries. Wire the pending_actions and open_questions fields into the next turn's system prompt so the assistant can proactively re-surface unresolved items without requiring the user to repeat them.

For model choice, prefer models with strong instruction-following and JSON mode support. GPT-4o and Claude 3.5 Sonnet are reliable defaults for this task. If using a smaller model for cost reasons, increase the validation strictness and consider adding few-shot examples of correctly formatted summaries to the prompt. Avoid using this prompt on models without native JSON mode unless you implement a robust JSON extraction and repair layer. For high-stakes domains like healthcare or finance, always route failed validations to a human review queue and never auto-commit a summary that failed faithfulness checks. The summary is the system's memory; a corrupted summary will poison every subsequent turn.