Stale Context Detection and Refresh Prompt

This prompt is for conversation AI engineers who manage long-running sessions where the model's working context—retrieved documents, user facts, or prior tool outputs—can become outdated without explicit user notification. The job-to-be-done is automated staleness detection: the prompt instructs the model to evaluate whether the current context is still valid for the user's next request, and if not, to produce a structured refresh decision that preserves essential session state while discarding or re-retrieving stale information. The ideal user is an engineer building a production assistant, copilot, or agent that maintains state across many turns, where silent context decay causes wrong answers, repeated corrections, or user frustration.

Use this prompt when your application maintains a context payload that includes time-sensitive data such as search results, API responses, user profile fields, or conversation summaries that may age out. It is appropriate for systems where the cost of operating on stale context is higher than the cost of running a detection step—for example, customer support copilots referencing a knowledge base that updates daily, coding agents working against a repository that receives new commits, or research assistants synthesizing news that changes hourly. The prompt expects a [CONTEXT] block containing the current session state, a [USER_REQUEST] representing the next user turn, and optional [STALENESS_RULES] that define domain-specific freshness thresholds.

Do not use this prompt when context freshness is guaranteed by the application architecture—for instance, when every turn triggers a fresh retrieval step, when the session is stateless, or when the context is immutable by design. It is also the wrong tool for detecting factual errors in the model's own generated content; that belongs to a hallucination self-check prompt. Avoid this prompt in latency-sensitive real-time flows where the detection step adds unacceptable delay, or when the staleness rules are so ambiguous that the model cannot make a reliable binary decision. In high-stakes domains such as healthcare or finance, pair this prompt with human review of the refresh decision and log every staleness verdict with the evidence that triggered it.

Before implementing, define what 'stale' means for your system. Is a document stale after 10 minutes? After a new version is published? When a user's account tier changes? Encode these rules in [STALENESS_RULES] as explicit, testable conditions. The output should be a machine-readable decision—either continue with existing context or refresh with a list of what to discard and what to re-retrieve—so your application can act on it without human parsing. Start by testing against a golden dataset of known-stale and known-fresh context pairs, and measure both staleness-detection accuracy and context-preservation fidelity before deploying to production.

This prompt template is designed to be inserted into your system instructions or used as a dedicated evaluation step in a long-running conversation agent. Its job is to analyze the current session state, identify information that is likely outdated or contradicted, and produce a decision object that your application can use to either continue, refresh specific context, or escalate for human review. The prompt uses square-bracket placeholders for all dynamic inputs, making it straightforward to wire into your existing prompt assembly pipeline.

textCopy
You are a context-staleness detector for a long-running AI assistant session. Your task is to analyze the current conversation state and determine whether any previously established context is now stale, outdated, or contradicted by more recent information.

## INPUTS

### Current Session State
[SESSION_STATE]

### Recent User Messages (last N turns)
[RECENT_USER_MESSAGES]

### Recent Assistant Actions and Observations
[RECENT_ASSISTANT_ACTIONS]

### Staleness Detection Rules
[STALENESS_RULES]

### Output Schema
[OUTPUT_SCHEMA]

### Risk Level
[RISK_LEVEL]

## INSTRUCTIONS

1. Review the current session state and identify any facts, preferences, decisions, or constraints that were established earlier in the conversation.
2. Compare these established items against the recent user messages and assistant actions. Look for:
   - Direct contradictions (user says something that conflicts with prior state)
   - Implicit staleness (time-sensitive information that has aged beyond its useful window)
   - Context shifts (user has clearly moved to a new topic or goal that invalidates prior constraints)
   - Tool-call results that supersede earlier retrieved information
3. For each potentially stale item, determine whether it should be:
   - **DISCARDED**: Remove entirely from session state
   - **REFRESHED**: Re-fetch or re-confirm with the user or a tool
   - **RETAINED**: Keep as-is because it remains valid
4. Generate a structured output following the exact output schema provided.

## CONSTRAINTS

- Do not discard context that is merely old but still relevant and uncontradicted.
- When uncertain, flag the item for human review rather than silently discarding it.
- Preserve essential session identity (user ID, session ID, conversation start time) regardless of staleness.
- If [RISK_LEVEL] is "high", require explicit user confirmation before discarding any context that affects decisions, commitments, or compliance-relevant information.
- Do not fabricate staleness reasons. Only flag items where you can point to specific contradictory or time-expired evidence.

To adapt this template for your application, replace each square-bracket placeholder with your actual data and constraints. The [SESSION_STATE] should contain your serialized conversation memory, including established facts, user preferences, and pending actions. The [STALENESS_RULES] placeholder lets you inject domain-specific rules, such as "financial data older than 24 hours is stale" or "user location preferences expire at session end." The [OUTPUT_SCHEMA] should define the exact JSON structure your application expects, including fields for staleness_detected (boolean), stale_items (array of objects with item_id, reason, and action), and refresh_requests (array of tool calls or clarification questions). For high-stakes domains like healthcare or finance, set [RISK_LEVEL] to "high" and ensure your application enforces human review on any discard actions before executing them.

The Stale Context Detection and Refresh Prompt is designed to be called as a pre-turn gate in long-running conversation loops. Before the main assistant processes a new user message, the application should invoke this prompt with the current session summary, the last N turns, and any time-since-last-activity metadata. The prompt returns a structured decision: either stale: false (proceed normally) or stale: true with a refresh_request payload that specifies what context to preserve and what to discard. This gate prevents the main assistant from reasoning over outdated information that could cause contradictory responses, repeated questions, or incorrect assumptions about user state.

Integration pattern: Wrap the detection call in a lightweight harness that enforces a strict JSON output schema. Use response_format with a defined JSON schema on models that support it, or apply a post-generation validator that rejects malformed outputs and retries once. The harness should log every detection decision—including the staleness score, the reason, and the refresh payload—to your observability stack so you can monitor false-positive and false-negative rates over time. For high-stakes domains (healthcare, finance, legal), route stale: true decisions to a human reviewer queue when the confidence field falls below a configured threshold, rather than automatically discarding context.

Model selection and latency: This prompt is a classification-plus-generation hybrid. Use a fast, cost-effective model (e.g., a small Claude Haiku or GPT-4o-mini variant) for the detection step, reserving larger models for the main assistant turn. The detection call should complete in under 500ms to avoid degrading the user experience. If the detection model is unavailable, implement a fail-open fallback: proceed with the full context but attach a warning flag so the main assistant can apply extra caution. Never fail-closed and block the user on a detection infrastructure error.

Context refresh execution: When stale: true is returned, the application must execute the refresh before calling the main assistant. This means trimming the conversation history to only the turns listed in preserved_turns, updating the session summary with the preserved_summary field, and discarding everything else. Do not pass the raw refresh_request to the main assistant—the application layer owns context assembly. After refresh, log the before-and-after token counts to measure context savings and verify that essential state was preserved. Run periodic evals comparing assistant response quality with and without the refresh gate to confirm the detection prompt isn't introducing regressions.