Multi-Step Rollback Recovery Prompt Template

This prompt is designed for agent orchestrators that must recover from a cascading failure by undoing multiple previously completed actions. It is intended for AI reliability engineers and agent-framework builders who need a structured rollback plan with dependency ordering, state restoration steps, and validation checks for side-effect reversal completeness. Use this when a single retry is insufficient and the system must safely unwind a sequence of state changes to return to a known-good checkpoint.

The ideal user has access to an execution trace that logs each completed action, its input parameters, its output or side effect, and a timestamp or sequence number. The prompt requires a known-good checkpoint identifier and a description of the failure that triggered the rollback. It is not a generic error-recovery prompt; it assumes the agent has already attempted and exhausted simpler retry strategies. Do not use this prompt for single-step failures, stateless operations, or workflows where side effects are irreversible (e.g., sending an email that cannot be recalled). In those cases, a human escalation or compensating transaction pattern is required instead.

Before invoking this prompt, ensure your harness has captured the full action history and can execute the rollback plan it produces. The prompt generates a plan—it does not execute it. Your application must parse the structured output, validate dependency ordering, and sequentially reverse each action while checking for partial reversals. Always log the rollback attempt and its outcome for auditability. If the rollback plan itself fails, escalate to a human operator rather than looping.

This template is designed to be pasted into your agent orchestrator's recovery handler when a multi-step action sequence fails and you need the model to produce a safe, ordered rollback plan. It forces the model to reason about side-effect reversal, dependency order, and state restoration before suggesting any new forward actions. Use it when a single retry is insufficient because earlier steps in the chain have already mutated external state—database writes, API calls, file modifications, or tool outputs that later steps depended on.

textCopy
You are a recovery planner for an autonomous agent that has encountered a cascading failure during a multi-step task. Your job is to produce a rollback plan that safely reverses completed actions in the correct dependency order, then restore the system to a consistent state.

## ORIGINAL PLAN
[ORIGINAL_PLAN]

## COMPLETED ACTIONS (in execution order)
[COMPLETED_ACTIONS]

## FAILURE DETAILS
Failed action: [FAILED_ACTION]
Error message: [ERROR_MESSAGE]
Error type: [ERROR_TYPE]

## CURRENT SYSTEM STATE
[SYSTEM_STATE]

## ROLLBACK CONSTRAINTS
- Some actions have irreversible side effects. Mark these clearly and explain why they cannot be undone.
- Actions that depend on each other must be rolled back in reverse dependency order.
- For each reversible action, specify the exact rollback operation and the expected post-rollback state.
- Do not propose new forward actions until rollback is complete and verified.
- If rollback of any action is uncertain, flag it for human review.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "failure_summary": "string describing what failed and why",
  "rollback_plan": [
    {
      "step": number,
      "original_action": "string describing the completed action to reverse",
      "dependency_on": [number] | null,
      "reversible": boolean,
      "irreversible_reason": "string or null",
      "rollback_operation": "string describing the exact undo operation",
      "expected_post_state": "string describing state after rollback",
      "verification_check": "string describing how to confirm rollback succeeded",
      "requires_human_approval": boolean
    }
  ],
  "state_after_rollback": "string describing the full system state once all reversible actions are undone",
  "unrecoverable_state": ["string describing any state that cannot be restored"],
  "human_escalation_required": boolean,
  "escalation_reason": "string or null",
  "resumption_ready": boolean
}

## RISK LEVEL
[RISK_LEVEL]

## ADDITIONAL CONTEXT
[CONTEXT]

Adapt this template by replacing the square-bracket placeholders with data from your agent's execution trace. [ORIGINAL_PLAN] should contain the full plan the agent was following before failure, including step numbers and dependencies. [COMPLETED_ACTIONS] must list every action that executed successfully before the failure, with their outputs and any state mutations. [SYSTEM_STATE] should capture the current state of all external systems the agent touched—database records, API resources, file paths, tool outputs. [RISK_LEVEL] accepts values like low, medium, high, or critical and should influence how conservative the rollback plan is. For high-risk or critical workflows, always set requires_human_approval on irreversible actions and route the output to a review queue before execution. The output schema is strict JSON; validate it against the schema before passing rollback operations to your execution harness. If the model returns human_escalation_required: true, stop the recovery loop and surface the escalation_reason to an operator immediately.

The Multi-Step Rollback Recovery Prompt is not a standalone chat instruction—it is a recovery subroutine inside an agent orchestrator. The harness invokes this prompt when a cascading failure is detected: a tool call fails, subsequent dependent actions produce errors, and the agent's current trajectory is no longer viable. The orchestrator must first freeze the agent's action loop, collect the full action history with timestamps and return values, and then inject this prompt as a structured recovery request. The prompt expects the complete failure chain, the original goal, and the current system state as input. Do not call this prompt for single-action failures; use a simpler retry-with-correction prompt instead.

Wire the prompt into a recovery workflow with these components: (1) A failure detector that monitors tool return codes, exception patterns, and dependency graphs to identify cascading failures. (2) A state snapshot module that captures the pre-failure state, all completed actions with their side effects, and any partial results before invoking recovery. (3) The rollback prompt itself, called with [ACTION_HISTORY], [ORIGINAL_GOAL], [CURRENT_STATE], [FAILURE_CHAIN], and [CONSTRAINTS] populated from the orchestrator's context. (4) A rollback validator that parses the prompt's output—a JSON rollback plan with dependency-ordered undo steps—and checks each step against the known side-effect registry. The validator must flag any step that claims to reverse a side effect not present in the action history, or that omits a known side effect from the reversal plan. (5) A rollback executor that runs each undo action in the specified order, verifying success after each step before proceeding. If any undo action fails, the harness must escalate to a human operator with the partial rollback state and failure context—do not loop the rollback prompt recursively.

Model choice matters. Use a model with strong reasoning and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because the rollback plan requires causal reasoning about action dependencies and side-effect ordering. Set response_format to JSON with a strict schema that includes rollback_steps (ordered array), dependency_graph (which steps depend on which), state_restoration_checks (assertions to verify after rollback), and irreversible_actions (side effects that cannot be undone and require manual intervention). Temperature should be low (0.0–0.2) to maximize plan consistency. Log every rollback invocation with the full prompt input, the generated plan, the validator's assessment, and the execution results. This audit trail is critical for debugging orchestrator behavior and for compliance in regulated workflows.

Retry budget and escalation: The harness must enforce a hard limit on rollback attempts per task—typically one rollback attempt. If the rollback plan itself fails validation (missing side effects, circular dependencies, impossible undo steps), do not retry the prompt with different parameters. Escalate immediately with the validator's findings. If the rollback executes but state restoration checks fail, log the discrepancy and escalate. The rollback prompt is a recovery mechanism of last resort for multi-step failures; it is not a general-purpose error handler. Testing: Before deploying, build a test suite of known cascading failure scenarios with expected rollback plans. Run the prompt against these scenarios and measure: (1) whether all reversible side effects appear in the rollback plan, (2) whether dependency ordering is correct, (3) whether irreversible actions are correctly flagged, and (4) whether the plan avoids introducing new side effects. A rollback plan that suggests deleting a resource that was never created is a critical failure. Human review: For any workflow involving data deletion, financial transactions, or state changes in production systems, require human approval before executing the rollback plan. The harness should present the plan, the validator's assessment, and a diff of state changes for operator sign-off.