Conversation History Summarization Demonstration Prompt

This prompt is designed for teams building long-running AI assistants that must operate within tight context windows. Its primary job is to compress a verbose, multi-turn conversation history into a dense, structured summary that preserves critical state—decisions made, unresolved questions, and explicit user preferences—while safely discarding greetings, repetitions, and resolved tangents. The ideal user is an AI engineer or backend developer integrating this summarization step into an agent loop or a chat application, where the summary becomes the new system state for subsequent turns.

You should use this prompt when the cost of lost context is high. This includes customer support sessions where a handoff to a human agent requires a perfect state transfer, multi-step sales or advisory conversations where user constraints evolve, and any long-running task where the model needs to 'remember' what was decided ten turns ago. The prompt relies on few-shot examples to demonstrate the desired density and structure, making it more reliable than purely instructional prompts for this task. You must provide at least two high-quality conversation-to-summary pairs in the [EXAMPLES] block that clearly show what to keep and what to drop.

Do not use this prompt for real-time, turn-by-turn processing where latency is critical; a full-history summarization call is typically a background or pre-turn step. It is also unsuitable for conversations that require verbatim retention of specific phrases, such as legal testimony or exact creative copy, where a retrieval-augmented generation (RAG) approach with the full transcript is safer. Finally, this prompt is not a replacement for a persistent database of user facts; it is a lossy compression step. You should always implement a validation harness that checks the output summary for hallucinated decisions or preferences that were not present in the input conversation, as this is the most common production failure mode.

This prompt template is designed to be copied directly into your application or prompt management system. It uses square-bracket placeholders for all variable inputs, making it easy to swap in real conversation data, output schemas, and constraints without rewriting the core instruction. The template focuses on teaching the model what to preserve (decisions, unresolved items, user preferences) and what to drop (small talk, redundant information) through structured demonstration pairs rather than verbose rules.

textCopy
You are a conversation summarizer for a long-running assistant. Your task is to compress the provided conversation history into a structured summary that preserves critical information and discards transient chatter.

## INPUT CONVERSATION
[CONVERSATION_HISTORY]

