Error Propagation Analysis Prompt Template

This prompt is a pre-execution safety analysis tool for agent plans with multiple steps and explicit dependencies. Its job is to trace how a failure at any single step would propagate through the rest of the workflow, identifying single points of failure (SPOFs), cascading impact chains, and containment boundaries. You use it during the plan critique phase, after a structured plan with step IDs and dependency declarations exists but before the agent begins executing irreversible actions. The primary users are resilience engineers, SREs, and agent platform developers who need to design circuit breakers, place retry budgets, and decide where human approval gates belong.

The prompt assumes you already have a structured plan with explicit step IDs, dependency declarations, and a clear execution order. It is not a runtime error handler—it does not react to live failures. It is a static analysis that runs once before execution begins. The output is a propagation graph showing which steps are affected by each potential failure, ranked by blast radius. This lets you harden the most critical nodes first. For example, if a data-fetching step feeds five downstream analysis steps with no fallback, the prompt will flag it as a SPOF and recommend a cache, a default value, or a human-in-the-loop gate before those downstream steps run blind.

Do not use this prompt for simple linear workflows with no branching or for plans where every step is fully independent. If there are no dependencies to trace, the analysis produces noise rather than actionable findings. Also avoid using it on plans that are still being drafted—wait until the plan structure is stable and step IDs are finalized. For plans with high irreversibility (e.g., database mutations, external API writes, customer-facing actions), pair this prompt with the Side Effect Prediction and Review Prompt Template and the Human Approval Gate Placement Review Prompt Template before execution. If the propagation analysis reveals a SPOF with no feasible mitigation, escalate to a human reviewer rather than proceeding with a fragile plan.

This prompt template is designed to be pasted directly into your planning module or agent orchestrator's pre-execution review stage. It instructs the model to analyze a complete execution plan and trace how a failure at any given step would cascade through downstream dependencies. The output is a propagation graph that identifies single points of failure (SPOFs), estimates blast radius, and recommends containment boundaries. Replace every square-bracket placeholder with your actual plan, tool manifest, domain constraints, and risk tolerance before use. The template assumes you already have a generated plan; it does not generate the plan itself.

textCopy
You are a resilience engineer reviewing an agent execution plan before it runs. Your task is to perform an error propagation analysis.

INPUT PLAN:
[PLAN]

AVAILABLE TOOLS AND CAPABILITIES:
[TOOL_MANIFEST]

DOMAIN CONSTRAINTS:
[DOMAIN_CONSTRAINTS]

RISK TOLERANCE:
[RISK_LEVEL]

ANALYSIS INSTRUCTIONS:
1. For each step in the plan, identify what would happen if that step fails completely, produces incorrect output, or times out.
2. Trace the failure forward through all downstream steps that depend on the failed step's output. For each affected downstream step, describe the specific impact (blocked, corrupted input, incorrect decision, etc.).
3. Identify single points of failure: steps where failure would block all remaining progress with no alternative path.
4. For each failure propagation path, estimate the blast radius (number of steps affected, criticality of affected outcomes).
5. Recommend containment boundaries: specific points where the plan should insert validation checks, alternative paths, human approval gates, or safe stop conditions to limit propagation.

OUTPUT SCHEMA:
{
  "propagation_graph": [
    {
      "source_step_id": "string",
      "source_step_description": "string",
      "failure_mode": "complete_failure | incorrect_output | timeout | partial_output",
      "affected_steps": [
        {
          "target_step_id": "string",
          "target_step_description": "string",
          "impact_type": "blocked | corrupted_input | incorrect_decision | delayed | none",
          "impact_description": "string",
          "is_blocking": true | false
        }
      ],
      "blast_radius": {
        "steps_affected_count": number,
        "critical_outcomes_affected": ["string"],
        "recovery_possible": true | false
      }
    }
  ],
  "single_points_of_failure": [
    {
      "step_id": "string",
      "step_description": "string",
      "reason": "string",
      "all_downstream_blocked": true | false
    }
  ],
  "containment_recommendations": [
    {
      "insert_after_step_id": "string",
      "recommendation_type": "validation_check | alternative_path | human_approval_gate | safe_stop | retry_with_backoff",
      "description": "string",
      "mitigates_failure_modes": ["string"]
    }
  ],
  "summary": "string"
}

CONSTRAINTS:
- Do not invent failure modes that are impossible given the tool manifest.
- If a step has no downstream dependents, mark its blast radius as zero and note that it is safe to fail.
- For each containment recommendation, specify exactly where it should be inserted and what it protects against.
- If the plan already contains error handling, evaluate whether it is sufficient for the identified propagation paths.
- Flag any step where the tool manifest lacks a capability needed for recovery.

To adapt this template, replace [PLAN] with your structured plan output—ideally a JSON array of steps with IDs, descriptions, inputs, outputs, and dependencies. Replace [TOOL_MANIFEST] with the actual tool schemas available to your agent, including function signatures, permissions, and rate limits. Replace [DOMAIN_CONSTRAINTS] with any regulatory, latency, cost, or data-residency rules that constrain recovery options. Set [RISK_LEVEL] to 'low', 'medium', 'high', or 'critical' to calibrate the depth of analysis. After running the prompt, validate the output against your plan's actual dependency graph: a propagation path that references a non-existent dependency is a hallucination and should fail your eval. For high-risk domains, route the output to a human reviewer before accepting containment recommendations that modify execution flow.

The Error Propagation Analysis prompt is designed to run as a pre-execution safety gate before an agent plan is committed to a runtime. It should be wired into the planning pipeline after plan generation but before any tool calls or state mutations occur. The prompt expects a structured plan (list of steps with dependencies) and a tool manifest as input, and it returns a propagation graph that identifies single points of failure, cascading failure chains, and recommended containment boundaries. Because this analysis directly informs whether a plan is safe to execute, the implementation harness must treat the output as a gating decision, not an advisory note.

API call structure: The prompt should be called synchronously within the plan validation stage. Use a structured output mode (e.g., JSON mode or function calling with a strict schema) to enforce the propagation graph format. The request payload must include [PLAN_STEPS] (array of step objects with id, description, depends_on, and tool fields) and [TOOL_MANIFEST] (array of available tools with name, capabilities, and failure_modes). Set temperature=0 to minimize variance in failure analysis. Retry logic: If the model returns a malformed graph or fails schema validation, retry once with the validation error appended to the prompt as a correction hint. If the second attempt also fails, escalate to a human reviewer rather than silently proceeding. Do not retry more than twice—propagation analysis failures often indicate an ambiguous plan that needs human clarification. Human review gates: Any step flagged as a single point of failure with severity: critical must trigger a human approval gate before execution. Similarly, if the propagation graph identifies a failure chain that would cascade to more than 50% of remaining steps, route the plan for manual review. Log the full propagation graph, the gating decision, and the reviewer's action for auditability.

Model choice: Use a model with strong reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) for this analysis. Smaller or faster models often miss indirect dependency chains or underestimate cascading effects. Tool use: This prompt does not require tool calls during analysis—it operates on the plan and tool manifest provided in the prompt context. However, the output propagation graph should be consumable by downstream execution monitors that can halt the agent if a predicted failure materializes. Observability: Emit the propagation graph as a structured trace event with plan_id, analysis_timestamp, spof_count, and cascade_risk_score fields. This allows SRE teams to track whether predicted failures actually occurred and whether containment boundaries held. What to avoid: Do not run this analysis on every minor plan revision—cache results keyed by plan hash and tool manifest version. Do not treat the propagation graph as a static artifact; if the tool manifest changes or a step's dependencies are updated during replanning, re-run the analysis before resuming execution.