Escalation Prompt After Max Retries

This prompt is for reliability engineers and AI ops teams who need a deterministic, structured output when an AI workflow exhausts its retry budget. Instead of a generic error or a silent failure, this prompt instructs the model to produce a machine-readable escalation payload and a human-readable explanation. Use this when your system already has a retry loop in the application layer and you need the final failure to be observable, auditable, and actionable for on-call engineers or downstream routing systems.

Do not use this prompt as a first-resort error handler or to replace application-level retry logic. It is designed to be the final step in a chain where previous attempts—including self-correction prompts, validation repair loops, and tool-call retries—have already failed. The prompt assumes you have captured the original user intent, the sequence of failed attempts, and any validator error messages. Without this context, the model cannot produce a useful root-cause analysis or a trustworthy escalation payload. The output must be treated as a structured incident artifact, not as a message shown directly to end users without review.

Before wiring this into production, define your escalation schema, your routing rules, and your human-review policy. The prompt produces a payload you can forward to an incident management system, a dead-letter queue, or an on-call channel. If the failure involves regulated data, personally identifiable information, or safety-critical actions, always require human acknowledgment before the escalation is considered closed. The next step after reading this section is to review the prompt template and adapt the placeholders to match your system's retry budget, error taxonomy, and escalation targets.

This template is designed to be used as the final-turn user message after your retry loop exits. It instructs the model to stop attempting the original task, acknowledge the failure, and produce a structured degradation response that downstream systems and human operators can consume. The prompt assumes that prior turns contain the original request, tool call attempts, validation errors, and retry instructions. Use this when you need a predictable, auditable failure path rather than a silent or malformed error.

textCopy
SYSTEM: You are an escalation handler. All prior attempts to complete the user's request have failed after [MAX_RETRIES] retries. Your only job is to produce a structured failure response. Do not attempt the original task again. Do not guess. Do not fabricate a successful result.

USER: The original request was:
[ORIGINAL_REQUEST]

The following attempts were made:
[ATTEMPT_HISTORY]

The final error was:
[FINAL_ERROR]

Produce a JSON response that follows this exact schema:
{
  "status": "error",
  "error_code": "[ERROR_CODE]",
  "message": "A concise, human-readable explanation of what failed and why.",
  "attempts_exhausted": [MAX_RETRIES],
  "final_error": "[FINAL_ERROR]",
  "recommended_action": "One of: retry_later, human_review_required, input_correction_needed, or unsupported_request.",
  "audit_trail": [SUMMARY_OF_ATTEMPTS]
}

Constraints:
- Do not include any text outside the JSON object.
- The message field must be understandable by a non-technical user.
- The audit_trail field must be a concise array of strings summarizing each attempt.
- If the error suggests the request itself is invalid, set recommended_action to input_correction_needed.
- If the error appears transient, set recommended_action to retry_later.
- If you cannot determine the cause, set recommended_action to human_review_required.

Adapt this template by replacing the placeholders with values from your application's retry loop. [ORIGINAL_REQUEST] should contain the user's initial input. [ATTEMPT_HISTORY] should be a structured log of each retry attempt, including the model's response and any validation errors. [FINAL_ERROR] is the last error that triggered the escalation. [MAX_RETRIES] is the integer count of attempts made. [ERROR_CODE] should be a stable identifier from your error taxonomy that downstream monitoring can alert on. For high-risk domains, route outputs with recommended_action set to human_review_required to a review queue before any automated response is sent to the user.

The escalation prompt is not a standalone prompt. It is the terminal step in a retry recovery pipeline. After a primary prompt fails and subsequent retry or self-correction prompts exhaust their configured maximum attempts, the escalation prompt produces a structured failure payload that downstream systems and operators can act on. This harness must enforce a hard retry limit, capture the full failure context, and decide whether to escalate silently, notify a human, or both.

Implement the harness as a retry loop with a configurable max_retries parameter (typically 3–5). On each attempt, call the primary prompt, validate the output against the expected schema, and check any domain-specific eval criteria (e.g., citation completeness, tool-call validity, enum adherence). If validation fails, feed the validator error message and the failed output into a self-correction or retry recovery prompt. Increment the attempt counter. If the counter exceeds max_retries, invoke the escalation prompt with the full failure context: the original input, the last failed output, the accumulated validation errors, and the retry history. The escalation prompt should return a structured error payload containing at minimum an error_code, a human_readable_summary, the failed_attempts count, and a recommended_action (e.g., human_review, degraded_response, retry_with_different_model). Log this payload with a unique escalation_id and the full trace for auditability.

Model choice matters here. Use a model with strong instruction-following for the escalation step—this is not the place for a small or quantized model that might hallucinate the error structure. If the workflow is high-risk (finance, healthcare, legal, safety), the harness must route the escalation payload to a human review queue and must not return an unverified model output to the end user. For lower-risk workflows, you may return a degraded but safe fallback response directly, such as 'I wasn't able to complete this request. Our team has been notified.' Avoid the temptation to add more retries instead of fixing the root cause; if escalation fires repeatedly for the same failure pattern, invest in improving the primary prompt, the validation rules, or the retry recovery instructions rather than tuning the escalation message.