Agent Action Retry Budget Exhaustion Escalation Prompt

This prompt is for agent harnesses that enforce a strict retry budget on tool calls or action steps. When an agent exhausts its allowed retries without achieving the required outcome, the system must stop looping and produce a structured escalation payload. The primary job-to-be-done is generating a clear, machine-readable failure summary and a human handoff request that includes the original goal, the actions attempted, the errors encountered, and the remaining system state. The ideal user is an AI reliability engineer or platform developer building autonomous or semi-autonomous agent orchestration layers where uncontrolled retries waste compute, increase latency, and degrade user trust.

Use this prompt when your agent runtime tracks a retry counter per action or per plan step, and you need a deterministic handoff point. The prompt expects structured inputs: the original objective, the sequence of attempted actions with their error messages, the retry budget limit, and the current agent state. It is not appropriate for simple single-turn retries, for workflows without a defined budget, or for cases where the model should decide autonomously whether to keep retrying. Do not use this prompt when the failure is transient and a simple backoff-and-retry loop is sufficient. This prompt is specifically for the moment when the budget counter hits zero and the system must escalate rather than attempt another correction.

Before wiring this into production, ensure your harness accurately tracks the retry budget and can distinguish between retryable errors (timeouts, transient API failures) and non-retryable errors (authorization denials, schema violations). The escalation payload produced by this prompt should be validated for completeness: check that the failure summary includes all attempted actions, that the handoff request contains enough context for a human operator to resume without replaying the entire trajectory, and that the escalation reason is unambiguous. In high-risk domains such as finance or healthcare, the escalation payload must be logged immutably and routed to a human review queue with appropriate urgency tagging. Avoid using this prompt as a substitute for proper error classification earlier in the pipeline; the retry budget should only count errors that are genuinely retryable.

This prompt is designed to be injected into an agent harness after a retry budget counter reaches zero. Its job is not to attempt another fix but to produce a clear, auditable escalation payload. The template uses square-bracket placeholders for all dynamic inputs, making it safe to template in code before sending to the model. The output is a structured summary that a human operator or upstream orchestrator can consume without replaying the entire failure history.

textCopy
SYSTEM: You are an agent escalation handler. Your only job is to produce a structured failure summary when the agent's retry budget is exhausted. Do not suggest further retries. Do not attempt to fix the problem.

USER: The agent has exhausted its retry budget of [MAX_RETRIES] attempts for the action [ACTION_NAME]. The original goal was:

[ORIGINAL_GOAL]

The action was attempted with these arguments:

[ACTION_ARGUMENTS]

Each attempt produced an error. Here is the error history in chronological order:

[ERROR_HISTORY]

The current agent state is:

[AGENT_STATE]

Additional context:

[CONTEXT]

Produce a structured escalation payload using this exact schema:

{
  "escalation_reason": "RETRY_BUDGET_EXHAUSTED",
  "action_name": "string",
  "original_goal": "string",
  "attempts_made": number,
  "error_summary": "string (concise classification of error types observed)",
  "last_error": "string (the most recent error message)",
  "state_at_failure": "string (relevant agent state at the time of the last failure)",
  "recommended_human_action": "string (specific, actionable next step for the human operator)",
  "blocking_issue": "string (the root cause that prevented success across all retries)",
  "urgency": "LOW | MEDIUM | HIGH | CRITICAL"
}

[OUTPUT_SCHEMA]

[CONSTRAINTS]
- Do not fabricate error details not present in the error history.
- If the error history is empty or incomplete, note that explicitly.
- Set urgency based on the original goal's criticality and the blocking issue's severity.
- The recommended_human_action must be specific enough for an operator to act on without additional research.

To adapt this template, replace each square-bracket placeholder with values from your agent runtime. [ERROR_HISTORY] should be a chronologically ordered list of error messages, timestamps, and any relevant metadata your harness captures. [AGENT_STATE] should include the last known valid state before the failure cascade began. If your system uses a different escalation schema, replace the JSON structure in [OUTPUT_SCHEMA] with your own. The [CONSTRAINTS] block is critical for high-risk domains—add requirements for evidence grounding, human review flags, or compliance fields as needed. Before deploying, validate that the prompt produces valid JSON matching your schema by running it against a set of known failure scenarios and checking the output with a schema validator.

This prompt is designed to sit at the boundary between an agent's retry loop and a human escalation queue. It should only be invoked when the agent's retry budget counter reaches zero after repeated action failures, tool timeouts, or validation errors. The harness must track the retry budget per action or per plan step, not globally, so that a single stuck action doesn't exhaust the budget for unrelated steps. Before calling this prompt, the harness should collect the original goal, the failed action description, the error messages from each attempt, the retry count, and any partial state changes the agent made during the failed attempts.

Wire the prompt into a dedicated escalation handler function that receives a structured failure context object. The handler should: (1) validate that the retry budget has actually been exhausted by checking the counter against the configured threshold; (2) assemble the prompt with all required placeholders filled from the agent's execution trace; (3) call the model with a low temperature setting (0.0–0.2) to produce a deterministic escalation payload; (4) parse the output against the expected schema using a JSON validator; (5) log the full escalation payload, including the model's failure classification and recommended handoff priority, to your observability system; and (6) route the escalation to the appropriate human queue based on the escalation_priority field. If the model output fails schema validation, retry once with a stricter schema reminder appended to the prompt. If it fails again, fall back to a pre-formatted escalation template with the raw error context attached.

For production reliability, implement a dead-letter queue for escalations that cannot be delivered to human reviewers within a configurable timeout. Track the retry_budget_remaining field in the prompt output against your actual budget counter to detect model hallucination of budget values. Add an eval step that checks whether the failure_summary accurately reflects the error messages from the execution trace—use an LLM judge with a rubric that penalizes fabricated error details. Finally, ensure that the escalation payload includes a unique escalation_id generated by the harness, not the model, so you can correlate escalations with agent traces in your observability platform. Avoid calling this prompt for transient errors that a simple retry with backoff would resolve; reserve it for cases where the agent has genuinely exhausted its recovery options and continuing autonomously would risk compounding the failure.