Session Summary Generation Prompt for Long Conversations

This prompt is designed for developers and infrastructure engineers building autonomous or semi-autonomous agents that conduct extended, multi-turn tool-use sessions. Its primary job is to compress a verbose history of tool calls, their arguments, outcomes, and errors into a dense, structured context block. This summary is then injected into a subsequent prompt to maintain the agent's situational awareness without exceeding context window limits. The ideal user is someone integrating this into an agent harness where context budgets are tight and the cost of lost detail is high—such as a coding agent working through a multi-file refactor or a research agent synthesizing data from dozens of API calls.

Use this prompt when a conversation or tool-use session has exceeded a predefined token threshold, when preparing a handoff summary for another agent, or when creating a checkpoint before a high-risk operation. It is specifically built for sessions where the sequence of tool calls and their results is the critical information to preserve. Do not use this prompt for simple chat history summarization where tool use is absent, or for summarizing creative writing. It is also inappropriate for real-time, low-latency applications where the cost of an extra summarization step outweighs the context savings. The prompt assumes the input is a structured log of tool interactions, not a free-form dialogue.

Before implementing this prompt, ensure your harness can reliably extract the full tool call history, including arguments and raw results. The primary failure mode is the omission of a critical detail—like a specific error code or a returned file path—that downstream tool calls depend on. Therefore, this prompt is a component in a larger system that should include an evaluation step to check the summary against the original history for completeness. If your workflow involves high-stakes actions like database writes, code commits, or financial transactions, a human review step on the generated summary is a required control before it re-enters the agent's active context.

This template is the core instruction set for generating a structured session summary from an extended, multi-turn tool-use conversation. It is designed to be dropped into your agent's context assembly pipeline when the conversation history exceeds your context budget or when a downstream agent or human reviewer needs a compact, trustworthy record of what happened. The prompt forces the model to extract tool calls, outcomes, errors, and pending actions into a typed schema, rather than producing a vague prose summary that hides critical details.

textCopy
You are a session summarizer for an AI agent that uses external tools. Your job is to compress the provided conversation history into a structured summary object. The summary must be accurate, lossless regarding critical tool outcomes, and must never invent tool results that are not present in the history.

## INPUT
- Conversation History: [CONVERSATION_HISTORY]
- Current Session State: [SESSION_STATE]
- Pending Actions Queue: [PENDING_ACTIONS]

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "session_id": "string, the session identifier",
  "summary_timestamp": "string, ISO 8601 timestamp of summary generation",
  "user_intent": "string, concise summary of the user's original and evolved goals",
  "key_decisions": [
    {
      "decision": "string, what was decided",
      "rationale": "string, why it was decided based on tool outputs",
      "turn": "integer, the conversation turn where the decision was made"
    }
  ],
  "tool_call_log": [
    {
      "tool_name": "string",
      "arguments": "object, the arguments passed",
      "result_summary": "string, condensed but accurate summary of the result",
      "status": "success | failure | timeout | pending",
      "error_details": "string | null, error message if status is failure or timeout",
      "turn": "integer"
    }
  ],
  "data_artifacts": [
    {
      "artifact_id": "string, unique identifier for the data",
      "source_tool": "string, which tool produced it",
      "summary": "string, what the artifact contains",
      "expiry_turn": "integer | null, turn after which this data may be stale"
    }
  ],
  "pending_actions": [
    {
      "action": "string, what needs to happen next",
      "depends_on": ["string, artifact_id or tool_call that must complete first"],
      "priority": "high | medium | low"
    }
  ],
  "errors_and_anomalies": [
    {
      "description": "string, what went wrong",
      "severity": "blocking | degraded | warning",
      "turn": "integer"
    }
  ],
  "context_health": {
    "stale_artifacts": ["string, artifact_ids that may be outdated"],
    "missing_dependencies": ["string, required data not yet retrieved"],
    "budget_remaining_tokens": "integer | null, estimated remaining context tokens"
  }
}

## CONSTRAINTS
- Do not hallucinate tool results. If a tool call's output is not in the history, set status to "unknown" and note it in errors_and_anomalies.
- Preserve exact argument values where they are critical for debugging (e.g., IDs, query strings).
- If the conversation history is truncated, note the truncation point in context_health.
- Prioritize recent turns but do not drop decisions or errors from earlier turns.
- If [RISK_LEVEL] is "high", flag any irreversible actions taken in key_decisions and require human review before the summary is used as source-of-truth.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Now, generate the session summary for the provided conversation history.

To adapt this template, replace the square-bracket placeholders with your application's runtime values. [CONVERSATION_HISTORY] should be the full or truncated message array. [SESSION_STATE] is your application's structured state object. [PENDING_ACTIONS] is the queue of tool calls the agent intends to make next. [FEW_SHOT_EXAMPLES] should contain 1-3 examples of correctly formatted summaries for your specific tool set, which dramatically improves schema adherence. [RISK_LEVEL] should be set to "high" if the session includes destructive actions like database writes, payment processing, or user data modification; this triggers the human-review flag in the output. Before deploying, validate the output against the schema in your application layer and run eval checks for hallucinated tool results, dropped errors, and missing pending actions. If the summary will be used to rehydrate agent state later, pair this prompt with the Session Rehydration from Persistent Store Prompt Template to close the loop.

The session summary prompt is not a standalone utility; it is a state-compression function inside a larger agent harness. It should fire when the context window approaches a configured threshold (e.g., 80% of the model's limit) or when a tool-call turn count is exceeded. The harness must supply the full conversation transcript, tool-call history with arguments and results, and any pending action items as the [FULL_SESSION_TRANSCRIPT] input. The [SUMMARY_SCHEMA] placeholder should be populated with a strict JSON schema that includes fields for decisions_made, pending_actions, tool_results_summary, key_facts, and open_questions. Do not call this prompt on every turn; doing so adds latency and risks summary drift where errors compound across successive compressions.

Wire the prompt into an application as a pre-call middleware function. Before the next user or tool turn, check the token count of the current context. If it exceeds the threshold, extract the full transcript, inject it into the prompt template, and call a model with structured output enforcement (e.g., response_format or a JSON mode flag). Validate the returned summary against the [SUMMARY_SCHEMA] using a JSON schema validator. If validation fails, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, log the failure, fall back to a simpler truncation strategy (e.g., keep the last N messages), and alert the operations team. Store the validated summary in the session state object and replace the compressed portion of the conversation with a single system message containing the summary text.

For high-stakes domains such as healthcare or finance, insert a human review step before the summary replaces live context. The harness should serialize the proposed summary and the original transcript segment into a review queue, pause the agent's autonomous execution, and wait for approval or correction. Log every summary generation event with the pre-compression token count, the post-compression token count, the model used, the validation result, and a hash of the input transcript for later audit. Avoid the common failure mode of summarizing tool results without preserving error codes or exact values; the schema must require that tool errors and quantitative results are carried forward verbatim, not paraphrased. The next step after implementing this harness is to build an eval pipeline that compares summary fidelity against the original transcript using an LLM judge, checking for dropped decisions, hallucinated tool results, and missing pending actions.