Silent Failure Detection and Recovery Prompt

This prompt is for ops engineers and AI reliability SREs who need an AI system to detect when a previous action—such as a tool call, a sub-agent task, or a data retrieval step—produced no output, an empty result, or a null response, and then recover gracefully. The core job-to-be-done is to prevent silent failures from cascading into downstream steps that assume valid data exists. The ideal user is someone integrating this prompt into an agent harness, a multi-step RAG pipeline, or an automated workflow where an empty result could be a legitimate 'nothing found' scenario or a hidden system error. Required context includes the original request, the action taken, the raw output (or lack thereof), and any error codes or logs available. Do not use this prompt when the system already has deterministic error handling at the application layer, when the action's output is guaranteed by a strict schema, or when the cost of a false positive (flagging a legitimate empty result as a failure) is unacceptable without human review.

The prompt is designed to produce a structured failure detection signal, a root cause hypothesis, and a concrete recovery action. It forces the model to distinguish between three states: a true silent failure (e.g., a tool returned null due to an unhandled exception), a legitimate empty result (e.g., a database query that correctly returned zero rows), and an ambiguous case that requires further investigation. In practice, you should wire this prompt into a post-action validation step within your agent loop. After every tool call or retrieval step, the harness checks the output. If the output is empty, null, or matches a configurable 'silence' pattern, this prompt is invoked before the agent proceeds. The prompt's output should be parsed by the harness to decide whether to retry the action, route to a fallback tool, escalate to a human, or log the event and continue. For high-risk workflows, always pair this prompt with an eval that measures both the detection rate of injected silent failures and the false-positive rate on legitimate empty results.

Before deploying, build a small test suite that simulates common silent failure modes in your specific stack: a tool returning an empty string, a function returning undefined, an API returning a 200 with an empty body, or a database query returning zero rows for a known-present entity. Run this prompt against those cases and measure whether the failure_detected boolean and the root_cause_hypothesis field are accurate. If your system cannot tolerate any missed failures, implement a human review step for all cases where the model's confidence is below your threshold. Avoid using this prompt as a replacement for proper application-level error handling and logging; it is a safety net, not the primary defense.

This prompt template is designed to be inserted into a multi-step agent or pipeline where a previous action may have produced no output, an empty result, or a null response. It instructs the model to distinguish between a legitimate empty result (e.g., a search that correctly found nothing) and a silent failure (e.g., a tool crash, a timeout, or a parsing error that yielded no output). The model must produce a structured detection signal, a root cause hypothesis, and a concrete recovery action. Use this template when you need an operational safety net that prevents an agent from proceeding with missing context or silently corrupting downstream state.

codeCopy
SYSTEM:
You are a failure detection specialist operating inside an AI agent pipeline. Your job is to analyze the output of a previous action and determine whether it represents a legitimate empty result or a silent failure that requires recovery.

## INPUT
You will receive the following:
- [PREVIOUS_ACTION_DESCRIPTION]: What the previous step was supposed to do.
- [PREVIOUS_ACTION_OUTPUT]: The raw output from the previous step. This may be empty, null, or truncated.
- [EXPECTED_OUTPUT_SCHEMA]: The schema or shape the output was supposed to match.
- [CONTEXT]: Any relevant conversation history, tool definitions, or state that preceded the action.

## TASK
1. Analyze the previous action output against the expected schema and the action description.
2. Classify the result as one of: `LEGITIMATE_EMPTY`, `SILENT_FAILURE`, or `PARTIAL_OUTPUT`.
3. If `SILENT_FAILURE` or `PARTIAL_OUTPUT`, generate a root cause hypothesis from the following categories: `TOOL_ERROR`, `TIMEOUT`, `PARSE_ERROR`, `PERMISSION_DENIED`, `EMPTY_RESPONSE_BODY`, `TRUNCATION`, `WRONG_OUTPUT_TYPE`, or `UNKNOWN`.
4. Produce a recovery action. This must be a single, executable next step: `RETRY_WITH_BACKOFF`, `RETRY_WITH_ALTERNATIVE_TOOL`, `REPROMPT_WITH_CLARIFICATION`, `ESCALATE_TO_HUMAN`, `SKIP_AND_CONTINUE`, or `ABORT_WORKFLOW`.
5. If recovery is `RETRY_WITH_ALTERNATIVE_TOOL`, suggest the tool name from [AVAILABLE_TOOLS].

## CONSTRAINTS
- Do not hallucinate output. If the previous action output is empty, do not invent content.
- A legitimate empty result (e.g., a database query returning zero rows) must not be classified as a failure.
- If you cannot determine the cause with high confidence, set root cause to `UNKNOWN` and recovery to `ESCALATE_TO_HUMAN`.
- For [RISK_LEVEL] = `HIGH`, always prefer `ESCALATE_TO_HUMAN` over autonomous retry.

