Assumption Drift Monitoring Prompt Template

Use this prompt when an agent or autonomous workflow runs for minutes, hours, or days and depends on assumptions that were true at planning time but may degrade silently. The core job-to-be-done is comparing the current execution state against a baseline set of planning assumptions and producing a structured drift report that flags which assumptions have weakened, which plan steps are now at risk, and whether replanning should be triggered. This is not a one-time pre-flight check. It is a scheduled runtime monitor that you wire into an agent loop, a step-transition gate, or a health-check interval. The ideal user is an AI engineer or platform developer building resilient agent runtimes where silent assumption decay causes confident but incorrect execution—think of a multi-hour data pipeline that assumes a schema hasn't changed, a research agent that assumes a source is still accessible, or a deployment agent that assumes a target environment hasn't been modified by another process.

You need several pieces of context to make this prompt work. First, a baseline assumption inventory—a structured list of assumptions with IDs, descriptions, categories, and initial confidence estimates, typically produced by an Assumption Inventory Generation prompt earlier in the planning phase. Second, current execution state, including what steps have completed, what outputs they produced, what tool calls succeeded or failed, and any new evidence that has arrived since planning. Third, drift thresholds that define how much confidence degradation or evidence contradiction constitutes actionable drift. Without these inputs, the prompt will either hallucinate assumptions that were never explicit or flag noise as drift. The prompt is designed for semi-structured JSON output—a drift report with affected assumption IDs, drift severity, impacted plan steps, and a recommended action (continue, gather evidence, replan, or escalate).

Do not use this prompt when the workflow is short-lived (under a few minutes), when assumptions are static and verifiable once at the start, or when the cost of a false drift flag is higher than the cost of letting execution continue. For single-step tool calls or request-response patterns, a pre-flight assumption check is sufficient. For workflows where assumption violations are catastrophic and irreversible, pair this prompt with a hard stop condition and human review rather than relying on drift detection alone. Also avoid this prompt when you lack a structured assumption inventory—running drift detection against implicit, undocumented assumptions produces noisy reports that erode operator trust. The next section provides the copy-ready prompt template you can adapt and embed directly into your agent runtime.

This prompt template is the core of your assumption drift monitoring module. It compares a stored baseline of planning assumptions against the latest execution state, tool outputs, and environmental evidence. The goal is to detect degradation before it causes downstream errors—not to generate a new plan. Paste this template into your agent runtime's monitoring loop, replacing the square-bracket placeholders with your application's actual data structures. The template is designed to produce a structured drift report that your execution engine can act on programmatically.

textCopy
You are an assumption drift monitor for an autonomous agent workflow. Your task is to compare the current execution state against a baseline set of planning assumptions and detect any drift that could compromise plan correctness.

## BASELINE ASSUMPTIONS
[ASSUMPTION_INVENTORY]

## CURRENT STATE
- Execution progress: [EXECUTION_PROGRESS]
- Recent tool outputs: [RECENT_TOOL_OUTPUTS]
- Environmental changes detected: [ENVIRONMENTAL_CHANGES]
- New evidence received: [NEW_EVIDENCE]
- Time elapsed since baseline: [TIME_ELAPSED]

## DRIFT DETECTION RULES
- An assumption has drifted if current evidence contradicts it, reduces its confidence below [CONFIDENCE_THRESHOLD], or if the assumption's validity window has expired.
- Ignore cosmetic changes that do not affect plan correctness.
- Flag assumptions that were previously validated but have aged beyond their [MAX_ASSUMPTION_AGE] without revalidation.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "drift_detected": boolean,
  "drifted_assumptions": [
    {
      "assumption_id": "string",
      "assumption_text": "string",
      "drift_type": "contradiction|confidence_drop|expired|missing_evidence",
      "current_evidence": "string",
      "severity": "blocking|warning|info",
      "affected_plan_steps": ["step_id"],
      "recommended_action": "revalidate|replan|escalate|ignore"
    }
  ],
  "stable_assumptions": ["assumption_id"],
  "unverifiable_assumptions": ["assumption_id"],
  "recommended_replanning_trigger": boolean,
  "summary": "string"
}

## CONSTRAINTS
- Do not invent assumptions not present in the baseline.
- If an assumption cannot be verified with available evidence, mark it as unverifiable rather than drifted.
- For [RISK_LEVEL] workflows, flag any unverifiable assumption as a warning by default.
- If drift is detected in any assumption that gates an irreversible step, set recommended_replanning_trigger to true.

## EXAMPLES
[DRIFT_DETECTION_EXAMPLES]

Analyze the current state against the baseline assumptions and return the drift report.

After pasting this template, you must wire the output into your agent's control loop. If drift_detected is true, route the drifted_assumptions array to your replanning module or human review queue based on severity. For blocking severity items, halt execution of affected plan steps immediately. For warning severity, log the drift and continue with caution, but increment a drift counter—if it exceeds your configured threshold, escalate. The unverifiable_assumptions field is your early-warning system: a growing list of unverifiable items often precedes actual drift. Store each drift report alongside the execution trace for post-mortem analysis and false-alarm tuning. Avoid the mistake of treating this prompt as a one-shot check; run it at regular intervals and after any significant state change.

The Assumption Drift Monitoring Prompt is not a one-shot call; it is a recurring checkpoint that must be wired into the agent's execution loop. The harness should invoke this prompt at configurable intervals—after every N steps, before each irreversible action, or when a monitoring signal (e.g., tool failure rate, unexpected output schema) crosses a threshold. The prompt compares the current execution state against a stored baseline of assumptions, each with an ID, category, original confidence, and last-validated timestamp. The harness is responsible for maintaining this baseline, injecting it into the prompt's [BASELINE_ASSUMPTIONS] placeholder, and capturing the resulting drift report for downstream decision-making.

The harness must enforce a strict output contract. The prompt returns a structured drift report containing a drift_detected boolean, an array of drifted_assumptions with assumption_id, drift_severity (low, medium, high, critical), evidence_summary, and recommended_action (ignore, revalidate, replan, escalate, abort). Implement a post-processing validator that checks: (1) every assumption_id in the drift report maps to a known baseline assumption, (2) drift_severity is a valid enum value, and (3) recommended_action is consistent with severity (e.g., critical severity must not recommend ignore). If validation fails, retry once with the validation error injected into [PREVIOUS_ERRORS]. If the retry also fails, escalate to a human operator with the raw output and validation trace. Log every invocation—baseline snapshot, prompt version, model, latency, drift report, and action taken—for audit and threshold tuning.

Drift thresholds should be configurable per assumption category, not hardcoded in the prompt. For example, security-related assumptions might trigger escalation at medium severity, while formatting assumptions might only trigger at high. Store these thresholds in a configuration object and implement a decision layer between the drift report and the agent's control loop. This layer reads the report, applies category-specific thresholds, and determines the actual execution impact: pause the agent, flag specific plan steps for replanning, request human approval, or continue with logged warnings. To tune false-alarm rates, track the ratio of escalated drift events to actual plan failures over time and adjust thresholds accordingly. Avoid wiring drift detection directly to abort without human review for the first N production runs—use a shadow mode where drift is logged and alerted but does not block execution until the thresholds are calibrated against real operating data.