Fallback Chain-of-Thought Prompt

This prompt is for platform engineers and SRE teams who need a fallback agent to take over a failed task and show its reasoning step by step. The primary job-to-be-done is not just task completion, but auditable recovery. When a primary agent times out, returns an error, or produces unusable output, the fallback agent must produce a reasoned plan that explains what it assumed, what it is uncertain about, and why it chose its approach. The ideal user is an engineer integrating this into an agent orchestration framework where downstream systems or human reviewers need to audit the fallback decision. Required context includes the original task, the failure signal (error code, timeout duration, or validator rejection), any partial results from the primary agent, and the fallback agent's capability constraints.

Use this prompt when traceability matters more than speed. It is appropriate for high-stakes workflows—incident response, compliance reporting, financial reconciliation—where an opaque fallback answer is worse than a slower, explained one. Do not use this prompt when the fallback task is trivial, when latency is the primary constraint, or when the fallback agent is a simple retry wrapper with no reasoning surface. It is also a poor fit when the primary agent's failure mode is unknown or unclassified; in that case, pair it with an Agent Failure Mode Classification Prompt first to route the failure correctly. The prompt assumes the fallback agent has enough context to reason about the task, even if it lacks the primary agent's specialized tools or domain fine-tuning.

Before wiring this into production, define what a 'good' chain-of-thought looks like for your domain. At minimum, validate that the output contains explicit assumption markers, uncertainty flags for any inferred or missing data, and a decision rationale that references the original failure context. If the fallback agent's output will be shown to end users, add a human-review gate before exposure. If the output feeds another agent, ensure the downstream agent's prompt can parse and act on the structured reasoning fields. The next section provides the copy-ready template you can adapt and test against these criteria.

This prompt template is designed for platform engineers who need a fallback agent to take over a task after the primary agent fails, times out, or returns an unusable result. The template forces explicit reasoning, assumption disclosure, and uncertainty marking so that downstream systems and human reviewers can trace the fallback agent's decision process. Use this when you need a reasoned fallback plan rather than a silent best-guess response.

textCopy
You are a fallback reasoning agent. The primary agent assigned to this task failed to produce a valid result. Your job is to construct the best possible response using available context while making your reasoning fully transparent.

## Task Context
[ORIGINAL_TASK]

## Primary Agent Failure Summary
[FAILURE_SUMMARY]

## Available Context
[AVAILABLE_CONTEXT]

## Constraints
[CONSTRAINTS]

## Output Schema
[OUTPUT_SCHEMA]

## Instructions
1. First, restate what you understand the original task to be and what the primary agent was expected to produce.
2. Identify what information you have and what critical information is missing. Mark each missing piece with an explicit gap label.
3. State every assumption you are making to fill those gaps. Number each assumption and explain why you chose it over alternatives.
4. For each assumption, assign an uncertainty level: LOW (well-supported by context), MEDIUM (reasonable inference), or HIGH (speculative).
5. Construct your fallback response following the output schema. For any field that relies on a HIGH-uncertainty assumption, prefix the value with [SPECULATIVE].
6. After the response, provide a decision rationale section explaining why you chose this fallback path over other possible approaches.
7. End with a list of questions you would ask a human to resolve the HIGH-uncertainty assumptions.

## Risk Level
[RISK_LEVEL]

If RISK_LEVEL is HIGH, you must additionally flag any part of your response that could cause harm if incorrect and recommend human review before action.

Adaptation notes: Replace [ORIGINAL_TASK] with the full task description the primary agent received. Populate [FAILURE_SUMMARY] with the error type, timeout duration, or partial output that triggered the fallback. [AVAILABLE_CONTEXT] should include any partial results, retrieved documents, or session state that survived the failure. [CONSTRAINTS] must carry forward the original constraints plus any new degradation constraints. [OUTPUT_SCHEMA] defines the expected response structure—keep it identical to the primary agent's schema so consumers don't need to handle two formats. [RISK_LEVEL] should be set to LOW, MEDIUM, or HIGH based on the task domain. For HIGH-risk tasks, add a human-in-the-loop step after the fallback agent produces its output. Validate the output by checking that every HIGH-uncertainty assumption is explicitly marked, that no fabricated data appears without a [SPECULATIVE] tag, and that the decision rationale references the actual failure context rather than generic reasoning.

The fallback chain-of-thought prompt is not a standalone artifact; it is a component inside an agent orchestration harness. When a primary agent fails—due to a tool error, timeout, or unavailable dependency—the orchestrator must invoke this prompt with a structured failure record, not raw logs. The harness is responsible for assembling the [FAILURE_CONTEXT], which includes the original user intent, the failed agent's role, the specific error or timeout signal, and any partial results produced before failure. Without this harness, the fallback agent receives insufficient context and produces a generic, untrustworthy plan.

Wire the prompt into your orchestration layer as a synchronous fallback step. After detecting a primary agent failure, the orchestrator should: (1) capture the failure event with a typed schema (e.g., agent_id, error_code, partial_output, tool_call_history); (2) populate the prompt's placeholders, especially [FAILURE_CONTEXT], [ORIGINAL_USER_REQUEST], and [AVAILABLE_TOOLS]; (3) invoke the model with a strict response_format requirement matching the [OUTPUT_SCHEMA] (JSON with reasoning_trace, assumptions, uncertainty_markers, fallback_plan, and escalation_decision); (4) validate the output against the schema before acting on it. If validation fails, retry once with the validation errors injected into [CONSTRAINTS]. If the retry also fails, escalate to a human operator with the raw failure record and the invalid model output attached. Log every invocation—including the prompt version, model, latency, and validation result—for later trace analysis and regression testing.

Model choice matters. Use a model with strong instruction-following and structured output support (e.g., GPT-4o, Claude 3.5 Sonnet) because the fallback agent must produce a parseable reasoning trace under degraded conditions. Avoid smaller or older models that may drop required fields or hallucinate tool capabilities when the [AVAILABLE_TOOLS] list is constrained. If the fallback agent itself fails, the harness must not loop indefinitely. Implement a circuit breaker: after two consecutive fallback failures for the same request, stop retrying, log the full failure chain, and route to a human review queue with a pre-formatted escalation payload. The fallback prompt is a safety net, not a replacement for root-cause fixing—monitor fallback invocation rates and use them to drive primary agent reliability improvements.