## OUTPUT_SCHEMA
Return a single JSON object with the following fields:
{
  "classification": "LEGITIMATE_EMPTY | SILENT_FAILURE | PARTIAL_OUTPUT",
  "root_cause_hypothesis": "TOOL_ERROR | TIMEOUT | PARSE_ERROR | PERMISSION_DENIED | EMPTY_RESPONSE_BODY | TRUNCATION | WRONG_OUTPUT_TYPE | UNKNOWN",
  "confidence": 0.0-1.0,
  "evidence": "string describing what led to this conclusion",
  "recovery_action": "RETRY_WITH_BACKOFF | RETRY_WITH_ALTERNATIVE_TOOL | REPROMPT_WITH_CLARIFICATION | ESCALATE_TO_HUMAN | SKIP_AND_CONTINUE | ABORT_WORKFLOW",
  "alternative_tool": "string or null",
  "recovery_rationale": "string explaining why this recovery action was chosen"
}

## EXAMPLES
[EXAMPLES]

## AVAILABLE TOOLS
[AVAILABLE_TOOLS]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your application's concrete values. [PREVIOUS_ACTION_DESCRIPTION] should be a one-sentence summary of what the prior step attempted. [PREVIOUS_ACTION_OUTPUT] is the raw string or object returned—pass it verbatim, even if empty. [EXPECTED_OUTPUT_SCHEMA] should be a JSON Schema, TypeScript interface, or plain description of the expected shape; this is critical for distinguishing a silent failure from a valid empty array or null field. [AVAILABLE_TOOLS] should list the tool names your agent can call during recovery. [RISK_LEVEL] accepts LOW, MEDIUM, or HIGH and gates whether autonomous retry is permitted. [EXAMPLES] should include at least two few-shot demonstrations: one showing a legitimate empty result (e.g., a search with no matches) and one showing a silent failure (e.g., a tool returning null when an object was expected). Without these examples, the model tends to over-classify empty results as failures. After adapting, validate the output against the schema before allowing the recovery action to execute. For high-risk workflows, route any ESCALATE_TO_HUMAN decision to a review queue and log the full detection payload for audit.

This prompt is designed to sit after a primary action step in an agentic or automated workflow—for example, after a tool call, a code execution step, or a retrieval query that returns an empty or null result. It should not be used as a standalone classifier for every model output; instead, wire it as a conditional recovery gate. The application should invoke this prompt only when the previous step's output is null, an empty string, an empty list, or a status code indicating no data was produced. Passing a legitimate empty result (e.g., a search that correctly found zero matches) through this prompt is a known failure mode, so the harness must distinguish between expected emptiness and silent failure before invocation. Use a pre-check: if the prior step had a non-zero exit code, threw an exception, or timed out, route directly to this recovery prompt. If the prior step completed successfully but produced no output, pass both the original input and the step's metadata (tool name, duration, error codes) into the prompt's [FAILED_STEP_CONTEXT] placeholder.

Validation and output contract. The prompt must return a structured JSON object with three required fields: failure_detected (boolean), root_cause_hypothesis (string), and recovery_action (string enum of [RETRY, ESCALATE, FALLBACK, IGNORE]). Implement a post-generation validator in your harness that rejects any response missing these fields or containing an invalid enum value. If validation fails, retry the prompt once with the validation error appended to [CONSTRAINTS]. For high-stakes workflows (e.g., financial transactions, clinical data processing), add a human review gate when recovery_action is ESCALATE or when failure_detected is true but root_cause_hypothesis confidence appears low. Log every invocation—including the pre-check decision, the prompt's raw output, validation result, and chosen recovery action—to your observability pipeline. Attach trace_id, step_id, and session_id as metadata so you can measure silent failure rates per tool, per model, and per workflow version over time.

Model choice and retry budget. This prompt benefits from models with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are good defaults. Avoid smaller or older models that may conflate failure_detected: false with an empty recovery action. Set a hard retry budget of two attempts for this prompt: one initial call, one retry on validation failure. If both attempts fail, the harness should default to recovery_action: ESCALATE and log the double-failure as a critical incident. Never loop silently. For latency-sensitive pipelines, consider caching the prompt prefix (system instructions and output schema) to reduce per-invocation token costs. Wire the chosen recovery_action directly into your workflow engine: RETRY re-invokes the failed step with corrected parameters, FALLBACK switches to an alternative tool or model, ESCALATE triggers a human queue or incident management system, and IGNORE allows the workflow to proceed with an empty result when the prompt determines the emptiness is legitimate.