Agent Plan Patching Prompt for Rollback Requirement

This prompt is designed for agent runtimes that operate on mutable resources—databases, file systems, cloud infrastructure, APIs with side effects—where a mid-plan failure leaves the system in an inconsistent state. Instead of aborting and leaving partial changes behind, the agent must generate a compensation plan that identifies which completed steps are reversible, determines the correct undo order, and preserves an audit trail of what was rolled back and why. Use this prompt when your agent has already detected a failure, the replanning decision has selected 'rollback' as the recovery strategy, and you need a structured, executable sequence of undo operations.

The prompt expects a detailed execution trace as input: which steps completed, what side effects they produced, the dependency graph between steps, and the nature of the failure that triggered the rollback. It produces a compensation plan with explicit undo operations ordered by reverse dependency—steps that depend on other steps must be rolled back first. Each undo operation includes the target resource, the reversal action, preconditions that must be satisfied before execution, and a verification check to confirm the rollback succeeded. The output also includes a rollback boundary marker indicating which steps are intentionally left in place because they are independent of the failed branch.

Do not use this prompt for read-only workflows, idempotent-only operations, or situations where a simple retry is sufficient. If your agent operates exclusively on immutable or stateless resources, a rollback prompt adds unnecessary complexity and latency. Similarly, if the failure is transient—a network timeout, a rate limit, a temporary unavailability—retry with backoff is the correct strategy, not compensation planning. Reserve this prompt for cases where side effects have already been committed and cannot be ignored, where the cost of inconsistent state exceeds the cost of rollback execution, and where an audit trail is required for compliance, debugging, or operator review.

This prompt template is designed to be injected into your agent's replanning module when a step failure has left the system in a partially modified state. It instructs the model to analyze the execution trace, identify which completed steps produced reversible side effects, and produce an ordered rollback sequence. The template uses square-bracket placeholders that your execution harness must populate with live data before sending the request to the model.

textCopy
You are an agent plan patching module responsible for generating rollback and compensation plans when a mid-plan failure requires undoing prior side effects on mutable resources.

## CONTEXT
- Original Goal: [ORIGINAL_GOAL]
- Original Plan: [ORIGINAL_PLAN_STEPS]
- Execution Trace (completed steps with side effects): [EXECUTION_TRACE]
- Failed Step: [FAILED_STEP_DETAILS]
- Failure Reason: [FAILURE_REASON]
- Current System State: [CURRENT_STATE_SNAPSHOT]
- Available Rollback Tools: [ROLLBACK_TOOLS]
- Audit Requirements: [AUDIT_REQUIREMENTS]

## TASK
Generate a compensation plan that:
1. Identifies every completed step that produced a reversible side effect.
2. Determines the correct undo operation for each reversible side effect.
3. Orders rollback operations to respect dependency constraints (e.g., delete child resources before parent resources).
4. Preserves audit evidence for every rollback action taken.
5. Verifies state consistency after all rollback operations complete.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "rollback_required": true,
  "compensation_plan": [
    {
      "step_id": "string",
      "original_action": "string",
      "side_effect_description": "string",
      "reversible": true,
      "rollback_operation": "string",
      "rollback_tool": "string",
      "rollback_arguments": {},
      "depends_on": ["step_id"],
      "verification_check": "string"
    }
  ],
  "irreversible_side_effects": [
    {
      "step_id": "string",
      "side_effect_description": "string",
      "reason_not_reversible": "string",
      "recommended_mitigation": "string"
    }
  ],
  "execution_order": ["step_id"],
  "state_consistency_checks": ["string"],
  "audit_evidence_required": ["string"]
}

## CONSTRAINTS
- Do not propose rollback operations for steps that had no side effects.
- Flag any side effect that cannot be reversed and explain why.
- Order rollback steps so that no step undoes a resource that a later rollback step still depends on.
- Include a verification check for every rollback operation.
- If the failure reason indicates data corruption, prioritize restoring from the last known-good state before attempting rollback.
- If [AUDIT_REQUIREMENTS] specifies regulatory or compliance obligations, include evidence collection steps that satisfy those requirements.

To adapt this template, replace each square-bracket placeholder with data from your agent's execution harness. The [EXECUTION_TRACE] should include structured records of every completed step, its inputs, outputs, and confirmed side effects. The [ROLLBACK_TOOLS] placeholder must list the actual tool signatures available for undo operations—such as delete, restore, or revert functions—so the model can propose concrete tool calls rather than abstract descriptions. For high-risk domains like finance or infrastructure, always route the generated compensation plan through a human approval step before execution. Validate the model's output against the JSON schema before feeding it into your rollback executor, and log both the plan and the validation result for audit purposes.

The rollback patching prompt is not a standalone safety net—it must be embedded in an execution harness that gates irreversible actions, tracks side effects, and enforces compensation before proceeding. Wire this prompt into your agent runtime as a recovery path that activates when a step failure is classified as requiring rollback (as opposed to retry, skip, or abort). The harness should maintain a side-effect ledger—a structured log of every mutating operation the agent has performed, including resource identifiers, timestamps, and pre-operation state snapshots where feasible. Without this ledger, the rollback prompt cannot identify what needs compensation, and the generated plan will be incomplete or dangerous.

Validation layer: Before executing any generated rollback plan, run a structural validator that checks: (1) every reversible step in the original plan has a corresponding compensation step in the rollback plan, (2) compensation steps are ordered correctly (reverse execution order for dependent mutations, parallel where safe), (3) no compensation step introduces new irreversible side effects, and (4) the rollback plan includes an audit evidence step that records what was rolled back and why. If validation fails, do not execute—re-prompt with the specific validation errors injected into [CONSTRAINTS] and request a corrected plan. After two failed validation attempts, escalate to a human operator with the original plan, the side-effect ledger, and both rejected rollback plans for manual review.

Retry and model selection: Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) for rollback plan generation—this is a high-stakes reasoning task where errors compound. Set temperature=0 or very low (0.1) to maximize deterministic, auditable output. If the model returns a malformed JSON plan that fails schema validation, retry once with the schema error injected into the prompt as a [CONSTRAINTS] amendment. Do not retry more than twice; after two schema failures, log the raw output, flag the session for human review, and halt the agent. Human-in-the-loop gate: For rollback operations that affect production data, financial records, or user-facing state, insert an approval step before execution. Present the human reviewer with: the original failed step, the side-effect ledger entries requiring compensation, the generated rollback plan, and an estimated blast radius. Require explicit approval before the harness executes any compensation step. For lower-risk environments (internal dev/staging), you may configure auto-approval with a mandatory post-rollback audit log.

Observability and logging: Instrument the harness to emit structured logs at each stage: failure classification (why rollback was chosen over retry), prompt invocation (with prompt version and input hash), validation result (pass/fail with specific violations), human approval decision (with reviewer identity and timestamp), and execution outcome (each compensation step success/failure with state verification). These logs form the audit trail required by the prompt's own output contract and are essential for post-incident review. Store the side-effect ledger and rollback plan alongside the session trace so operators can reconstruct what happened without replaying the entire agent run. What to avoid: Do not use this prompt as a substitute for idempotency design or transactional safety at the tool layer. If your tools support native rollback (database transactions, infrastructure-as-code state reconciliation), prefer those over agent-generated compensation plans. The prompt is a recovery mechanism for when native rollback is unavailable or when the agent has performed multiple cross-system mutations that must be unwound in a specific order.