Agent Plan Staleness Detection and Refresh Prompt

This prompt is designed for long-running autonomous agents whose execution spans minutes, hours, or days. During that window, the external world—database schemas, file systems, API endpoints, user permissions, or dependent service states—can change. When an agent continues executing a plan that assumes a now-invalid state, the result is wasted resources, incorrect outputs, or cascading tool failures that require expensive manual intervention. The staleness detection prompt compares the original plan's assumptions against current state observations and produces a structured assessment of which plan steps remain valid, which are stale, and what a refreshed plan segment should look like. The primary job-to-be-done is preventing silent plan decay before the agent takes another action.

Use this prompt inside an agent harness that can inject two critical inputs: (1) the original plan with its explicit assumptions about external state, and (2) current state observations gathered from the environment (e.g., schema introspection, file existence checks, API health probes, permission audits). The harness should also supply a history of completed steps so the refresh preserves finished work rather than restarting. Do not use this prompt for short-lived, single-turn tasks where the plan cannot go stale before completion—adding staleness checks to a sub-second API call adds latency without benefit. Similarly, avoid this prompt when the agent operates in a fully static environment where external state changes are impossible by design.

Before wiring this into production, define staleness severity thresholds that determine whether the agent should auto-refresh and continue, pause for human review, or abort entirely. A schema column rename might be auto-recoverable; a revoked production credential should trigger immediate escalation. Pair this prompt with eval checks that verify the refreshed plan preserves completed work, correctly identifies stale assumptions, and does not introduce new steps that conflict with the current state. If your agent operates in regulated or high-risk domains, require human approval on the refreshed plan segment before execution resumes.

This template is designed to be pasted directly into your agent harness when a long-running agent's plan may have become invalid due to external state changes. It instructs the model to assess staleness, identify which assumptions are obsolete, and produce a refreshed plan segment without discarding work that has already been completed. Replace every square-bracket placeholder with runtime values before sending the prompt to the model.

textCopy
You are an agent plan auditor. Your task is to detect staleness in an agent's execution plan and produce a refreshed plan segment when the original plan is no longer valid.

[ORIGINAL_PLAN]
[COMPLETED_STEPS]
[CURRENT_STATE]
[EXTERNAL_CHANGES]

# Instructions
1. Compare the [ORIGINAL_PLAN] against [CURRENT_STATE] and [EXTERNAL_CHANGES].
2. Identify every assumption in the original plan that is now obsolete, invalid, or contradicted by new evidence. List each obsolete assumption with a one-sentence explanation of why it is stale.
3. Determine which steps in [COMPLETED_STEPS] remain valid and do not need to be repeated. List them explicitly as preserved progress.
4. Generate a refreshed plan segment that replaces only the stale portions of the original plan. The refreshed segment must:
   - Preserve the original goal stated in [ORIGINAL_PLAN].
   - Reuse any valid completed steps without re-executing them.
   - Propose new steps only for the portions of the plan affected by staleness.
   - Respect all constraints from [CONSTRAINTS].
5. If no staleness is detected, respond with {"staleness_detected": false, "reasoning": "<brief explanation>"} and do not generate a refreshed plan.

[CONSTRAINTS]
[OUTPUT_SCHEMA]

Adaptation notes: Replace [ORIGINAL_PLAN] with the full plan the agent was following, including goals, steps, and assumptions. [COMPLETED_STEPS] should contain a structured log of actions already taken and their outcomes. [CURRENT_STATE] is the latest observed state of the system or environment. [EXTERNAL_CHANGES] captures any events, data updates, or signals that may have invalidated the plan since it was created. [CONSTRAINTS] should include resource limits, safety rules, and domain-specific boundaries. [OUTPUT_SCHEMA] must define the exact JSON structure you expect, including fields for staleness_detected, obsolete_assumptions, preserved_progress, and refreshed_plan_segment. If your harness uses structured output APIs, remove the schema instruction and enforce the schema at the API level instead.

Before deploying this prompt in production, validate its behavior against a golden set of stale-plan scenarios. Common failure modes include the model failing to recognize subtle staleness (false negatives), flagging assumptions as stale when they are still valid (false positives), or generating a refreshed plan that inadvertently repeats completed work. For high-stakes agent workflows, route outputs where staleness_detected is true to a human reviewer before the agent resumes execution. Log every staleness assessment with the original plan, completed steps, and refreshed segment for auditability.

The staleness detection prompt is not a standalone utility—it is a decision node inside an agent orchestration loop. The harness invokes this prompt at predefined checkpoints: before executing a high-cost action, after a tool timeout, when external state change signals arrive, or on a fixed-interval heartbeat for long-running agents. The prompt receives the original plan, completed steps, current world state, and any new observations. It returns a structured staleness assessment and, if the plan is stale, a refreshed plan segment. The harness must treat this output as a control signal, not just text: parse the staleness flag, branch execution accordingly, and log the decision for observability.

Wire the prompt into your agent runtime with a strict contract. Define a typed output schema requiring is_stale (boolean), stale_assumptions (array of strings), preserved_progress (array of completed step IDs), and refreshed_plan_segment (array of new steps, nullable). Validate the response against this schema before acting on it. If validation fails, retry once with a repair prompt that includes the schema violation details. If is_stale is true but refreshed_plan_segment is empty or malformed, escalate to a human reviewer or fall back to a full re-planning prompt. Log every staleness check with the plan version, trigger reason, assessment result, and action taken—this trace is essential for debugging agent drift in production. For high-stakes domains, require human approval before executing the refreshed plan segment if the number of stale assumptions exceeds a configurable threshold or if the refreshed steps modify safety-critical actions.

Model choice matters here. Use a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may conflate staleness with uncertainty or produce inconsistent JSON under complex plan structures. Set temperature=0 or very low to maximize deterministic assessments. Implement a retry budget: two attempts for validation failures, one attempt for staleness detection, then escalate. Never loop the staleness check itself—if the refresh produces a plan that is immediately flagged as stale again, break the cycle, log the contradiction, and escalate. The harness should also track plan versioning: each refresh increments a version number, and the agent must not execute steps from mixed plan versions. Finally, instrument the harness to emit metrics on staleness check frequency, refresh rate, validation failure rate, and escalation rate—these become your leading indicators for plan quality degradation in long-running agent workflows.