Retry Budget Exhaustion Escalation Prompt

This prompt is designed for a specific, high-stakes decision point: the moment an agent's per-tool retry counter exceeds its configured maximum budget. It is not a general-purpose error handler or a replacement for initial retry logic. Its sole job is to force a structured, reasoned escalation decision when the system can no longer justify another immediate retry. The ideal user is an agent developer or platform reliability engineer who is already tracking per-tool retry counts, error types, and latency data, and who needs to encode a deterministic, auditable handoff from the retry loop to an escalation policy.

You should invoke this prompt only after a tool call has failed and the agent's internal retry counter for that specific tool and operation has been incremented past the allowed threshold. The required context includes the tool's name, the total retries attempted, the error signatures from the most recent failures, the tool's idempotency status, and any relevant latency data. Do not use this prompt for simple binary retry/abort decisions on a single attempt; that is the job of the sibling Tool Retry vs Abort Decision Prompt. This prompt assumes the retry budget is fully consumed and a higher-order decision—fail fast, switch to a fallback, queue for async retry, or alert on-call—is now mandatory.

Before wiring this prompt into your agent loop, ensure you have a reliable mechanism for resetting the retry counter when a tool call succeeds or when a new user request begins. A common failure mode is invoking this escalation prompt prematurely because a shared counter was not properly scoped to the operation. The next step after reading this section is to review the prompt template and implementation harness, which will show you how to pass the required variables, validate the model's output against a strict decision schema, and log the escalation decision for operational visibility.

The following prompt template is designed to be injected into your agent's control loop at the exact moment the retry budget for a specific tool call is consumed. Its job is to force a structured decision—fail fast, switch to a fallback, queue for asynchronous processing, or alert a human on-call—instead of allowing the agent to loop indefinitely or hallucinate a recovery. The prompt expects runtime values from your retry budget tracker, tool registry, and circuit breaker state to be substituted into the placeholders before the model is invoked.

textCopy
SYSTEM: You are a reliability decision engine for an autonomous agent. Your only job is to produce a structured escalation decision when a tool's retry budget is exhausted. Do not attempt to call the tool again. Do not apologize. Do not invent a successful result.

CONTEXT:
- Failed Tool: [TOOL_NAME]
- Tool Call ID: [CALL_ID]
- Retry Budget Consumed: [RETRIES_USED] / [RETRIES_ALLOWED]
- Error History (most recent last):
[ERROR_HISTORY]
- Circuit Breaker State for [TOOL_NAME]: [CIRCUIT_STATE]
- Available Fallback Tools: [FALLBACK_TOOLS]
- User-Facing Impact: [USER_IMPACT]
- Current Task Step: [TASK_STEP]

DECISION RULES:
1. If the error is non-transient (invalid argument, auth failure, resource not found), decide FAIL_FAST.
2. If a fallback tool is available and its circuit breaker is CLOSED or HALF_OPEN, decide SWITCH_TO_FALLBACK.
3. If the task is not latency-sensitive and an async queue exists, decide QUEUE_FOR_ASYNC.
4. If the error is transient but the circuit breaker is OPEN, decide QUEUE_FOR_ASYNC or FAIL_FAST.
5. If user impact is HIGH and no automated recovery path exists, decide ALERT_ONCALL.

OUTPUT_SCHEMA:
{
  "decision": "FAIL_FAST" | "SWITCH_TO_FALLBACK" | "QUEUE_FOR_ASYNC" | "ALERT_ONCALL",
  "rationale": "string (max 200 chars, cite specific error and rule)",
  "fallback_tool": "string | null (required if SWITCH_TO_FALLBACK)",
  "user_message": "string | null (what to tell the user, if anything)",
  "alert_priority": "P1" | "P2" | "P3" | null (required if ALERT_ONCALL)",
  "evidence": {
    "terminal_error_type": "string",
    "circuit_breaker_state": "string",
    "retries_exhausted": true
  }
}

CONSTRAINTS:
- Do not suggest retrying the same tool.
- If SWITCH_TO_FALLBACK, the fallback_tool must be from the provided FALLBACK_TOOLS list.
- If ALERT_ONCALL, alert_priority must be P1 for user-facing impact, P2 for internal degradation, P3 for cosmetic.
- user_message must be honest about degradation; do not promise a fix timeline unless known.

To adapt this template, replace every square-bracket placeholder with live data from your agent runtime. The [ERROR_HISTORY] field should be a chronologically ordered list of error codes, messages, and timestamps from each failed attempt—this is the primary evidence the model uses to classify the error as transient or terminal. The [FALLBACK_TOOLS] list must be drawn from your tool registry and filtered to only include tools whose circuit breaker state is not OPEN. Before deploying, validate that your retry budget tracker correctly increments [RETRIES_USED] and that the escalation handler is only invoked when [RETRIES_USED] equals [RETRIES_ALLOWED]. For high-risk domains, route ALERT_ONCALL decisions to a human review queue before paging, and log every decision with the full prompt context for post-incident analysis.

This prompt is not a standalone script; it is a decision node inside a larger retry governance system. The agent's execution loop should invoke this prompt only when the retry budget for a specific tool call or action sequence has been fully consumed. The prompt's output is a structured escalation decision that the harness must parse and execute, not a suggestion to be ignored. The harness is responsible for tracking retry counts, timestamps, error signatures, and budget state before the prompt is ever called, ensuring the model receives accurate, pre-computed budget exhaustion facts rather than being asked to infer them from conversation history.

The implementation harness must enforce several hard constraints. First, budget tracking accuracy: the harness should maintain an atomic counter of retries, a timestamp of the first attempt, and a structured log of error codes and latency for each failed call. This data becomes the [RETRY_LOG] input to the prompt. Second, decision enforcement: the harness must parse the model's output against a strict schema (e.g., action: FAIL_FAST | SWITCH_TO_FALLBACK | QUEUE_ASYNC | ALERT_ONCALL, with a required rationale field) and reject any response that does not conform. If parsing fails, the harness should default to a safe action (typically FAIL_FAST with an alert) rather than retrying the prompt itself. Third, fallback execution: if the decision is SWITCH_TO_FALLBACK, the harness must have a pre-registered fallback tool or degraded mode ready to invoke with adapted inputs. The prompt's fallback_plan field should specify which fallback to use, but the harness validates that the fallback exists before executing it.

For production deployment, instrument this node with structured logging that captures the retry budget state, the prompt's raw response, the parsed decision, and the eventual action taken. This log becomes critical for postmortem analysis and for tuning the retry budget thresholds themselves. Additionally, implement a premature escalation detector as a separate monitoring check: if the harness observes that the escalation prompt is being triggered while tool latency remains within normal percentiles or error rates are below defined thresholds, flag this as a configuration error. The retry budget parameters (max retries, time window, error types that consume budget) should be tunable via runtime configuration, not hardcoded in the prompt. Finally, avoid wiring this prompt into a naive retry loop where the escalation decision itself can be retried—the escalation node must execute exactly once per budget exhaustion event, and its decision must be final for that event window.