Agent Plan Patching Prompt for Partial Completion

This prompt is designed for agent runtime developers who need to recover from a step that partially succeeded in a long-running workflow. A partial completion occurs when a single step applies some side effects while failing to apply others—for example, a database write succeeds but a notification fails, a file is created but permissions are not set, or a multi-resource deployment provisions compute but fails on storage. In these cases, the agent cannot simply retry the step because repeating the successful side effects could cause duplication, inconsistency, or resource conflicts. Instead, the agent must produce a structured recovery plan that identifies what completed, what must be retried or compensated, and whether a rollback is required.

Use this prompt inside an agent execution loop after detecting a partial completion state. The detection should come from postcondition validation or step verification logic that compares expected side effects against actual state. The prompt expects a detailed description of the step that was attempted, the intended side effects, and the observed partial state. It produces a recovery plan with three sections: completed side effects that should be preserved, failed side effects that need retry or compensation, and a rollback decision with justification. The output should be machine-readable so the agent runtime can execute the recovery steps programmatically.

Do not use this prompt for total step failures where no side effects were applied. For those cases, use the Agent Plan Patching Prompt for Tool Failure, which handles clean retry or tool substitution without compensation logic. Do not use this prompt when the failure mode is an unexpected output that doesn't match the expected schema—that scenario requires the Agent Plan Patching Prompt for Unexpected Output. Do not use this prompt when new evidence invalidates prior assumptions rather than a specific step failure—that requires the Agent Plan Patching Prompt for New Evidence. Misclassifying the failure mode leads to recovery plans that either over-compensate by rolling back work that didn't need undoing, or under-compensate by retrying steps that already left side effects. Always run a failure classification step before selecting which patching prompt to invoke.

This prompt instructs the model to act as a plan-patching agent. Its job is to analyze a partially completed step, identify what succeeded and what failed, and produce a structured recovery plan. The recovery plan must account for applied side effects, pending retries, and any required compensation or rollback actions. Use this template as the core instruction block in your agent's replanning module, wiring it to execute after a step returns a partial-success status.

codeCopy
You are an agent plan patching specialist. Your task is to generate a recovery plan when a step in a long-running workflow partially succeeds. Some side effects have been applied, while others have failed.

## INPUT
- Original Plan Step: [ORIGINAL_STEP]
- Execution Result: [EXECUTION_RESULT]
- Completed Side Effects: [COMPLETED_SIDE_EFFECTS]
- Failed Side Effects: [FAILED_SIDE_EFFECTS]
- Remaining Plan Steps: [REMAINING_PLAN_STEPS]
- Available Tools: [AVAILABLE_TOOLS]
- System Constraints: [CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "state_assessment": {
    "step_status": "partially_completed",
    "completed_actions": ["list of actions that succeeded"],
    "failed_actions": ["list of actions that failed"],
    "applied_side_effects": ["list of side effects already applied to the system"],
    "rollback_required": true_or_false,
    "rollback_reason": "explanation if rollback is required, otherwise null"
  },
  "recovery_plan": {
    "strategy": "retry_and_continue | rollback_and_retry | compensate_and_skip | escalate",
    "compensation_steps": [
      {
        "step_id": "unique identifier",
        "action": "description of the compensation action",
        "tool": "tool name or null",
        "target_side_effect": "which side effect this compensates for",
        "idempotency_key": "key to prevent duplicate execution"
      }
    ],
    "retry_steps": [
      {
        "step_id": "unique identifier",
        "action": "description of the retry action",
        "tool": "tool name",
        "modified_parameters": {},
        "precondition_checks": ["checks to run before retry"]
      }
    ],
    "updated_remaining_plan": ["adjusted list of remaining steps"],
    "checkpoint_instruction": "what state to save before executing recovery"
  },
  "risk_assessment": {
    "data_loss_risk": "low | medium | high",
    "duplicate_action_risk": "low | medium | high",
    "requires_human_approval": true_or_false,
    "approval_reason": "explanation if human approval is needed"
  }
}

