Plan Generation with Postcondition Contracts Prompt

This prompt is for agent planning modules that operate on mutable resources such as databases, file systems, cloud infrastructure, or persistent application state. When an agent modifies state across multiple steps, a silent partial failure in step 3 can corrupt the assumptions step 7 depends on. This prompt forces the model to define explicit postcondition contracts for every step: what the expected output is, what side effects must be observable, and what state changes must be verified before the next step can proceed. Use this prompt when your agent framework needs a plan that an execution harness can validate programmatically after each step, not just a list of instructions.

The ideal user is an AI engineer or platform developer building an agent execution loop that must detect and contain failures before they cascade. Required context includes the agent's available tools, their schemas and side-effect profiles, the target resource types, and the execution harness's validation capabilities. The prompt works best when the harness can actually perform the postcondition checks—querying a database row after a write, listing files after a create operation, or checking infrastructure state after a provisioning step. If your harness can only observe tool return values without verifying external state, this prompt will produce contracts you cannot enforce, creating a false sense of safety.

Do not use this prompt for read-only workflows, stateless transformations, or single-step tool calls where postcondition verification adds overhead without reducing risk. If your agent is summarizing documents, classifying text, or generating content without mutating external state, a simpler plan format without postcondition contracts will be faster and cheaper. Similarly, if your execution harness lacks the ability to perform side-effect verification, prefer a plan format that focuses on output validation rather than state-change contracts. The postcondition approach is specifically valuable when state corruption is the primary failure mode you need to defend against, not when output quality or format compliance is the main concern.

This prompt template is the core of the Plan Generation with Postcondition Contracts workflow. It instructs the model to produce a plan where every step is a contract, not just a description. Each step must declare its expected outputs, side effects, and state changes so that an execution harness can programmatically verify success before proceeding. The template is designed to be copied directly into your planning module, with square-bracket placeholders replaced by your specific goal, available tools, current state, and operational constraints.

textCopy
You are an agent planner that produces execution plans with verifiable postcondition contracts.

# OBJECTIVE
[GOAL]

# AVAILABLE TOOLS
[TOOLS]

# CURRENT STATE
[STATE]

# CONSTRAINTS
[CONSTRAINTS]

# OUTPUT SCHEMA
Produce a JSON plan with the following structure:
{
  "plan_id": "string",
  "goal_summary": "string",
  "assumptions": ["string"],
  "steps": [
    {
      "step_id": "string",
      "description": "string",
      "tool": "string",
      "arguments": {},
      "preconditions": ["string"],
      "postconditions": {
        "expected_output": "description of the primary output",
        "expected_side_effects": ["description of each expected side effect"],
        "expected_state_changes": [
          {
            "resource": "string",
            "property": "string",
            "expected_value": "description or value"
          }
        ]
      },
      "on_failure": "retry|skip|escalate|abort",
      "retry_budget": 0,
      "timeout_seconds": 0
    }
  ]
}

# RULES
1. Every step must have a non-empty postconditions block.
2. expected_state_changes must reference specific resources and properties.
3. If a step has no side effects, explicitly state "no side effects".
4. If a step does not modify state, explicitly state "no state changes".
5. Flag any step where postcondition verification is impossible with the given tools.
6. Do not include steps that cannot be executed with the available tools.

After pasting this template, replace [GOAL] with a clear, unambiguous description of the objective. Populate [TOOLS] with a structured list of available functions, their parameters, and their return types—this is critical because the model must map each step to a real tool. [STATE] should describe the current system state, including relevant resource identifiers and their known properties. [CONSTRAINTS] should include budgets, deadlines, permission boundaries, and any immutable rules. The output schema is strict by design: the postconditions block is what separates this prompt from a generic task list. Each expected_state_change must be specific enough that a validator function can compare it against actual state after execution. Before integrating this prompt into a production agent, run it against a set of known goals and manually inspect whether the generated postconditions are verifiable with your toolset.

The Plan Generation with Postcondition Contracts prompt is not a one-shot generator; it is a contract factory. Each step in the generated plan must define expected outputs, side effects, and state changes in a machine-readable schema. The implementation harness wraps this prompt in an execution loop that reads the plan, executes steps sequentially, and runs programmatic postcondition verification after every step before allowing the next step to proceed. Without this harness, the prompt produces a document that looks correct but provides no runtime safety.

The harness should parse the model's output into a typed plan object with a steps array. Each step object must include an id, a description, a tool or action field, an inputs map, and a postconditions block. The postconditions block is the critical contract: it must contain expected_output_schema (a JSON Schema or type descriptor), expected_side_effects (a list of observable state mutations), and expected_state_changes (a map of key-value assertions about system state after execution). After executing a step, the harness runs a validator function that compares actual outputs, side effects, and state against these contracts. If validation fails, the harness must halt execution, log the mismatch with the step ID and actual vs. expected values, and either trigger a replanning prompt or escalate to a human operator. Do not proceed to the next step on a failed postcondition.

For production deployments, implement the harness with a retry budget per step (default 1 retry with the same inputs before escalation), structured logging that captures the plan version, step ID, tool call, raw output, postcondition contract, and validation result, and a dead-letter queue for steps that fail validation after retries are exhausted. Choose a model with strong schema-following behavior (such as GPT-4o or Claude 3.5 Sonnet) and set response_format to json_schema or use tool-calling mode to enforce the plan structure. If the plan involves mutable infrastructure (databases, cloud resources, file systems), add a pre-execution state snapshot so the postcondition validator can compute diffs. The most common production failure is a step that succeeds at the tool level but produces output that fails schema validation—your harness must distinguish tool failures from contract failures and route them differently.