## OUTPUT SCHEMA
Return a JSON object with the following fields:
{
  "summary": "A concise narrative summary of the conversation's purpose and outcome.",
  "key_decisions": ["List of decisions made, with who made them if known."],
  "unresolved_items": ["List of questions, tasks, or conflicts that remain open."],
  "user_preferences": ["Explicit or strongly implied user preferences, constraints, or style choices."],
  "action_items": [{"owner": "string", "task": "string", "deadline": "string or null"}],
  "critical_facts": ["Verifiable facts, numbers, dates, or references that must not be lost."]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
Below are demonstration pairs showing how to convert conversations into summaries.

### Example 1: Simple Decision
**Input:**
User: I need to change the dashboard refresh rate to 30 seconds.
Assistant: The current setting is 60 seconds. I can change that for you. Should I apply this to all users or just your account?
User: Just my account for now. Let's test it first.
Assistant: Done. Your personal dashboard will now refresh every 30 seconds. I've noted this as a test change.

**Output:**
{
  "summary": "User requested and received a dashboard refresh rate change from 60s to 30s for their account only as a test.",
  "key_decisions": ["Changed dashboard refresh rate to 30 seconds for user's account only."],
  "unresolved_items": [],
  "user_preferences": ["Prefers to test changes on own account before broader rollout."],
  "action_items": [],
  "critical_facts": ["Previous refresh rate: 60 seconds. New refresh rate: 30 seconds. Scope: single account."]
}

### Example 2: Unresolved Discussion
**Input:**
User: Can you analyze the Q3 sales data and tell me why the West region underperformed?
Assistant: I'll need access to the Q3 sales database. Do you want me to pull data from the CRM or the data warehouse?
User: Use the data warehouse. And compare it against Q2 for the same region.
Assistant: Understood. I'll query the data warehouse for West region sales in Q2 and Q3. This may take a few minutes. I'll also need to know which metrics you care about most—revenue, units, or customer acquisition?
User: Revenue and customer acquisition. Let's start there.
Assistant: Got it. I'm pulling revenue and customer acquisition data for the West region, Q2 vs Q3, from the data warehouse. I'll report back when the analysis is ready.

**Output:**
{
  "summary": "User requested analysis of West region Q3 underperformance compared to Q2. Assistant is pulling revenue and customer acquisition data from the data warehouse.",
  "key_decisions": ["Data source: data warehouse. Metrics: revenue and customer acquisition. Comparison period: Q2 vs Q3."],
  "unresolved_items": ["Root cause of West region underperformance not yet determined. Analysis query still in progress."],
  "user_preferences": ["Prefers data warehouse over CRM for analytical queries."],
  "action_items": [{"owner": "Assistant", "task": "Complete West region Q2 vs Q3 revenue and customer acquisition analysis", "deadline": null}],
  "critical_facts": ["Region: West. Periods: Q2 and Q3. Metrics: revenue, customer acquisition. Data source: data warehouse."]
}

[ADDITIONAL_EXAMPLES]

## INSTRUCTIONS
Using the examples above as your guide, summarize the INPUT CONVERSATION into the OUTPUT SCHEMA format. Follow all CONSTRAINTS. Do not invent information not present in the conversation. If a field has no applicable data, return an empty array.

To adapt this template for your own system, replace [CONVERSATION_HISTORY] with your actual turn-by-turn chat log, formatted consistently with clear role markers. The [CONSTRAINTS] placeholder should be replaced with any domain-specific rules, such as maximum summary length, required fields, or compliance requirements. The [ADDITIONAL_EXAMPLES] placeholder lets you inject more demonstration pairs that reflect your specific conversation patterns—this is where you teach the model your team's definition of a "decision" versus an "action item." After copying the template, run it against a golden dataset of known conversations and compare the structured output against expected summaries to validate that the model is preserving the right information and not hallucinating additions.

This prompt is designed to sit inside a context-compression pipeline for long-running assistants. The typical integration point is a context window manager that triggers summarization when the conversation history exceeds a token threshold. The application layer should extract the raw conversation turns from your chat store, inject them into the [CONVERSATION_HISTORY] placeholder, and replace the [SUMMARY_SCHEMA] with a structured output specification that matches your downstream context format. Do not pass the entire raw history directly to the model without first truncating to the most recent N turns that fit within your summarization budget—this prompt is a compressor, not a full-context reader.

Validation and retry logic must be implemented at the application layer, not inside the prompt. After receiving the model output, validate that the summary contains all required fields from your schema (e.g., decisions, unresolved_items, user_preferences, key_facts). Check for hallucinated additions by diffing any claimed facts against the source conversation turns using a lightweight string-match or embedding-similarity check. If the summary fails validation—missing required fields, containing unsupported claims, or exceeding a maximum length—retry once with the same prompt but append the validation errors as a [CORRECTION_FEEDBACK] block. After two failed retries, log the failure and fall back to a simpler truncation strategy (keep the last K messages as-is) rather than blocking the user. For high-stakes domains like healthcare or legal, route failed summaries to a human review queue instead of silently degrading.

Model selection matters for this workflow. Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) rather than a smaller or faster model that may drop fields or hallucinate under long-context pressure. If latency is critical, consider running the prompt on a fast model for low-risk conversations and escalating to a stronger model when the validation step detects quality issues. Logging and observability should capture: the input token count, output token count, validation pass/fail status, retry count, and a hash of the summary for deduplication. Store these metrics alongside the conversation ID so you can trace summarization quality degradation over time and detect when your prompt or model version needs updating.

Tool use and RAG are not required for this prompt's core function—it operates on the provided conversation text alone. However, if your assistant maintains a persistent user profile or knowledge base, you may optionally inject relevant user preferences or domain facts into the [CONTEXT] placeholder to help the model distinguish between new information and previously known facts. Do not use this prompt for real-time conversation turn generation; it is a batch compression step that runs asynchronously between conversation turns or during session handoff. Wire it into your context assembly pipeline so that the compressed summary replaces older turns in the model's context window, and always preserve the most recent 2-3 turns in full to avoid losing immediate conversational coherence.