Context Drift Detection and Correction Prompt

This prompt is built for reliability engineers and agent infrastructure developers who need to catch and correct silent reasoning failures in long-running, multi-turn tool-use agents. The core job-to-be-done is automated state reconciliation: comparing the agent's current assumptions and planned actions against the ground-truth state returned by external tools, then producing a structured correction plan. The ideal user is someone operating an agent in production who has observed quality degradation over extended sessions—hallucinated tool results, repeated calls with stale arguments, or plans that no longer match reality—and needs a programmatic checkpoint to restore coherence without restarting the session.

Use this prompt when an agent has completed more than a handful of tool calls and you need to verify that its internal reasoning still aligns with the actual state of external systems. It is appropriate for agents interacting with databases, APIs, file systems, or MCP servers where tool outputs represent a source of truth. The prompt requires the following inputs to be effective: the agent's current stated assumptions or plan, a log of recent tool calls and their actual results, and the system's defined state schema or expected invariants. Do not use this prompt for single-turn tool calls, stateless transformations, or workflows where the cost of a full state comparison exceeds the risk of drift. It is also a poor fit for real-time, latency-sensitive loops where the detection and correction cycle would violate a strict timeout budget.

Before deploying this prompt into an automated harness, you must define what constitutes a drift event for your specific application. A generic prompt will flag too many false positives or miss domain-specific inconsistencies. Work with your engineering team to establish concrete drift categories—such as schema mismatch, stale version identifiers, missing dependencies, or contradictory facts—and encode them in the [DRIFT_CATEGORIES] placeholder. The prompt's value is proportional to the precision of these definitions. For high-risk domains like finance or healthcare, the correction plan this prompt generates must never be auto-applied. Route its output to a human review queue or a restricted sandbox where proposed corrections are validated against the original tool outputs before execution.

This prompt template is designed to be injected at regular intervals during long-running agent sessions, or triggered when a tool call fails, returns unexpected results, or when the agent's confidence in its current state drops below a threshold. It forces the agent to explicitly list its operating assumptions, compare them against the actual tool state retrieved from the system of record, and produce a corrected state block that replaces the drifted context. The template uses square-bracket placeholders so you can adapt it to your specific tool ecosystem, state schema, and risk tolerance without rewriting the core logic.

textCopy
You are a context integrity monitor for an agent system. Your job is to detect and correct context drift by comparing the agent's current assumptions against ground-truth tool state.

## CURRENT AGENT ASSUMPTIONS
[AGENT_ASSUMPTIONS]

## GROUND-TRUTH TOOL STATE
[TOOL_STATE]

## STATE SCHEMA
[STATE_SCHEMA]

## DRIFT DETECTION RULES
- Compare each field in the agent's assumptions against the corresponding field in the ground-truth tool state.
- Flag any field where the agent's value differs from the ground truth, is missing, or is hallucinated.
- Ignore fields that are intentionally null or undefined in both sources.
- For each flagged field, classify the drift severity as: CRITICAL (would cause downstream tool failure), MODERATE (would degrade output quality), or MINOR (cosmetic or non-blocking).

## CORRECTION RULES
- For CRITICAL and MODERATE drift, produce the corrected value from the ground-truth tool state.
- For MINOR drift, note the discrepancy but do not block execution.
- If the ground-truth tool state is incomplete or unavailable for a required field, mark it as UNRESOLVED and recommend a tool call to retrieve the missing data.
- Do not invent or assume values not present in the ground-truth tool state.

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "drift_detected": boolean,
  "drift_summary": "One-sentence summary of findings",
  "drift_items": [
    {
      "field_path": "dot.notation.path.to.field",
      "assumed_value": "value from agent assumptions or null",
      "ground_truth_value": "value from tool state or null",
      "severity": "CRITICAL | MODERATE | MINOR",
      "correction": "corrected value or 'UNRESOLVED'",
      "recommended_action": "apply_correction | fetch_missing_data | ignore"
    }
  ],
  "corrected_state": {
    // Full corrected state object matching STATE_SCHEMA
  },
  "unresolved_fields": ["field_paths that need fetching"],
  "confidence": 0.0_to_1.0
}

## CONSTRAINTS
- Do not modify fields that match between assumptions and ground truth.
- If no drift is detected, return the original assumptions as the corrected_state.
- If [RISK_LEVEL] is HIGH, flag any UNRESOLVED field as CRITICAL and halt downstream execution.
- If [RISK_LEVEL] is LOW, allow execution to proceed with UNRESOLVED fields noted.

Adaptation guidance: Replace [AGENT_ASSUMPTIONS] with the agent's current working memory or state object, typically extracted from the last few turns of conversation or the agent's internal state store. [TOOL_STATE] should be populated by calling the authoritative tool or API immediately before invoking this prompt—do not rely on cached results older than the session's staleness threshold. [STATE_SCHEMA] must be a typed schema definition (JSON Schema, TypeScript interface, or structured field list) that defines required fields, optional fields, and their expected types. [RISK_LEVEL] should be set dynamically based on the downstream action: use HIGH for write operations, financial transactions, or clinical decisions; use LOW for read-only queries or informational outputs. For production use, wrap this prompt in a validation harness that checks the output JSON against the schema before the corrected state replaces the agent's working context.

The Context Drift Detection and Correction Prompt is designed to run as a sidecar evaluation step, not as part of the primary agent loop. It should be invoked by a monitoring service or a scheduled checkpoint within a long-running agent session. The prompt compares the agent's current working assumptions against a ground-truth snapshot of tool state, session metadata, and prior confirmed decisions. The output is a structured drift report that downstream systems can use to decide whether to pause the agent, inject a correction, or escalate for human review. This prompt is not a replacement for state validation at the tool-call level; it is a higher-order consistency check that catches reasoning drift that accumulates across multiple turns.

To wire this into an application, build a drift-check trigger that fires after every N tool calls, before high-risk actions, or when a session exceeds a time or token threshold. The harness must assemble two inputs: the agent's current belief state (extracted from conversation history, intermediate reasoning, or a dedicated state object) and the ground-truth tool state (pulled from a persistent store, tool result cache, or direct API query). Pass these into the prompt as [AGENT_BELIEF_STATE] and [GROUND_TRUTH_STATE]. The output must conform to a strict JSON schema with fields for drift_detected (boolean), drift_items (array of objects with field, believed_value, actual_value, severity), and correction_plan (array of recommended actions). Validate this schema before acting on the result. If the output fails schema validation, retry once with a stricter format instruction; if it fails again, log the failure and escalate to a human operator rather than silently continuing.

For high-stakes domains such as healthcare, finance, or infrastructure operations, always insert a human review gate when drift severity is critical or when the correction plan includes irreversible actions. Log every drift detection event with the full prompt input, output, schema validation result, and the action taken (ignore, auto-correct, escalate). This audit trail is essential for debugging false positives, tuning severity thresholds, and proving governance compliance. Avoid running this prompt on every turn in latency-sensitive paths; instead, batch drift checks or run them asynchronously. The most common production failure mode is a false drift alert caused by a stale ground-truth snapshot—always verify that the ground-truth state is fresher than the agent's last belief update before flagging a drift.