Agent Replanning Decision Prompt Template

This prompt is for agent runtime developers who need a structured, programmatic decision point when an agent's execution step fails or new evidence contradicts the current plan. The job-to-be-done is not to fix the plan, but to reliably classify the situation and output a machine-readable directive: continue, patch, rollback, or abort. The ideal user is an engineering lead or AI/ML engineer building a resilient agent execution loop in a production system where silent failures, infinite retries, or unsafe state mutations are unacceptable. Required context includes the original plan, the current execution state, the failure or contradiction event, and the agent's operational constraints (budget, time, safety policy).

Do not use this prompt when you need a creative workaround or a human-readable explanation of what went wrong. It is not for generating a new plan from scratch, nor for patching the plan directly—it is a decision router that precedes a specialized patching prompt. It is also inappropriate for low-risk, stateless, or idempotent workflows where a simple retry loop is sufficient. The prompt assumes you have already detected a failure or contradiction and have packaged the relevant state into the input. If your agent lacks a clear plan structure, step tracking, or constraint definitions, this prompt will produce unreliable decisions because it cannot reason about what it cannot see.

Before integrating this prompt, ensure your agent runtime can act on each decision type: continue means proceed to the next step despite the event; patch means invoke a plan-patching sub-agent with the specific failure mode; rollback means execute a compensation plan to undo prior side effects; abort means halt execution and escalate to a human or logging system. The prompt's value is in preventing the most common production failure modes—agents that loop, agents that proceed with corrupted state, and agents that waste tokens on unrecoverable paths. Wire this prompt into your execution loop immediately after any step failure, postcondition validation failure, or new-evidence trigger, and before any retry logic.

The following prompt template is designed to be called by an agent runtime's replanning module. It forces a structured decision—continue, patch, rollback, or abort—instead of allowing the model to produce an open-ended narrative. Use this template as the core instruction set for your replanning node, wrapping it with your specific tool definitions, execution history, and safety policies. The square-bracket placeholders must be populated by your application before the model call; never pass unresolved placeholders to the model.

textCopy
You are an agent replanning decision module. Your only job is to evaluate the current execution state and output a structured decision.

## Current Plan
[PLAN_STEPS]

## Completed Steps with Outputs
[COMPLETED_STEPS]

## Failure or Trigger Event
[TRIGGER_EVENT]

## Available Tools
[TOOL_LIST]

## Constraints
- Max remaining budget: [BUDGET_REMAINING]
- Deadline: [DEADLINE]
- Safety policy: [SAFETY_POLICY]
- Rollback capability: [ROLLBACK_AVAILABLE]

## Decision Rules
1. If the failure is recoverable with an available alternative tool or adjusted arguments, output `patch`.
2. If the failure invalidates prior steps that must be undone, output `rollback` only if rollback is available; otherwise output `abort`.
3. If the failure is non-recoverable and the plan cannot be salvaged, output `abort`.
4. If the trigger is new evidence that contradicts a planning assumption, identify all assumption-dependent steps and output `patch` with a revised plan segment.
5. If the trigger is a constraint violation (budget, time, policy), output `patch` with a constraint-satisfying revision or `abort` if no revision is feasible.
6. If none of the above apply and the plan can proceed, output `continue`.

## Output Schema
Return ONLY a valid JSON object with no additional text:
{
  "decision": "continue" | "patch" | "rollback" | "abort",
  "confidence": 0.0-1.0,
  "reasoning": "Concise explanation of why this decision was chosen, referencing specific evidence from the trigger event and plan state.",
  "affected_steps": ["step_ids"],
  "revised_plan": [
    {
      "step_id": "string",
      "action": "string",
      "tool": "string or null",
      "arguments": {},
      "depends_on": ["step_ids"],
      "rollback_action": "string or null"
    }
  ],
  "requires_human_approval": true | false,
  "escalation_reason": "string or null"
}

## Critical Rules
- If confidence is below 0.7, set `requires_human_approval` to true.
- If the decision is `rollback`, include `rollback_action` for every reversible step in `revised_plan`.
- If the decision is `abort`, `revised_plan` must be an empty array.
- Never invent tools not present in the available tools list.
- If the trigger event involves a safety policy violation, `requires_human_approval` must be true regardless of confidence.

To adapt this template for your agent runtime, replace each placeholder with live data from your execution state. [PLAN_STEPS] should contain the full ordered plan with step IDs, descriptions, and dependencies. [COMPLETED_STEPS] must include actual outputs and any validation results. [TRIGGER_EVENT] should be a structured description of what failed or what new evidence arrived—avoid passing raw error logs without summarization. Wire your tool registry into [TOOL_LIST] with full schemas so the model can reason about alternatives. Set [ROLLBACK_AVAILABLE] based on whether your execution environment supports compensating transactions or state reversal. After the model returns a decision, validate the JSON against the schema before acting on it. If the decision is patch or rollback, feed the revised_plan into your plan executor only after running precondition checks on each new step. For high-risk domains, always require human approval when requires_human_approval is true, and log the full decision payload for audit.

The Agent Replanning Decision Prompt is designed to sit inside a tight runtime loop—not as a standalone chat interaction. It should be invoked immediately after a step failure, unexpected output, or contradictory evidence is detected by the agent's monitoring layer. The prompt expects a structured snapshot of the current plan state, the triggering event, and available tools. Your harness must assemble this context programmatically from the agent's execution trace, not from user input. The model's response is a structured decision object that your runtime must parse and act on: continue, patch, rollback, or abort. Do not expose this prompt to end users; it is an internal control-plane component.

Wire the prompt into your agent framework as a synchronous decision point with a strict timeout (e.g., 5 seconds) and a hardcoded fallback. If the model call fails, times out, or returns unparseable output, the harness must default to the safest action for the domain—typically abort for financial or safety-critical agents, or rollback for agents operating on mutable resources. Validate the response against a schema that requires decision (enum), rationale (string), and optional patch_plan (array of steps). Reject any response that proposes a patch referencing tools not present in the original [TOOLS] input. Log every decision with the full prompt, response, and validation result for audit and debugging. For high-risk domains, insert a human approval gate before executing any rollback or patch decision that modifies external state.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) because the cost of a wrong decision—wasted agent steps, corrupted state, or unsafe execution—far exceeds the per-call token cost. Avoid using smaller or faster models unless you have validated decision accuracy against a golden test set of at least 50 failure scenarios. Implement a retry budget of 2 attempts with exponential backoff for transient model errors, but never retry on a decision: abort response. After deployment, monitor the ratio of patch to abort decisions; a sudden spike in patches often indicates that the agent is papering over a systemic tool or planning failure that requires root-cause investigation rather than more replanning.