## CONSTRAINTS
- Do not propose actions that would duplicate already-applied side effects.
- If a side effect is irreversible, mark rollback_required as false and explain why compensation is the only path.
- Prefer idempotent retry steps whenever possible.
- If the failure mode is unclear, request human approval before proceeding.
- Preserve all successfully completed work unless rollback is strictly required.
- If the estimated recovery cost exceeds [MAX_RECOVERY_COST], escalate instead of patching.

## EXAMPLES
[EXAMPLES]

Generate the recovery plan.

To adapt this template for your runtime, replace each square-bracket placeholder with live data from your agent's execution context. [ORIGINAL_STEP] should contain the full step definition that was attempted. [EXECUTION_RESULT] must include the raw output, error messages, and status codes. [COMPLETED_SIDE_EFFECTS] and [FAILED_SIDE_EFFECTS] require accurate state tracking—your agent must maintain a side-effect ledger to populate these correctly. [EXAMPLES] should include at least two few-shot demonstrations: one showing a safe retry-and-continue patch and one showing a rollback-and-compensate scenario. If your domain involves irreversible operations (e.g., sending emails, charging payments), add explicit constraints to the [CONSTRAINTS] block that forbid retries without human approval. After pasting this prompt, validate the output against the JSON schema before passing it to your execution engine. If the model returns a strategy of "escalate," route to a human operator immediately rather than attempting automated recovery.

The plan-patching prompt is not a standalone utility; it is a decision node inside an agent's execution loop. When a step returns a partial completion signal—some side effects applied, others failed—the runtime must pause execution, capture the current state, and invoke this prompt to produce a recovery plan. The harness is responsible for providing the prompt with an accurate snapshot of completed work, failed operations, and the original plan context. Without this harness discipline, the model receives stale or incomplete information and generates patches that either duplicate completed work or skip necessary compensation steps.

Integration pattern. Wire the prompt as a synchronous call within the agent's step-completion handler. After each step, the runtime evaluates the step's output against its expected postconditions. If the step reports partial completion, the handler constructs the prompt's input payload: the original plan with step IDs, the completed sub-steps with their side-effect descriptions, the failed sub-steps with error details, and any relevant tool schemas for compensation actions. The model's output should conform to a strict schema—typically a JSON object containing a recovery_plan array of patched steps, a compensation_required boolean, and a state_summary string. Validate this output before acting on it: check that every step ID in the patch references either an existing plan step or a new compensation step with a defined tool, that no completed-and-verified step is marked for re-execution unless explicitly justified, and that the compensation steps are ordered correctly (undo before redo, dependent rollbacks sequenced properly).

Retry and escalation logic. If the model's output fails schema validation, retry once with the validation errors appended to the prompt as additional constraints. If the retry also fails, do not execute a best-guess patch—escalate to a human operator with the partial state, the failed validation details, and the original plan. For high-risk domains (finance, healthcare, infrastructure), require human approval before executing any compensation step that modifies external state, even when the model's output passes validation. Log every patch invocation with the input state, the model's raw output, the validation result, and the human approval decision. This audit trail is essential for debugging plan drift and for demonstrating governance compliance. Model choice matters: use a model with strong instruction-following and structured output capabilities (such as GPT-4o or Claude 3.5 Sonnet) for plan-patching decisions, and set temperature low (0.0–0.2) to reduce variance in recovery plan generation.

State management and idempotency. Before executing any patched step, the harness must check whether the step's intended side effect has already been applied. Partial completions often leave ambiguous state—a database write may have succeeded while the confirmation message failed. Implement idempotency keys or state-verification checks before re-running any operation. If the patch includes a rollback step, verify that the resource to be rolled back still exists and is in the expected state. The harness should also update the agent's progress tracker immediately after each patched step completes, maintaining a clear distinction between original-plan steps and patch-injected steps. This prevents the agent from losing track of what was part of the initial plan versus what was added during recovery, which is a common source of infinite patching loops.