Agent Plan Patching Prompt for Human Override

This prompt is designed for a specific moment in a human-in-the-loop agent system: an operator has reviewed the agent's proposed next step or current trajectory and decided to intervene. The intervention might be a rejection of a planned step, a modification of a sub-goal, or a complete redirection of the workflow. The core job-to-be-done is to translate this human judgment into a surgical plan patch that applies the override without forcing the agent to discard all prior progress. The ideal user is a developer or AI engineer building the agent runtime's override handler, where the system must accept an operator's natural language command and produce a structured, machine-readable plan update.

To use this prompt effectively, you must provide it with the current plan state, including completed steps, in-progress steps, and their dependency graph. You also need the operator's override instruction and a clear output schema for the patch. The prompt's value is in its ability to preserve unaffected work and generate a minimal diff. Do not use this prompt for fully autonomous replanning triggered by tool failures, unexpected outputs, or new evidence; those scenarios have dedicated sibling prompts (e.g., 'Agent Plan Patching Prompt for Tool Failure') with different evaluation criteria and failure modes. Using this prompt for autonomous error recovery will produce patches that incorrectly treat a system error as a human strategic decision, missing the required diagnostic and fallback logic.

Before wiring this into your application, ensure your harness can validate the patch's scope. A common failure mode is an override that implicitly invalidates a completed step's output without the patch explicitly marking it for re-evaluation. Your implementation should check that the patch's affected_steps list includes all downstream dependencies of the overridden step. If the operator's instruction is ambiguous, the system should request clarification rather than guess, as a misapplied patch in a high-risk workflow can corrupt state silently. The next section provides the copy-ready prompt template you will integrate into this handler.

This template is designed to be pasted directly into your agent runtime when a human operator has rejected a step, modified a goal, or redirected execution. It instructs the model to produce a surgical plan patch—not a full replan—that respects the override, preserves completed and in-progress work, and identifies which downstream steps are impacted. The prompt expects structured context about the current plan state, the override details, and the execution history so the model can reason about minimal changes rather than starting from scratch.

textCopy
You are an agent plan patching module operating in a human-in-the-loop system. Your task is to generate a minimal plan patch that incorporates a human override while preserving completed work and minimizing unnecessary re-execution.

## CURRENT PLAN STATE
[ORIGINAL_PLAN]

## EXECUTION HISTORY
[COMPLETED_STEPS]
[IN_PROGRESS_STEPS]
[PENDING_STEPS]

## HUMAN OVERRIDE
Override Type: [OVERRIDE_TYPE]  # One of: STEP_REJECTION, GOAL_MODIFICATION, REDIRECTION, CONSTRAINT_CHANGE
Override Details: [OVERRIDE_DETAILS]
Operator Notes: [OPERATOR_NOTES]

## PATCHING CONSTRAINTS
- Preserve all completed steps unless the override explicitly invalidates their outputs.
- For in-progress steps, determine whether they can complete safely or must be interrupted.
- Identify downstream steps that depend on overridden or modified outputs.
- Minimize rework: only mark steps for re-execution if their inputs or assumptions have changed.
- Do not alter steps that are independent of the override.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "patch_id": "string",
  "override_summary": "One-sentence summary of what the human changed",
  "impact_assessment": {
    "invalidated_completed_steps": ["step_ids"],
    "interrupted_in_progress_steps": ["step_ids"],
    "affected_pending_steps": ["step_ids"],
    "unaffected_steps": ["step_ids"],
    "estimated_rewind_cost": "description of lost work if any"
  },
  "patch_operations": [
    {
      "operation": "RETAIN | MODIFY | DELETE | INSERT | REORDER",
      "target_step_id": "string or null for INSERT",
      "new_step_definition": "full step spec if MODIFY or INSERT, otherwise null",
      "reason": "Why this operation is necessary"
    }
  ],
  "revised_plan": ["ordered list of step_ids after patching"],
  "requires_human_review": true or false,
  "review_rationale": "Explain why human review is or is not needed before resuming execution"
}

