Tool Call Retry Budget Exhaustion Escalation Prompt Template

This prompt is the final instruction in a tool-call retry loop, activated only when the agent harness has exhausted its configured retry budget for a specific operation. Its job is to terminate the loop deterministically, preventing the waste of compute resources, violation of latency SLOs, and the user-facing degradation caused by infinite or prolonged retry cycles. The ideal user is a reliability engineer or platform developer who needs an auditable, structured handoff from autonomous recovery to human or upstream system intervention. The required context includes the original user intent, the complete failure history with error codes, the retry budget configuration, and any partial results that can be salvaged.

Do not use this prompt for initial retries, schema repairs, or argument correction attempts. Those workflows are handled by dedicated recovery prompts that instruct the model to fix a specific error. This prompt is exclusively for the budget-exhaustion boundary, where the system must stop trying to self-heal. Using it prematurely will cause unnecessary escalations and defeat the purpose of autonomous recovery. Using it too late, or not at all, results in a hung agent, a timeout, or a silent failure that is difficult to debug. The harness should track a retry_count against a max_retries configuration parameter and invoke this prompt only when retry_count >= max_retries.

Before wiring this prompt into production, ensure your harness distinguishes between retryable and non-retryable errors. A 400 Bad Request due to a malformed argument is retryable; a 403 Forbidden due to invalid credentials is not and should escalate immediately without consuming the retry budget. The escalation payload produced by this prompt should be logged, routed to a human review queue or a dead-letter topic, and never silently discarded. The next step is to pair this prompt with the Tool Call Retry with Progressive Disclosure of Error Context Prompt Template to ensure the model receives the right level of detail on each attempt before this termination boundary is reached.

This prompt template is injected as a system or developer message after the agent harness detects that the retry budget for a specific tool call has been fully consumed. Its job is to halt further retries, force the model to produce a structured escalation decision, and preserve any partial results or failure context for a human operator. The template uses square-bracket placeholders that your harness must populate before sending the request. Do not use this prompt for transient errors that are still within the retry budget; it is designed exclusively for the terminal state after all retries have failed.

textCopy
SYSTEM
You are a reliability agent operating in escalation mode. The retry budget for a tool call has been exhausted. You must not attempt any further tool calls. Your only task is to produce a structured escalation decision.

RETRY CONTEXT
- Original intent: [ORIGINAL_INTENT]
- Tool name: [TOOL_NAME]
- Last attempted arguments: [LAST_ARGUMENTS]
- Retry attempts consumed: [RETRY_COUNT] of [RETRY_BUDGET]
- Final error category: [ERROR_CATEGORY]
- Final error message: [ERROR_MESSAGE]
- Partial results available: [PARTIAL_RESULTS]
- Conversation summary (last 3 turns): [CONVERSATION_SUMMARY]

OUTPUT REQUIREMENTS
Produce a JSON object with the following schema:
{
  "decision": "ESCALATE" | "ABANDON" | "FALLBACK",
  "failure_summary": "A concise explanation of what was attempted and why it failed, suitable for a human operator.",
  "preserved_context": {
    "original_intent": "string",
    "last_valid_state": "any serializable partial result or null",
    "error_chain": ["ordered list of error messages from each retry attempt"]
  },
  "recommended_next_steps": "Specific actions a human should take, including which tool to try, what arguments to adjust, or what upstream system to check.",
  "confidence": "LOW" | "MEDIUM" | "HIGH"
}

CONSTRAINTS
- Do not suggest another retry. The budget is exhausted.
- If partial results exist, include them verbatim in preserved_context.last_valid_state.
- If the error category is PERMANENT (auth failure, invalid schema, resource not found), decision must be ABANDON or ESCALATE, never FALLBACK.
- If the error category is TRANSIENT but the budget is exhausted, decision must be ESCALATE.
- FALLBACK is only valid when an alternative tool or manual workaround is clearly available and described in recommended_next_steps.
- Do not fabricate success. If nothing worked, say so clearly.

To adapt this template, replace each square-bracket placeholder with live data from your retry harness. [ORIGINAL_INTENT] should capture the user's goal in one sentence. [ERROR_CATEGORY] must come from a taxonomy your harness maintains—classify each failure as TRANSIENT, PERMANENT, TIMEOUT, or UNKNOWN before injecting it. [PARTIAL_RESULTS] should be serialized as a string or null; if you have structured partial data, JSON-stringify it. The [CONVERSATION_SUMMARY] field prevents the model from losing context when the retry loop has consumed most of the context window. If your harness cannot provide a summary, omit this field and the surrounding sentence.

Before deploying, validate that your harness can parse the model's JSON output against the schema. If the model returns a decision other than ESCALATE, ABANDON, or FALLBACK, treat that as a harness-level failure and default to ESCALATE. Log every escalation output for post-mortem analysis. For high-risk domains where an incorrect escalation decision could cause harm, route the output to a human review queue before taking any automated action based on the decision field.

The escalation prompt is the terminal node in a retry harness. It should only be invoked after a counter has exceeded a configured [MAX_RETRIES] threshold and all prior recovery prompts have failed. The harness must maintain a structured retry log containing each attempt's error type, the recovery prompt used, and the model's response. This log becomes the primary input to the escalation prompt, enabling it to produce a coherent failure summary rather than a generic error message. The harness should also capture any partial results—validated arguments, intermediate tool outputs, or user clarifications—so the escalation payload preserves recoverable work.

Implement the retry loop as a state machine with three terminal states: success (valid tool call produced), escalation (budget exhausted, human handoff generated), and fatal (unrecoverable system error). Each iteration increments an attempt_count and appends a record to retry_history with the fields attempt_number, error_type, error_message, recovery_prompt_used, and model_response. Before invoking the escalation prompt, the harness should validate that attempt_count > [MAX_RETRIES] and that the last attempt did not succeed. The escalation prompt itself should be treated as a structured output call—request a JSON response matching [ESCALATION_SCHEMA] with fields for escalation_reason, failure_summary, partial_results_preserved, recommended_human_action, and retry_log_attached. Validate this schema before surfacing the escalation to a human or logging system. For high-stakes domains, route the escalation payload to a review queue rather than auto-resolving.

Avoid two common harness mistakes. First, do not call the escalation prompt inside the retry loop as just another recovery attempt—it is the exit condition, not a retry. Second, do not discard partial results when escalating. The partial_results_preserved field should contain any validated arguments, successful prior tool calls in a chain, or user-provided clarifications that a human operator can reuse. After escalation, the harness should log the full retry history and escalation decision to your observability stack for post-mortem analysis and prompt improvement. If the escalation prompt itself fails to produce valid JSON, fall back to a static template that surfaces the raw retry log and a generic 'manual intervention required' message.