Reflection and Self-Critique Prompt for Agent Plans

This prompt is designed for planning modules in autonomous agent systems that must validate a generated plan before execution begins. Use it when a single-pass plan from an LLM is likely to contain gaps, infeasible steps, or missing dependencies that would cause expensive runtime failures. The prompt instructs the model to act as a critical reviewer of its own output, producing a structured critique that identifies weaknesses and suggests concrete revisions. This is not a prompt for generating the initial plan. It is a second-pass validation step that sits between plan generation and plan execution. Apply it when the cost of a bad plan exceeds the cost of an extra inference call.

The ideal user is an AI engineer or agent architect building a planning system where execution carries real cost—whether that cost is measured in API spend, irreversible side effects, or user trust. The required context includes the original goal, the generated plan, available tools and their capabilities, known constraints, and any explicit assumptions the planner made. Without this context, the critique will be shallow and may miss domain-specific feasibility issues. The prompt works best when the plan is complex enough to have non-obvious failure modes but structured enough that a reviewer can systematically check each step.

Do not use this prompt when the plan is trivial, when execution cost is negligible, or when the planning model already has strong self-consistency guarantees. It is also inappropriate for real-time systems where the latency of a second inference call violates the user's time budget. If your agent operates in a domain where plans rarely fail or where failures are cheap to detect and recover from at runtime, skip the reflection step and invest instead in better postcondition validation. For high-risk domains such as healthcare, finance, or safety-critical infrastructure, this prompt is necessary but not sufficient—you must also implement human review gates and evidence grounding checks before any action is taken.

This template is designed to be pasted directly into your planning validation module. It instructs the model to act as a skeptical reviewer, systematically identifying gaps, infeasible steps, and missing dependencies in a proposed agent plan. The output is a structured critique that can be parsed by an orchestrator to either approve the plan or route it back for revision, preventing costly execution errors.

textCopy
You are a critical plan reviewer. Your task is to analyze the provided execution plan for an AI agent and produce a structured critique. Do not execute the plan. Focus exclusively on finding flaws before execution begins.

**Objective:** [OBJECTIVE]

**Available Tools (name, description, parameters):**
[TOOLS]

**Proposed Plan:**
[PLAN]

**Constraints and Risk Level:** [CONSTRAINTS]

**Critique Instructions:**
1. **Completeness Check:** Identify any missing steps required to achieve the objective. Are there unhandled edge cases or implicit assumptions?
2. **Feasibility Check:** For each step, verify if the required tool exists and if the proposed parameters are valid. Flag any step that relies on an output from a previous step without a clear dependency chain.
3. **Dependency Analysis:** Map the execution order. Are there circular dependencies or steps that could be parallelized? Identify any step that is scheduled before its required inputs are guaranteed to exist.
4. **Risk Assessment:** Flag steps that are irreversible, destructive, or have a high blast radius. Note if the plan lacks a rollback or fallback strategy for these steps.
5. **Gap Analysis:** Identify what information is unknown before execution but is required for a decision point. The plan should request clarification, not guess.

**Output Format:**
Return a valid JSON object with the following schema:
{
  "critique_summary": "A one-sentence overall assessment.",
  "verdict": "APPROVE" | "REVISE" | "REJECT",
  "critical_issues": [
    {
      "step_id": "string or null",
      "severity": "BLOCKER" | "HIGH" | "MEDIUM",
      "category": "MISSING_STEP" | "INFEASIBLE_STEP" | "DEPENDENCY_ERROR" | "RISK_EXPOSURE" | "MISSING_INFORMATION",
      "description": "Clear explanation of the flaw.",
      "suggestion": "Actionable recommendation to fix the issue."
    }
  ],
  "revised_plan_skeleton": "A high-level corrected sequence of steps, only if the verdict is REVISE. Otherwise, null."
}

To adapt this template, replace the square-bracket placeholders with your specific context. The [TOOLS] placeholder should be populated with a strict JSON schema defining your agent's available functions, as this is the contract the critique will validate against. The [CONSTRAINTS] placeholder is critical for high-risk workflows; use it to specify rules like 'no destructive actions without approval' or 'must handle PII data.' After receiving the critique, your harness should parse the verdict field: an APPROVE verdict can proceed directly to execution, a REVISE verdict should feed the revised_plan_skeleton back into your plan generation prompt, and a REJECT verdict should halt the workflow and escalate to a human operator for goal clarification.

The reflection prompt is not a standalone artifact—it is a planning-stage validator that sits between plan generation and plan execution. In a typical agent pipeline, the planner produces a multi-step plan, and the reflection prompt critiques that plan before any tool calls or state mutations occur. This gate prevents the agent from executing infeasible steps, missing dependencies, or committing to irreversible actions without adequate justification. The harness should treat the reflection output as structured feedback that can trigger plan revision, human escalation, or plan rejection—not as a pass/fail stamp that the agent blindly trusts.

Integration pattern: Wire the reflection prompt as a synchronous validation step in the planning loop. After the planner generates a plan, serialize it into the [PLAN] placeholder along with the original [GOAL], [CONSTRAINTS], and [AVAILABLE_TOOLS]. The reflection model returns a structured critique containing gaps, infeasible_steps, missing_dependencies, risk_flags, and an overall_confidence score. Parse this output with a schema validator (e.g., Pydantic or JSON Schema) and apply decision rules: if overall_confidence is below a configurable threshold (start with 0.7), route the plan back to the planner with the critique as feedback for revision. If confidence is above threshold but risk_flags contain high-severity items, surface to a human review queue with the plan, critique, and a summary of flagged risks. If confidence is high and no critical risks exist, release the plan for execution. Model selection: Use a capable reasoning model (e.g., Claude 3.5 Sonnet, GPT-4o) for the reflection step—cheaper models often produce shallow critiques that miss dependency gaps. The planner and reflector can be the same model with different system prompts, but using a separate model instance for reflection reduces self-consistency bias where the model rubber-stamps its own output.

Retry and loop control: Implement a maximum revision count (recommended: 3) to prevent infinite critique-revise loops. On each revision, append the previous critique to the planner's context so it can address specific gaps. If the plan still fails reflection after max revisions, escalate to a human operator with the full revision history. Logging and observability: Log every reflection output alongside the plan version, revision count, and final disposition (accepted, revised, rejected, escalated). This trace is essential for debugging planning failures and tuning confidence thresholds. What to avoid: Do not use the reflection prompt as a post-execution audit—by then, irreversible actions may already be taken. Do not skip schema validation on the reflection output; unstructured critiques are hard to act on programmatically. Do not assume the reflection model catches everything—it can miss subtle domain-specific constraints that require human expertise, which is why the high-risk escalation path must remain available.