Session Context Loss Root-Cause Analysis Prompt

Use this prompt when a user reports that an AI assistant 'forgot' previously provided information, preferences, or context during a multi-turn conversation. The job-to-be-done is a structured root-cause analysis that distinguishes between three distinct failure modes: context window overflow (the information was pushed out of the model's attention window), premature summarization (a compression step discarded critical details), and state hydration failure (the application layer failed to load or correctly deserialize the saved session state). The ideal user is an AI reliability engineer, a platform SRE, or a developer on the conversational AI team who has access to raw turn-level trace data and session configuration metadata.

This prompt is not a general-purpose debugging tool. Do not use it when you lack a complete trace export that includes every user message, every assistant response, every tool call, and the session state snapshots at turn boundaries. It is also inappropriate for diagnosing latency issues, token cost overruns, or safety policy violations—those require separate, specialized trace review prompts. The analysis assumes the assistant's architecture uses some form of state management, whether in-application memory, a database, or a context-carrying mechanism. If your system is stateless by design, the root cause is architectural, and this prompt will not add value.

Before running this prompt, assemble the required inputs: a full turn-level trace in a structured format (JSON or JSONL is preferred), the session's configuration metadata (context window size, summarization model and threshold, state serialization format), and the specific user report describing what context was lost and at which point in the conversation. The prompt will produce a structured root-cause report with a primary classification, supporting evidence from the trace, and a confidence score. For high-severity incidents where the context loss caused a compliance or safety issue, always route the output for human review before closing the incident. The next step after receiving the analysis is to implement the recommended remediation, which may involve adjusting summarization thresholds, increasing the context budget, or fixing state hydration logic in the application layer.

The prompt below is designed to be copied directly into your AI harness, observability pipeline, or internal debugging tool. It accepts a raw multi-turn trace and session configuration metadata, then produces a structured root-cause analysis report. Every placeholder is enclosed in square brackets and must be replaced with real data before execution. The prompt forces the model to distinguish between three primary failure modes—context window overflow, premature summarization, and state hydration failure—rather than allowing a vague 'the assistant forgot' explanation.

textCopy
You are an AI reliability engineer reviewing a production conversation trace where a user reported that the assistant lost context. Your job is to produce a structured root-cause analysis that identifies the exact failure mechanism, the turn where context was lost, and the evidence supporting your conclusion.

## INPUTS

### Conversation Trace
[FULL_MULTI_TURN_TRACE]

### Session Configuration
- Max context window tokens: [MAX_CONTEXT_WINDOW_TOKENS]
- Summarization trigger threshold tokens: [SUMMARIZATION_THRESHOLD_TOKENS]
- Summarization model or method: [SUMMARIZATION_METHOD]
- State hydration mechanism: [STATE_HYDRATION_MECHANISM]
- Session start timestamp: [SESSION_START_TIME]

### User Report
[USER_REPORT_OF_CONTEXT_LOSS]

## ANALYSIS INSTRUCTIONS

1. Parse the full trace into individual turns, labeling each with turn number, role, token count, and a one-line summary of content.
2. Identify the earliest turn where the assistant's response demonstrates loss of previously established context. Cite the specific user utterance that was forgotten and the assistant response that reveals the loss.
3. Classify the root cause into exactly one of the following categories:
   - **Context Window Overflow**: The forgotten context was pushed out of the context window by newer turns. Provide the token count at the turn where overflow occurred and confirm that the forgotten context fell outside the window.
   - **Premature Summarization**: A summarization step compressed or omitted the critical context before it was needed. Identify the summarization event, the summary content, and what was lost.
   - **State Hydration Failure**: The assistant's session state was not correctly loaded, deserialized, or applied at a turn boundary. Identify the turn where state was expected to be present but was missing or corrupted.
   - **Other**: A different failure mode not listed above. Describe the mechanism with equal specificity.
4. For the identified root cause, provide:
   - The exact turn number where context loss occurred.
   - The specific context that was lost.
   - The downstream impact: which subsequent turns were affected and how.
   - A confidence score from 0.0 to 1.0.
5. If the evidence is ambiguous between two categories, list the alternative hypothesis and explain why it was not selected.
6. Recommend one actionable fix, such as increasing context window, adjusting summarization thresholds, adding state validation on hydration, or instrumenting additional logging.

## OUTPUT SCHEMA

Return a JSON object with this exact structure:
{
  "trace_summary": {
    "total_turns": <integer>,
    "total_tokens_consumed": <integer>,
    "session_duration_seconds": <integer>
  },
  "context_loss_event": {
    "turn_number": <integer>,
    "lost_context": "<string describing what was forgotten>",
    "assistant_response_showing_loss": "<verbatim excerpt>",
    "root_cause_category": "context_window_overflow | premature_summarization | state_hydration_failure | other",
    "root_cause_description": "<detailed explanation>",
    "confidence": <float 0.0-1.0>
  },
  "alternative_hypothesis": {
    "category": "<string or null>",
    "explanation": "<string or null>"
  },
  "downstream_impact": {
    "affected_turns": [<list of turn numbers>],
    "impact_description": "<string>"
  },
  "recommended_fix": "<actionable recommendation>"
}

## CONSTRAINTS

- Do not speculate beyond the evidence in the trace.
- If token counts are not provided in the trace, estimate them conservatively and note that estimates were used.
- If the trace is incomplete, flag what is missing and reduce confidence accordingly.
- Do not fabricate turn content. Quote verbatim from the trace.
- If no context loss is detected, set root_cause_category to "none_detected" and explain why the user may have perceived a loss.

To adapt this prompt for your environment, replace each square-bracket placeholder with real data from your tracing system. The [FULL_MULTI_TURN_TRACE] should include raw turn data with role labels, timestamps, and token counts if available. If your tracing system does not capture token counts per turn, modify the prompt to instruct the model to estimate from character counts, but always flag that estimates were used. The output schema is strict JSON to enable automated ingestion into your incident management pipeline. Before deploying, test this prompt against at least three known context-loss incidents and one negative case where no loss occurred to calibrate the confidence scoring and verify that the model does not hallucinate loss events.

This prompt is designed to be invoked programmatically as part of an automated incident response or a manual QA review queue. The primary integration point is a trace ingestion service that fetches turn-level data and session configuration metadata from your observability platform (e.g., LangSmith, Arize, or a custom trace store). Before calling the LLM, the harness must validate that the [TRACE_DATA] payload contains the minimum required fields: a unique session_id, a list of turns with role, content, and timestamp, and a session_config object that includes context_window_limit and summarization_strategy. If these fields are missing, the harness should reject the request immediately and log a MISSING_TRACE_SCHEMA error rather than sending incomplete data to the model.

The harness should implement a two-stage validation pipeline. First, a structural validator checks that the input JSON conforms to the expected schema and that timestamps are monotonically increasing. Second, a content sanity checker verifies that the trace contains at least one user turn and that the session duration is plausible (e.g., not spanning negative time). After the LLM returns its root-cause classification and evidence, a post-processing validator must confirm that the output contains the required fields: root_cause_category (one of context_window_overflow, premature_summarization, state_hydration_failure, or other), confidence_score (0.0–1.0), evidence_turns (an array of turn indices), and diagnosis_rationale. If the model output fails this validation, the harness should retry once with a stricter output format instruction appended to the prompt. If the retry also fails, the trace should be routed to a human review queue with the raw model output attached.

For model selection, use a model with strong structured output capabilities and a context window large enough to hold the full trace plus the analysis instructions. GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Set temperature to 0.0 to maximize reproducibility, and enable JSON mode or structured outputs if the provider supports it. The harness should log every invocation—including the prompt version, model, input trace ID, output classification, confidence score, and latency—to a dedicated analysis log table. This log becomes the audit trail for root-cause trends and model performance over time. Avoid using this prompt on traces that contain PII unless the data has been redacted upstream; the harness should check for common PII patterns and either reject or sanitize before sending.