Retry Budget Exhaustion Escalation Prompt Template

This prompt is designed for platform engineers and reliability engineers building agent harnesses and automated AI pipelines. Use it when a retry budget has been fully consumed and the system must stop retrying, package the failure context, and route a structured escalation payload to a human operator, a dead-letter queue, or an incident management system. The prompt assumes you have already tracked retry attempts, error messages, and the original task context. It does not decide whether to retry; it executes the escalation handoff after the budget is exhausted.

Before invoking this prompt, your harness must have already enforced the retry budget—whether token-based, time-based, cost-based, or attempt-counted—and confirmed that no further retries are permitted. The harness should provide the prompt with a complete failure history: the original task definition, each retry attempt with its error or failure reason, any partial results produced, and the specific budget threshold that was breached. The prompt's job is to synthesize this raw telemetry into a structured escalation record that a downstream system or human reviewer can act on without reconstructing context from scattered logs.

Do not use this prompt when the retry budget has not yet been exhausted, when the failure is immediately recoverable with a known fix, or when the system should silently degrade without escalation. This prompt is also inappropriate for non-critical workflows where escalation adds overhead without value—if the task is low-stakes and failure is acceptable, log and drop the task instead. For high-risk domains such as healthcare, finance, or safety-critical infrastructure, always route the escalation payload through a human approval queue and ensure the payload includes traceable evidence links, not just model-generated summaries. The next section provides the copy-ready template you can adapt to your escalation schema and routing logic.

This prompt template is designed to be called by your agent harness or orchestration layer the moment a retry budget counter reaches zero. Its job is not to attempt another fix, but to produce a structured escalation payload that a human operator or downstream routing system can act on immediately. The template assumes you have already tracked the original task, each retry attempt, the error or validator output from each attempt, and the cumulative cost or latency incurred. Populate the placeholders with that tracked state before calling the model.

textCopy
SYSTEM:
You are an escalation handler for an AI agent platform. Your only job is to produce a structured escalation payload when a retry budget has been exhausted. Do not attempt to solve the original task. Do not suggest further retries. Package the failure context completely and recommend a clear next action for a human operator or fallback system.

USER:
The agent has exhausted its retry budget for the following task. Produce an escalation payload.

ORIGINAL TASK:
[TASK_DESCRIPTION]

TASK_ID: [TASK_ID]
SESSION_ID: [SESSION_ID]

RETRY POLICY:
Budget Type: [BUDGET_TYPE]  // e.g., token_count, wall_clock_time, attempt_count, cost_usd
Budget Limit: [BUDGET_LIMIT]
Budget Consumed: [BUDGET_CONSUMED]

RETRY HISTORY (oldest first):
---
[RETRY_ATTEMPTS]  // Array of objects: { attempt_number, timestamp, error_type, error_message, action_taken, output_snippet, cost_or_latency_delta }
---

FINAL ERROR:
Error Type: [FINAL_ERROR_TYPE]
Error Message: [FINAL_ERROR_MESSAGE]

CUMULATIVE COST: [CUMULATIVE_COST_USD]
CUMULATIVE LATENCY: [CUMULATIVE_LATENCY_MS]

OUTPUT_SCHEMA:
{
  "escalation_id": "string, unique ID for this escalation event",
  "task_id": "string",
  "session_id": "string",
  "escalation_reason": "string, summary of why the budget was exhausted",
  "failure_classification": "string, one of: transient_infrastructure | persistent_tool_error | schema_violation | hallucination | policy_refusal | plan_deviation | rate_limited | unknown",
  "retry_summary": {
    "total_attempts": "integer",
    "error_types_seen": ["string"],
    "was_progress_made": "boolean, did any retry improve the output before ultimate failure?",
    "last_partial_success": "string or null, any partial result worth preserving"
  },
  "recommended_action": "string, one of: human_review | route_to_fallback_model | dead_letter_queue | abort_task | retry_with_different_strategy",
  "human_handoff_context": {
    "summary_for_operator": "string, plain-language summary of what happened and what the operator needs to decide",
    "evidence_package": ["string, key log lines, error traces, or output snippets the operator should see"],
    "urgency": "string, one of: low | medium | high | critical"
  },
  "routing_hints": {
    "suggested_team": "string or null",
    "suggested_fallback_model": "string or null",
    "do_not_retry_before": "ISO8601 timestamp or null"
  }
}

CONSTRAINTS:
- Do not fabricate details not present in the retry history.
- If the same error occurred on every retry, classify the failure as persistent and set was_progress_made to false.
- If a partial result exists, include it in last_partial_success; otherwise set to null.
- Set urgency to critical only if the task is time-sensitive and the failure blocks a downstream system.
- If the error type suggests a rate limit or infrastructure outage, set do_not_retry_before to a reasonable backoff timestamp.

After pasting this template into your escalation handler, wire the placeholder population step to your retry-tracking store. The RETRY_ATTEMPTS array is the most critical field—each entry must include the error type and the action the retry logic took, because the model uses that history to decide whether progress was made and whether the failure is persistent or transient. Before deploying, run at least five eval cases: a transient infrastructure failure, a persistent schema violation, a hallucination loop, a rate-limit exhaustion, and a task that produced a usable partial result. Validate that the output JSON parses, that failure_classification matches the ground-truth error category, and that recommended_action is appropriate for each scenario. For high-risk domains, route the generated payload to a human review queue and log the escalation event with the full retry trace attached.

This prompt is designed to be the final step in a retry loop, not a standalone call. It should only be invoked when a retry budget counter—tracking attempts, tokens, time, or cost—has been exhausted. The harness must pass in the full failure history, including the original task, each attempt's output, the error or validator rejection for each, and any tool-call traces. Without this context, the escalation payload will be incomplete and the human reviewer won't have enough information to act.

Wire this prompt into your agent's error-handling path. After each failed attempt, append a structured record to a retry_history array containing attempt_number, timestamp, model_used, output, error_type, error_message, and validator_result. When the budget counter reaches zero, construct the prompt's [RETRY_HISTORY] placeholder by serializing this array. The [ORIGINAL_TASK] should include the user's input, the system prompt, and any tool definitions that were active. The [ESCALATION_POLICY] placeholder should contain your organization's routing rules: who reviews what, SLAs, and any regulatory flags. Validate the model's output against a strict JSON schema that requires escalation_level, failure_summary, retry_timeline, recommended_action, assigned_team, and context_package. If the output fails schema validation, do not retry—log the failure and fall back to a static escalation template.

For high-risk domains, insert a human-review step before the escalation payload is delivered. The harness should route the generated payload to a review queue, not directly to the downstream team or system. Log every escalation event with a unique escalation_id, the full prompt, the raw model output, the schema validation result, and the reviewer's disposition. This audit trail is essential for tuning retry budgets and defending escalation decisions. Avoid using this prompt for non-escalation tasks—it is not a general summarizer or a retry prompt itself. If you find the model hallucinating details not present in the retry history, add an explicit constraint to the prompt: 'Do not invent or assume any failure details not present in the provided retry history.'