Tool Call Execution Plan Validation Prompt for Dependencies

This prompt is a pre-execution validation gate for agent infrastructure. It accepts a proposed list of tool calls—each with declared inputs, outputs, and dependency relationships—and returns a structured pass/fail assessment. The primary job-to-be-done is preventing incorrect parallelization, race conditions, and inconsistent state before the execution engine dispatches any tool. Platform engineers and agent infrastructure teams use this prompt in the orchestration layer, positioned after a planner or agent proposes tool calls but before the execution engine runs them. It is not a runtime recovery prompt, a retry handler, or a tool output interpreter.

Use this prompt when your agent system generates multi-tool execution plans and you need automated validation of dependency correctness. Required context includes the full list of proposed tool calls, each tool's declared input-output signature, and any explicit dependency annotations (e.g., requires-output-of, conflicts-with, must-follow). The prompt checks for missing dependencies, circular references, resource conflicts, ordering constraint violations, and read-after-write hazards. It produces a structured error report suitable for automated rejection or human review. Do not use this prompt for single-tool calls, for runtime error recovery after execution has started, or for validating the semantic correctness of tool outputs—those belong to separate playbooks.

This prompt belongs in a pre-execution middleware layer. Wire it so that any plan failing validation is blocked with a detailed violation report, not silently executed. For high-risk domains—such as financial transactions, healthcare operations, or infrastructure mutations—require human approval on any plan that triggers a FAIL or CONDITIONAL_PASS result. The prompt works best with models that support structured output and tool-use reasoning (e.g., GPT-4, Claude 3.5 Sonnet). Avoid using smaller or instruction-untuned models for this task, as they may miss subtle dependency violations. After validation passes, hand the approved plan to your execution engine with confidence that ordering and dependency constraints are satisfied.

This prompt template is designed to be pasted directly into your orchestration layer. It accepts a proposed execution plan—a list of tool calls with their inputs and declared dependencies—and returns a structured pass/fail assessment. The model acts as a pre-execution validator, not an executor. It checks for missing dependencies, circular references, resource conflicts, and ordering constraint violations. The output is a machine-readable report that your system can use to automatically reject invalid plans before they cause runtime failures, race conditions, or inconsistent state.

textCopy
You are a pre-execution validation engine for tool call orchestration. Your job is to analyze a proposed execution plan and determine whether it is safe to execute. You do not execute any tools. You only validate the plan.

## INPUT
You will receive a proposed execution plan as a JSON object:

[EXECUTION_PLAN]

## VALIDATION RULES
Apply the following checks in order. Stop at the first violation unless [FAIL_FAST] is set to false.

1. **Missing Dependency Check**: For every tool call that declares a dependency on another tool call's output, verify that the referenced tool call exists in the plan and is scheduled to execute before the dependent call.
2. **Circular Dependency Check**: Traverse all dependency edges. If any cycle exists (A depends on B, B depends on A, or longer chains), flag it.
3. **Ordering Constraint Violation**: If the plan specifies a required execution order (e.g., sequential groups), verify that all dependency edges respect that order. A tool call must not depend on a tool scheduled to run after it.
4. **Resource Conflict Check**: If [RESOURCE_MAP] is provided, check whether any two tool calls in the same parallel group access the same mutable resource in conflicting ways (e.g., both writing to the same database row).
5. **Schema Compatibility Check**: For each dependency, verify that the output schema of the upstream tool contains the fields required by the downstream tool's input parameters.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "plan_valid": boolean,
  "violations": [
    {
      "type": "missing_dependency" | "circular_dependency" | "ordering_violation" | "resource_conflict" | "schema_incompatibility",
      "severity": "blocking" | "warning",
      "description": "Human-readable explanation of the violation.",
      "offending_tool_calls": ["tool_call_id", ...],
      "dependency_chain": ["tool_call_id", ...] | null,
      "suggested_fix": "Actionable suggestion to resolve the violation."
    }
  ],
  "dependency_graph_summary": {
    "total_nodes": number,
    "total_edges": number,
    "parallel_groups": number,
    "sequential_chains": number,
    "max_chain_depth": number
  }
}

## CONSTRAINTS
- Do not hallucinate tool outputs. You are validating the plan structure only.
- If the plan is valid, return an empty violations array and set plan_valid to true.
- If [FAIL_FAST] is true, return only the first blocking violation found.
- If the input plan is malformed or unparseable, return a single violation of type "invalid_plan" with severity "blocking".

To adapt this template, replace the square-bracket placeholders with values from your orchestration context. [EXECUTION_PLAN] should be the full JSON object representing the proposed tool calls, their arguments, and their declared dependencies. [FAIL_FAST] controls whether the validator stops at the first error or collects all violations—set it to true for latency-sensitive pre-flight checks and false for plan debugging interfaces. [RESOURCE_MAP] is optional; provide it when your tools share mutable state like databases, caches, or file systems. If omitted, the resource conflict check is skipped. The output schema is designed for direct consumption by your plan executor's guard: if plan_valid is false, reject the plan and log the violations array for the developer. For high-risk production systems, always pair this prompt with a post-execution audit that compares actual tool call order against the validated plan.

This prompt is designed to operate as a synchronous pre-execution gate inside an agent orchestration engine. Before any tool call plan is dispatched to the runtime, the planner's proposed execution graph—including tool names, arguments, and declared dependency edges—is serialized into the [EXECUTION_PLAN] input. The model's structured output is parsed to extract the pass boolean and the violations array. If pass is false, the orchestration engine must block execution entirely and route the violation report to the calling service. Do not attempt to auto-correct the plan using this prompt; its job is validation, not repair. For repair, chain a separate recovery prompt that consumes the violation report and the original plan.

The harness should enforce a strict schema contract on the model's output. Use your inference platform's structured output mode (e.g., JSON mode with a supplied schema, function calling with strict: true) to guarantee that the response matches the expected { pass: boolean, violations: [...] } shape. Each violation object must include tool_call_id, violation_type (one of missing_dependency, circular_reference, resource_conflict, ordering_constraint), description, and severity (blocking or warning). If the model returns a malformed response or the schema validation fails, retry once with the same plan and a stronger instruction to output only the specified JSON. After a second failure, escalate the plan for human review rather than guessing. Log every validation result—pass or fail—with the plan hash, model version, and latency for audit and regression testing.

For high-risk domains where a false-negative validation could cause data corruption or unauthorized state changes, insert a human approval step when the plan contains any blocking severity violation or when the model's confidence appears low. The harness can detect low confidence by checking for ambiguous violation descriptions or by using a separate LLM-as-judge prompt that scores the validation quality. In regulated environments, store the full validation payload—including the input plan, the model's output, and the human reviewer's decision—as an immutable audit record. This prompt is a guardrail, not a planner; never use it to generate execution plans, only to reject invalid ones.