Partial Failure Detection Prompt for Multi-Step Agents

This prompt is for agent operators and platform engineers who run sequential tool chains where intermediate steps can fail silently. The core job-to-be-done is detecting partial failures—substeps that completed without throwing an exception but produced degraded, empty, or incorrect results—before those failures corrupt downstream reasoning. The ideal user is someone integrating multi-step agent workflows into production systems, such as a backend engineer wiring a research agent to a vector database and a web search tool, or an SRE running a diagnostic agent that queries multiple observability APIs in sequence. You need this prompt when your agent's execution graph is linear or branching but each step's output becomes the next step's input, creating a cascading failure risk.

Use this prompt when a step's return code or HTTP 200 is insufficient to guarantee correctness. For example, a web search tool might return a list of URLs with empty snippets, a code execution sandbox might return a zero-byte file, or a database query might return an empty result set when a non-empty one is expected. The prompt requires the full execution trace as input: the original objective, each step's intended function, the tool call arguments, and the raw output. It produces a structured health report classifying each step as SUCCESS, DEGRADED, or FAILURE, with evidence and a downstream corruption risk score. Do not use this prompt for single-step workflows, for agents with robust built-in error handling that already surfaces structured exceptions, or when the cost of the detection pass exceeds the cost of simply re-running the entire workflow.

Before implementing this prompt, ensure you have access to the complete step execution log, including tool call parameters and raw responses. If your agent framework does not log this data, instrument it first. The prompt is designed for post-hoc analysis after a multi-step run completes, not for real-time interception. For high-risk workflows involving mutable resources—database writes, cloud provisioning, or file system changes—pair this prompt with a human review step before any automated rollback or retry logic is triggered. The next section provides the copy-ready template you can adapt to your agent's specific tool set and failure taxonomy.

This template is designed to be dropped into an agent harness after a multi-step execution completes. It takes the original plan, the execution trace, and the outputs from each step, then produces a structured health report that identifies which substeps succeeded, which failed, and which produced degraded results. The prompt is built to catch cascading failure blindness—the most dangerous failure mode in sequential tool chains, where an early partial failure goes undetected and corrupts every downstream step.

textCopy
You are an agent execution auditor. Your job is to analyze a multi-step agent execution trace and produce a structured health report identifying which steps succeeded, which failed, and which produced degraded results.

## INPUTS

### Original Plan
[PLAN]

### Execution Trace
[EXECUTION_TRACE]

### Step Outputs
[STEP_OUTPUTS]

### Success Criteria Per Step
[SUCCESS_CRITERIA]

### Known Failure Modes
[KNOWN_FAILURE_MODES]

## OUTPUT SCHEMA

Return a JSON object with this structure:

{
  "workflow_id": "string",
  "overall_status": "success | partial_failure | failure | degraded",
  "steps": [
    {
      "step_id": "string",
      "step_name": "string",
      "status": "success | failure | degraded | skipped | unknown",
      "evidence": ["string"],
      "failure_mode": "string | null",
      "degradation_details": {
        "expected": "string",
        "actual": "string",
        "gap": "string"
      } | null,
      "downstream_impact": ["string"],
      "recoverable": true | false,
      "recommended_action": "retry | skip | rollback | escalate | continue"
    }
  ],
  "cascading_failures": [
    {
      "root_step_id": "string",
      "affected_steps": ["string"],
      "propagation_path": "string"
    }
  ],
  "summary": "string",
  "requires_human_review": true | false
}

## CONSTRAINTS

1. Do not assume a step succeeded just because it produced output. Check the output against the success criteria.
2. Flag any step where the output is valid but semantically degraded (e.g., correct structure but incomplete data).
3. For each failed or degraded step, identify which downstream steps consumed its output and assess whether corruption propagated.
4. If you cannot determine a step's status from the available evidence, mark it as "unknown" and request human review.
5. Do not recommend "continue" for any step where downstream corruption is confirmed.
6. Prioritize false negatives over false positives: it is safer to flag a healthy step for review than to miss a real failure.

## RISK LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with the relevant data from your agent runtime. [PLAN] should contain the original task decomposition with expected outputs per step. [EXECUTION_TRACE] should include tool calls, responses, and any error messages. [STEP_OUTPUTS] should contain the actual outputs from each completed step. [SUCCESS_CRITERIA] should define what constitutes success for each step—this is critical because the model cannot infer your domain-specific expectations without explicit criteria. [KNOWN_FAILURE_MODES] should list common failure patterns you have observed in your tool chain, such as silent API timeouts, partial writes, or schema drift. [RISK_LEVEL] should be set to high if any step mutates production resources, triggers financial transactions, or affects user-facing state; this will tighten the model's threshold for flagging degradation. [EXAMPLES] should include at least two annotated traces: one with a clean execution and one with a known partial failure, showing the expected health report for each.

Before deploying this prompt into a production harness, validate the output schema with a JSON schema validator and run at least 20 annotated traces through it to measure precision and recall on failure detection. Pay special attention to false negatives on degraded steps—these are the failures that will compound silently. If your agent operates on mutable resources, pair this prompt with a side-effect detection check and require human review when overall_status is partial_failure or degraded. Do not use this prompt as a replacement for step-level precondition and postcondition checks; it is a post-hoc audit layer that catches what those checks miss.

The partial failure detection prompt is not a standalone artifact; it is a gating function that sits between agent steps. Wire it into your agent's execution loop immediately after a multi-step tool chain completes and before any downstream step consumes the output. The prompt expects a structured input containing the original objective, the ordered list of substeps with their expected outcomes, and the actual outputs or side effects produced. Assemble this input programmatically from your agent's trace log, tool-call history, and state snapshot. Do not rely on the agent's own summary of what happened—use the raw tool outputs and return codes as ground truth. The model's job is to compare expected versus actual, not to reconstruct events from memory.

For the integration, wrap the prompt in a validation harness that enforces the output schema before the agent proceeds. The expected output is a JSON object with a step_results array, where each element contains step_id, status (one of success, failure, degraded), evidence, and cascading_risk (boolean). Implement a post-processing validator that rejects any response missing required fields or containing status values outside the enum. If validation fails, retry the prompt once with the validation error message appended as additional context. If the retry also fails, escalate to a human operator or trigger a safe abort—never proceed with an unvalidated health report. Log every invocation, including the input assembly, raw model response, validation result, and the final gating decision, to an audit trail for debugging cascading failures later.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may conflate degraded and failure statuses or miss subtle evidence of partial completion. Set temperature to 0 or near-zero to minimize variance in status classification. If your agent operates in a high-risk domain—such as database migrations, financial transactions, or infrastructure changes—add a human review step for any health report containing a failure or cascading_risk: true flag before the next step executes. The prompt is a detection tool, not an auto-remediation tool; it tells you what broke, but deciding whether to roll back, retry, skip, or abort is a separate decision prompt that should follow this one.