Plan Generation with Validation Step Insertion Prompt

This prompt is designed for agent planning modules that must produce a multi-step execution plan where critical outputs are verified before subsequent steps consume them. The core job-to-be-done is preventing cascading failures in autonomous or semi-autonomous workflows. Use it when your agent operates on mutable resources—such as databases, file systems, or cloud infrastructure—where an undetected partial failure in step three corrupts the input assumptions for steps four through seven. It is equally valuable when generating content that downstream steps depend on, such as a draft report that a later summarization step will process, or when executing actions where errors compound silently across steps, like a data pipeline where a schema mismatch in an early transformation produces valid-but-wrong results later.

The ideal user is an AI engineer or technical decision maker building an agent harness where the execution loop can interpret and enforce validation gates. You need a runtime that can pause execution at designated checkpoints, run the specified quality checks, evaluate the results against explicit thresholds, and branch to retry, repair, or escalate paths when validation fails. This prompt is not a standalone solution; it is a contract between the planning module and the execution engine. The plan it produces must be machine-readable enough that your harness can act on the validation gates without re-interpreting natural language at runtime. If your agent runtime cannot programmatically execute validation checks or conditionally branch based on their results, this prompt will produce plans your system cannot honor, leading to ignored gates and the very compounding failures the prompt was designed to prevent.

Do not use this prompt for simple linear workflows without interdependencies between steps. If each step is independent and a failure in one does not affect the others, the overhead of embedded validation gates adds latency and token cost without reducing risk. Similarly, avoid this prompt when all validation logic already lives entirely in external harness code rather than in the plan contract itself—if your execution engine already validates every tool output against a fixed schema before proceeding, the plan-level validation gates are redundant and create maintenance drift between the plan and the harness. This prompt is also inappropriate for agents with no ability to execute validation checks, such as a chat-only assistant that cannot call tools or inspect state. Finally, for plans with fewer than three steps or where the total execution time is under a few seconds, the cost of generating and parsing validation gates likely exceeds the cost of just re-running the entire workflow on failure. Reserve this prompt for workflows where the blast radius of an undetected failure justifies the additional planning complexity and runtime overhead.

This prompt template instructs the model to produce a complete execution plan where critical outputs are verified before downstream steps consume them. It is designed for agent planning modules that operate on mutable resources, regulated data, or high-cost actions where an undetected error in step three can corrupt step seven. Replace every square-bracket placeholder with your specific goal, available tools, output schema, and risk tolerance before sending this to the model. The template forces the model to define what 'passing' means for each validation gate, what happens on failure, and which steps can run in parallel while a validation is pending.

textCopy
You are a planning module for an autonomous agent system. Your job is to produce a complete, executable multi-step plan from a goal, a set of available tools, and known constraints. Every plan you produce must include embedded validation gates on steps whose output quality affects downstream correctness, safety, or cost.

# GOAL
[GOAL_DESCRIPTION]

# AVAILABLE TOOLS
[TOOL_LIST_WITH_CAPABILITIES_AND_ARGUMENTS]

# CONSTRAINTS
[BUDGETS, DEADLINES, PERMISSIONS, RATE_LIMITS, DATA_SENSITIVITY, REGULATORY_REQUIREMENTS]

# OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "plan_id": "string",
  "goal_summary": "string",
  "assumptions": ["string"],
  "steps": [
    {
      "step_id": "string",
      "description": "string",
      "tool": "string | null",
      "tool_arguments": {},
      "depends_on": ["step_id"],
      "expected_output": "string",
      "validation_gate": {
        "condition": "string describing the pass/fail check",
        "type": "schema_check | content_check | side_effect_check | human_approval | threshold_check",
        "threshold": "number | string | null",
        "on_failure": "retry | skip | fallback_to_step_id | escalate | abort",
        "max_retries": "number",
        "fallback_step_id": "string | null"
      } | null,
      "timeout_seconds": "number",
      "parallel_group": "string | null"
    }
  ],
  "critical_path_step_ids": ["string"],
  "escalation_triggers": ["string"]
}

# VALIDATION GATE RULES
1. Insert a validation gate on any step whose output is consumed by two or more downstream steps.
2. Insert a validation gate on any step that modifies persistent state, writes to a database, sends a message, or triggers an external action with no undo.
3. Insert a validation gate on any step whose output is used in a compliance, financial, or safety decision.
4. For steps with a validation gate, define a concrete, testable pass/fail condition. Do not use vague conditions like "check if output is good."
5. When a validation gate fails, specify exactly one on_failure behavior. If you choose "fallback_to_step_id," that step must exist in the plan.
6. Steps that do not depend on each other should be assigned the same parallel_group string so the execution engine can run them concurrently.

# RISK LEVEL
[RISK_LEVEL: low | medium | high | critical]

# EXAMPLES OF GOOD VALIDATION GATES
[OPTIONAL: 1-3 EXAMPLES OF WELL-FORMED VALIDATION GATES FOR YOUR DOMAIN]

Generate the plan now. Return only valid JSON.

After pasting this template, replace [GOAL_DESCRIPTION] with a specific, scoped objective—avoid vague requests like "analyze the data." The [TOOL_LIST_WITH_CAPABILITIES_AND_ARGUMENTS] placeholder must include every tool the agent can call, with argument schemas, so the model does not hallucinate unavailable capabilities. The [RISK_LEVEL] field controls how aggressively the model inserts validation gates: at critical, expect gates on nearly every state-mutating step; at low, gates appear only on high-leverage outputs. If your domain has recurring validation patterns—such as "schema check on API response" or "human approval on outbound email"—add them to the [EXAMPLES] section to improve consistency across plans. Before deploying, run this prompt against a set of known goals and verify that the output JSON parses, that every depends_on reference resolves to a real step_id, and that no step with a fallback_to_step_id points to a missing or circular dependency.

The prompt template produces a structured plan with embedded validation gates, but the real work begins when you connect it to an agent execution loop. The planning module should call this prompt after goal clarification and constraint elicitation, but before any tool execution. Treat the output as a contract: every step must include a validation block with a condition, threshold, and on_failure branch. If the model omits validation on a step that produces output consumed downstream, reject the plan and retry with a targeted correction message rather than silently accepting the gap.

Wire the prompt into your agent harness with a schema validator that checks for required fields before the plan enters the execution queue. At minimum, validate that every step with output_type not equal to null has a non-empty validation object, that on_failure values are drawn from a closed set (retry, skip, escalate, abort), and that no step references a tool outside the provided [TOOLS] list. Log validation failures with the step index and missing field so operators can trace plan quality degradation over time. For high-stakes domains, insert a human review gate after plan generation but before execution: surface steps marked risk_level: high or steps where validation.threshold is below 0.8 for approval.

The execution loop should treat each validation gate as a blocking condition. After a step completes, evaluate the validation.condition against the actual output before proceeding. If the condition fails, follow the on_failure branch exactly—do not let the agent improvise recovery unless your harness explicitly supports dynamic replanning. Track validation pass/fail rates per step type in your observability layer. A rising failure rate on a specific validation gate often signals tool output drift or prompt degradation, not a planning problem. Do not use this prompt for real-time safety-critical systems without a hardcoded circuit breaker that halts execution when validation failures exceed a configured threshold within a single plan run.