## ADDITIONAL CONTEXT
[TOOL_CATALOG]
[CONSTRAINT_POLICIES]
[RISK_LEVEL]

Generate only the JSON patch object. Do not include explanatory text outside the JSON.

Adaptation notes: Replace [ORIGINAL_PLAN] with the full plan structure including step IDs, descriptions, dependencies, and expected outputs. [COMPLETED_STEPS] and [IN_PROGRESS_STEPS] should include step IDs, actual outputs, and any side effects observed. For [OVERRIDE_TYPE], constrain to the four enumerated values to prevent the model from inventing override categories. The [TOOL_CATALOG] should list available tools with their schemas so the model can validate that modified or inserted steps reference valid tools. In high-risk domains, set [RISK_LEVEL] to high and ensure the requires_human_review field is evaluated against your organization's approval policy before resuming execution. Always validate the returned JSON against the schema before applying the patch to your plan state.

This prompt is designed to sit inside a human-in-the-loop (HITL) approval gateway within an agent execution loop. When a human operator rejects a step, modifies a goal, or redirects execution via a review interface, the runtime captures the override instruction, the current plan state, and the execution history, then calls this prompt to generate a minimal, safe patch. The prompt is not a standalone chatbot interaction; it is a structured API call within a stateful agent harness. The harness is responsible for providing accurate [CURRENT_PLAN], [COMPLETED_STEPS], [OVERRIDE_INSTRUCTION], and [CONSTRAINTS] context. Without this harness, the model cannot reliably preserve completed work or calculate downstream impact.

Wiring the prompt into an agent runtime requires a pre-call validation layer and a post-call execution gate. Before calling the model, the harness must validate that the [OVERRIDE_INSTRUCTION] is non-empty, that the [CURRENT_PLAN] is structurally valid (e.g., a list of steps with IDs and statuses), and that the [COMPLETED_STEPS] list is consistent with the plan's recorded state. After receiving the model's output, the harness must parse the proposed plan patch—typically a JSON object containing patch_type, affected_step_ids, new_steps, removed_step_ids, and impact_analysis—and run a series of deterministic checks before applying it. These checks include: verifying that no completed step is modified or removed unless explicitly flagged for rollback; confirming that all new or modified steps reference valid tool schemas from [AVAILABLE_TOOLS]; and ensuring the patch does not introduce circular dependencies. If any check fails, the harness should log the failure, surface the conflict to the operator, and request clarification rather than silently applying a broken patch.

Retry and fallback logic must be designed for the specific failure modes of this prompt. Common failures include: the model proposing a patch that deletes a completed step without a rollback plan; generating a step that uses a tool not present in [AVAILABLE_TOOLS]; or producing a patch that is syntactically valid but semantically empty (e.g., no steps changed). The harness should implement a retry loop with a maximum of 2-3 attempts, each time appending the specific validation error to the prompt context as a [PREVIOUS_PATCH_ERROR]. If retries are exhausted, the harness must escalate to a human operator with the full plan context and the failed patch attempts, never falling back to autonomous application of a rejected patch. Logging and audit trail preservation are critical: every override event, the generated patch, validation results, and the final applied (or rejected) patch must be written to an append-only audit log with timestamps and operator identity. This log serves as the evidence trail for compliance reviews and debugging.

Model choice and tool integration affect how this prompt is deployed. The prompt requires strong instruction-following and structured output capabilities; models like Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro are appropriate. The harness should call the model with response_format set to a JSON schema that matches the expected patch structure, reducing the need for repair prompts. The prompt's [AVAILABLE_TOOLS] placeholder should be populated from the agent's live tool registry, not a static list, to prevent the model from suggesting unavailable tools. If the agent runtime uses a tool-calling API (e.g., OpenAI function calling), the harness should map the model's textual tool references to actual function signatures before execution. Human-review gates are the final safety layer: for high-risk overrides—such as those modifying steps that involve write operations, financial transactions, or data deletion—the harness should require explicit operator confirmation of the patched plan before resuming execution, even if all automated validation checks pass.