Agent Plan Feasibility Gate Prompt

This prompt acts as a safety interlock for autonomous agent systems. Before an agent executes a multi-step plan—such as modifying files, sending emails, or making API calls—this gate prompt evaluates the plan for feasibility, identifies missing preconditions, and assesses step-level risk. It produces a binary feasible/infeasible decision, preventing agents from executing plans that are logically broken, have unmet dependencies, or carry unacceptable risk. Use this prompt when your agent generates a plan and you need a structured, programmatic go/no-go signal before any side effects occur. This is not a planning prompt; it is a plan evaluation prompt. It assumes a plan already exists and needs validation.

The ideal user is an AI engineer or platform developer building an agent harness where plan execution carries real-world consequences. You should have a plan object—likely JSON with ordered steps, each containing an action type, parameters, and preconditions—ready to pass into this gate. The prompt requires a defined [RISK_LEVEL] threshold (e.g., 'low', 'medium', 'high') that determines how aggressively the gate rejects plans. It also benefits from [TOOLS] context describing what each tool does and its side-effect profile, so the model can reason about whether a step's preconditions are actually satisfiable given available capabilities.

Do not use this prompt as a substitute for proper planning. If your agent hasn't generated a coherent plan yet, use a planning prompt from the Agent Planning and Task Decomposition pillar instead. Do not use this gate for real-time safety-critical systems where latency constraints preclude LLM evaluation—hardcoded rule checks or deterministic validators are more appropriate there. Also avoid this prompt when the plan's risk is purely informational (e.g., a research agent that only reads data). The gate is designed for plans with side effects: writes, sends, deletes, or external API calls. For read-only plans, a simpler precondition check may suffice without the full feasibility and risk assessment overhead.

This prompt acts as a feasibility gate before an autonomous agent executes a multi-step plan. It forces the model to examine each step for missing dependencies, resource conflicts, safety violations, and logical impossibility rather than accepting the plan at face value. The template is designed to be wired into an agent orchestration layer where a proposed plan is intercepted, validated, and either approved for execution or returned for revision. Use this when the cost of a bad plan is high—data mutation, external API calls with side effects, or user-facing actions that cannot be easily undone.

textCopy
You are an execution feasibility auditor for autonomous agent systems. Your job is to evaluate a proposed execution plan and determine whether it can succeed given the available tools, current state, and known constraints. You must be skeptical of optimistic assumptions and identify what is missing before approving any action.

## INPUT

[PLAN_DESCRIPTION]

[AVAILABLE_TOOLS]

[CURRENT_STATE]

