Agent Plan Patching Prompt for New Evidence

This prompt is for agent runtimes that discover new evidence mid-execution which contradicts the assumptions the original plan was built on. Use it when a tool returns data that invalidates a prior belief, a retrieved document disproves a planning premise, or an external sensor reading changes the operating context. The core job-to-be-done is surgical plan repair: you need to retract only the steps that depended on the invalidated assumption, preserve all unaffected progress, and re-sequence the remaining work without rebuilding the entire plan from scratch. This matters because full replanning is expensive, discards valid completed work, and introduces unnecessary variance in production agent loops.

This prompt assumes your agent runtime already maintains an explicit plan structure with tracked assumptions, completed steps, and pending dependencies. The plan must include a dependency graph or at minimum a list of steps annotated with the assumptions each step depends on. Without this assumption traceability, the model cannot calculate the impact radius of new evidence and will either over-correct by discarding too much work or under-correct by leaving contradicted steps in the plan. The ideal user is an engineering team building autonomous or semi-autonomous agent loops where static plans fail silently in production—think research agents, code-review agents operating across multiple repositories, or data-processing pipelines where upstream schema changes invalidate downstream transformation logic.

Do not use this prompt for simple step retries, tool-argument fixes, or constraint violations. Those failures have dedicated patching prompts: tool failures need alternative tool selection, unexpected outputs need output-reinterpretation logic, and constraint violations need boundary-aware replanning. This prompt is specifically for the case where the plan's foundational beliefs were wrong—not where execution hit a recoverable error. Also avoid this prompt when the new evidence is merely additive rather than contradictory; if the evidence extends understanding without invalidating prior steps, a plan extension prompt is more appropriate. Finally, if your agent does not track assumptions explicitly, invest in that infrastructure before deploying this prompt, because asking the model to infer what assumptions existed retroactively produces unreliable impact analysis.

This template is designed to be injected into an agent's replanning module when a runtime monitor detects that new evidence contradicts a previously held assumption. It instructs the model to act as a plan surgeon: identify the exact steps that depended on the invalidated assumption, retract them, and generate a minimal replacement sequence that incorporates the new evidence. The prompt is structured to prevent full plan regeneration, which is expensive and risks discarding valid, completed work.

textCopy
You are an agent plan patching module. Your task is to revise an in-progress execution plan because new evidence has invalidated a core assumption.

# Original Plan
[ORIGINAL_PLAN]

# Completed Steps (do not modify or re-execute)
[COMPLETED_STEPS]

# Invalidated Assumption
The following assumption was made during planning but is now contradicted by evidence:
[INVALIDATED_ASSUMPTION]

# New Evidence
The following evidence has been observed that contradicts the assumption:
[NEW_EVIDENCE]

# Current Active Step (may be interrupted)
[ACTIVE_STEP]

# Available Tools
[AVAILABLE_TOOLS]

# Constraints
- Preserve all completed steps. Do not suggest re-executing them.
- Minimize the number of new or modified steps.
- If the active step depends on the invalidated assumption, mark it for immediate interruption.
- Do not alter steps that are independent of the invalidated assumption.
- If the new evidence makes the original goal unachievable, explicitly state this and recommend escalation.

# Output Schema
Return a JSON object with the following structure:
{
  "assumption_impact_analysis": "string describing which plan steps depend on the invalidated assumption",
  "interrupted_step": "[ACTIVE_STEP] or null if the active step is unaffected",
  "retracted_steps": ["list of step IDs to remove from the remaining plan"],
  "patched_plan_fragment": [
    {
      "step_id": "unique step identifier",
      "description": "what the step does",
      "tool": "tool name from available tools or null",
      "depends_on": ["list of step IDs this step requires"],
      "expected_output": "description of what success looks like"
    }
  ],
  "goal_still_achievable": true or false,
  "escalation_reason": "string explaining why escalation is needed, or null"
}

To adapt this template, replace the square-bracket placeholders at runtime. [ORIGINAL_PLAN] should contain the full plan object, including step IDs, descriptions, and dependency edges. [COMPLETED_STEPS] must be an accurate list of step IDs that have already executed successfully—errors here cause the agent to either redo work or skip necessary steps. [INVALIDATED_ASSUMPTION] should be a single, specific statement extracted from the planning trace, not a vague observation. [NEW_EVIDENCE] must be the raw observation or tool output that triggered the replanning event. Before deploying, validate that the output JSON strictly conforms to the schema, that retracted step IDs exist in the original plan, and that the patched fragment does not reintroduce dependencies on the invalidated assumption. For high-risk domains, route the generated patch to a human reviewer before resuming execution.

The plan patching prompt is not a standalone chat interaction—it is a component inside an agent orchestration loop. The runtime should invoke it only when a monitoring module detects a specific trigger condition: new evidence that contradicts a tracked planning assumption. Before calling the prompt, the harness must assemble the current plan state, the contradictory evidence, the list of explicit assumptions the plan depends on, and the completed step history. This context assembly is the most common failure point in production because incomplete or stale state causes the patching prompt to propose revisions that conflict with already-completed work.

Wire the prompt into a structured decision node within the agent's execution loop. The runtime flow should be: (1) the evidence monitor flags a contradiction and emits a structured trigger payload containing the assumption that was invalidated and the new evidence; (2) the harness collects the current plan, completed steps with their outputs, pending steps, and the full assumption register; (3) the patching prompt is called with these inputs; (4) the output is parsed as a structured patch object containing affected_steps, replacement_steps, retracted_assumptions, and new_assumptions; (5) a validator checks that every affected_step exists in the current plan, that no replacement_step duplicates a completed step, and that all new_assumptions are explicit and testable; (6) if validation fails, the harness retries once with the validation errors appended as feedback, then escalates to a human operator if the second attempt also fails. Use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enforce the output schema with function calling or structured output mode rather than relying on free-text parsing.

Log every patch invocation with the trigger reason, the assumption that was invalidated, the evidence that caused it, the patch diff, and the validation result. This audit trail is essential for debugging agent behavior and for post-execution reviews. Avoid applying patches automatically when the patch proposes changes to more than 30% of remaining steps or when it retracts an assumption that was used to justify a completed irreversible action—in these cases, escalate for human review. The harness should also enforce a maximum patch depth (no more than three nested replanning events per session) to prevent infinite replanning loops where each patch introduces new assumptions that are immediately invalidated.