[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with exactly this structure:
{
  "feasible": boolean,
  "overall_risk": "low" | "medium" | "high" | "critical",
  "step_assessments": [
    {
      "step_index": number,
      "step_description": string,
      "feasible": boolean,
      "risk": "low" | "medium" | "high" | "critical",
      "missing_preconditions": [string],
      "failure_mode": string | null,
      "remediation_suggestion": string | null
    }
  ],
  "blocking_issues": [string],
  "warnings": [string],
  "requires_human_approval": boolean,
  "rationale": string
}

## EVALUATION RULES

1. For each step, verify that all required tools are present in [AVAILABLE_TOOLS] and that their required parameters can be satisfied from [CURRENT_STATE] or prior step outputs.
2. Flag any step that assumes success of a prior step without verification or error handling.
3. Identify circular dependencies where two steps each require the other's output before they can start.
4. Mark a step as infeasible if it requires external state not present in [CURRENT_STATE] and no prior step produces it.
5. Escalate to human approval if any step modifies production data, triggers financial transactions, sends user-facing communications, or accesses PII.
6. A plan is feasible only if every step is individually feasible and the dependency chain is complete.
7. Do not reject creative or unconventional approaches that are logically sound. Only reject plans with demonstrable gaps.

## CONSTRAINTS

- Base your assessment only on the information provided. Do not assume tools or state that are not listed.
- If a step's feasibility depends on an unverified assumption, flag it as a warning rather than blocking unless the assumption is provably false.
- For steps with high or critical risk, provide specific remediation suggestions.
- If the plan is infeasible, the rationale must explain exactly which steps fail and why.

To adapt this template, replace the four bracketed inputs before calling the model. [PLAN_DESCRIPTION] should contain the agent's proposed steps with their intended order and dependencies. [AVAILABLE_TOOLS] must list every tool the agent can invoke, including their parameter schemas so the judge can verify argument availability. [CURRENT_STATE] should capture the system state at the moment of evaluation—database records, environment variables, session data, or prior step outputs. [CONSTRAINTS] should encode operational boundaries such as rate limits, permission scopes, cost budgets, and safety policies. After receiving the output, check requires_human_approval first: if true, route to a review queue before any execution begins. If feasible is false, return the blocking_issues and step_assessments to the planning agent for revision rather than attempting execution. Validate the JSON structure before acting on the decision—malformed outputs should trigger a retry or fallback to a conservative block.

The Agent Plan Feasibility Gate Prompt is designed to sit as a synchronous checkpoint between plan generation and plan execution in an autonomous agent loop. After the planning agent produces a proposed execution plan, the entire plan—including steps, dependencies, and expected preconditions—is passed to this gate prompt. The gate returns a structured binary verdict (feasible or infeasible) along with a step-level risk assessment. This output should be parsed by the orchestration layer before any tool calls or state mutations occur. The prompt is not a planner itself; it is a critic that validates whether the plan is safe and likely to succeed given the available tools, context, and constraints.

To wire this into an application, construct the prompt input by serializing the proposed plan into the [PLAN] placeholder. The plan should include an ordered list of steps, each with a description, the tool or action to invoke, expected inputs, and declared preconditions. The [AVAILABLE_TOOLS] placeholder must contain a machine-readable manifest of tool names, parameter schemas, and side-effect classifications (e.g., read-only, mutating, destructive). The [CONSTRAINTS] placeholder should encode operational boundaries such as rate limits, cost budgets, and forbidden actions. After invoking the LLM, parse the response against a strict JSON schema that requires the verdict field to be exactly `

feasible"or"infeasible

and the step_assessments array to contain an entry for every input step. If parsing fails

retry once with a repair prompt that includes the raw output and the schema; if it fails again

escalate to a human reviewer and log the full trace. For high-risk domains

always require human approval before executing any plan where the gate returns `

infeasible"or where any individual step is flagged with arisk_levelof"high"`."

Model choice matters here. Use a model with strong reasoning capabilities and reliable structured output support, such as GPT-4o or Claude 3.5 Sonnet, configured with a low temperature (0.0–0.2) to minimize variance in binary decisions. Enable structured output mode if available to enforce the JSON schema at the API level, reducing parse errors. Log every gate invocation with the input plan, the raw model response, the parsed verdict, and a timestamp. This audit trail is essential for debugging false positives (plans incorrectly rejected) and false negatives (plans incorrectly approved). Implement a metric dashboard tracking gate pass rate, parse failure rate, and the distribution of risk levels across steps. A sudden drop in pass rate may indicate prompt drift or a change in the planning agent's behavior that requires investigation.

Common failure modes in production include the gate rejecting creative but valid plans due to overly conservative constraints, and the gate approving plans that contain hallucinated tool names or impossible parameter combinations. To mitigate the first, periodically review a sample of rejected plans with a human expert and adjust the [CONSTRAINTS] or [EXAMPLES] to calibrate the gate's risk tolerance. To mitigate the second, cross-reference the tool_name fields in the plan against the actual [AVAILABLE_TOOLS] manifest before calling the gate, and reject plans with unknown tools at the orchestration layer. Never rely solely on the LLM to catch every tool hallucination. Finally, set a hard timeout on gate execution—if the model call exceeds your latency budget, default to a safe fallback: reject the plan, log the timeout, and alert the on-call engineer. Do not silently proceed with an unevaluated plan.