Retry Budget Exhaustion Escalation Prompt

This prompt is for the boundary condition where an agent orchestrator has fully consumed its configured retry budget on a critical tool call and must make a structured, auditable decision. The job-to-be-done is not error handling or retry logic—those belong to upstream prompts like the Retry Decision Prompt for Transient Failures or the Tool Failure Detection Prompt Template. This prompt fires only after those mechanisms have been exhausted. The ideal user is a reliability engineer or agent developer who needs deterministic behavior at the edge of automated recovery, ensuring the system does not loop infinitely, fail silently, or escalate prematurely. Required context includes the original task goal, the tool's failure history with timestamps and error classifications, the retry policy that was exhausted, any partial results recovered, and the current state of dependent tasks in the workflow.

Do not use this prompt as a general error handler. It is specifically designed for the moment when the retry budget counter reaches zero. Using it earlier—such as on the first or second failure—bypasses the retry mechanisms that resolve most transient issues and generates unnecessary human review load or workflow aborts. Using it later—by allowing the agent to continue retrying after the budget is exhausted—defeats the purpose of having a budget and can lead to resource exhaustion, rate-limit lockouts, or silent failure. The prompt assumes that the upstream retry logic has already classified the error, attempted modified arguments where safe, and respected idempotency constraints. If those steps haven't happened, the escalation decision will be based on incomplete information. The output is not a suggestion; it is a structured decision that the orchestrator should execute, including an audit trail entry for governance and post-incident review.

Before wiring this prompt into your orchestrator, ensure you have a well-defined retry budget with clear units (e.g., max attempts, max elapsed time, or max cost), a failure classification taxonomy that upstream prompts populate consistently, and a human review queue or fallback chain that is actually provisioned and monitored. The most common production failure mode is not a bad escalation decision—it's an escalation that lands in an unmonitored queue or triggers a fallback chain that was never tested end-to-end. Validate the entire path: retry exhaustion → escalation prompt → decision execution → human acknowledgment or fallback completion. If any link in that chain is broken, the prompt will produce a correct decision that the system cannot fulfill.

This prompt is designed to be the final decision point in your agent's retry loop. It should be invoked only after the orchestrator has logged all retry attempts, captured the full error history, and confirmed that the configured retry budget (max attempts, time, or cost) has been reached. The prompt forces the model to choose a concrete escalation path—abort, fallback, human review, or degraded continue—rather than looping indefinitely or hallucinating a recovery. It also requires an impact assessment and a structured audit trail entry, making the decision explainable to downstream systems and human reviewers.

textCopy
You are an agent orchestrator at a critical decision point. The retry budget for a tool call has been exhausted. You must produce a structured escalation decision. Do not attempt further retries. Do not fabricate a successful result.

## TOOL CALL CONTEXT
- Tool name: [TOOL_NAME]
- Tool description: [TOOL_DESCRIPTION]
- Original arguments: [ORIGINAL_ARGUMENTS]
- Task the tool was supposed to accomplish: [TASK_INTENT]
- Criticality level: [CRITICALITY_LEVEL] // Options: 'critical' (workflow cannot proceed without this), 'high' (significant degradation), 'medium' (acceptable workaround exists), 'low' (optional enhancement)

## RETRY HISTORY
- Retry budget: [MAX_RETRIES] attempts over [MAX_RETRY_DURATION_SECONDS] seconds
- Attempts made: [ATTEMPT_COUNT]
- Total time spent: [ELAPSED_SECONDS] seconds
- Error log per attempt (chronological):
[ERROR_LOG] // Array of objects: { attempt: number, timestamp: ISO8601, error_type: string, error_message: string, arguments_used: object, duration_ms: number }

## AVAILABLE ESCALATION OPTIONS
[ESCALATION_OPTIONS] // Array of objects: { option_id: string, option_type: 'abort' | 'fallback_tool' | 'human_review' | 'degraded_continue', description: string, fallback_tool_name?: string, fallback_tool_capabilities?: string, human_queue?: string, estimated_human_response_time?: string, degraded_output_schema?: object }

## WORKFLOW STATE
- Overall task progress (0.0 to 1.0): [TASK_PROGRESS]
- Remaining steps after this tool: [REMAINING_STEPS]
- Overall task deadline: [TASK_DEADLINE_ISO8601]
- Upstream dependencies that have already succeeded: [UPSTREAM_SUCCESSES]
- Downstream dependencies waiting on this result: [DOWNSTREAM_DEPENDENTS]

## OUTPUT SCHEMA
Return a single JSON object with these exact fields:
{
  "decision": {
    "chosen_option_id": "string (must match an option_id from ESCALATION_OPTIONS)",
    "rationale": "string (explain why this option was chosen over alternatives, referencing specific error patterns, progress state, and deadline pressure)",
    "confidence": "number (0.0 to 1.0, your confidence that this escalation is the correct path)"
  },
  "impact_assessment": {
    "task_blocked": "boolean (true if the overall task cannot proceed)",
    "data_loss_risk": "'none' | 'partial' | 'significant'",
    "estimated_delay_minutes": "number (additional delay this escalation introduces)",
    "downstream_impact": "string (describe what happens to dependent steps)"
  },
  "audit_trail": {
    "escalation_reason": "string (summary of why retries failed, suitable for audit logs)",
    "attempts_exhausted": "number",
    "dominant_error_type": "string (the most frequent or impactful error type from the retry history)",
    "recommended_postmortem_action": "string (what should be investigated to prevent recurrence)"
  },
  "user_communication": {
    "internal_message": "string (message for system operators, can include technical details)",
    "external_message": "string or null (message for end users if applicable, must not leak system internals)"
  }
}

## CONSTRAINTS
- Do not choose an option that is not in the provided ESCALATION_OPTIONS list.
- If the task deadline has passed or is within [DEADLINE_BUFFER_SECONDS] seconds, prefer abort or degraded_continue over human_review unless human review is instantaneous.
- If data_loss_risk is 'significant', human_review is strongly preferred unless explicitly unavailable.
- The external_message must never contain stack traces, error codes, tool names, or internal system details.
- If the dominant error type is 'authentication_failure' or 'authorization_failure', do not suggest retry-like fallbacks; escalate to human_review or abort.
- If all retry attempts returned the same error type with no variation in arguments, note this as a probable systemic issue, not a transient failure.

To adapt this prompt for your system, replace the square-bracket placeholders with runtime values from your orchestrator's state store. The ERROR_LOG should be a serialized JSON array of attempt records—do not summarize or truncate it unless context length forces pruning, in which case keep the first attempt, the last attempt, and any attempt where the error type changed. The ESCALATION_OPTIONS array must be generated dynamically from your tool registry and human review queue configuration; never hardcode it. Before deploying, validate that your orchestrator enforces the chosen escalation path—if the prompt selects human_review, your system must actually route to a review queue, not silently continue. Test this prompt against at least three scenarios: a transient failure that genuinely exhausted retries, a systemic auth failure, and a deadline-overrun case where the correct answer is abort, not further waiting.

This prompt is designed to be the final decision point in an agent's retry loop, not a standalone module. It should be invoked by the orchestrator only after a retry counter has been exhausted against a specific tool call. The orchestrator must pass in the full failure history, the original task context, the remaining workflow steps, and any partial results. The prompt's output is a structured escalation decision that the orchestrator must parse and execute—abort, request human review, switch to a fallback chain, or continue in a degraded mode. Do not call this prompt preemptively; it is a circuit breaker, not a diagnostic tool.

The implementation harness requires a strict contract between the orchestrator and the prompt. Before invoking the prompt, validate that the [RETRY_LOG] contains at least one entry per attempt with timestamps, error classifications, and modified arguments. After receiving the prompt's output, validate the JSON against a schema that enforces the decision enum (abort, human_review, fallback, degraded_continue), a non-empty rationale string, and an impact_assessment object with data_loss_risk and downstream_effects fields. If validation fails, log the raw output and default to human_review as a safe fallback. For high-risk domains, always require a human-in-the-loop approval step before executing a degraded_continue or fallback decision. Log every escalation event with the full prompt input, output, and validation result to create an audit trail for post-incident review.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, because the cost of a misclassified escalation (e.g., aborting a recoverable task or continuing with corrupted data) far exceeds the inference cost. Set temperature to 0 to minimize variance in critical decisions. The prompt should be cached as a static system instruction, with only the dynamic variables injected per invocation. Monitor for two failure modes in production: premature escalation, where the prompt recommends human_review or abort for transient errors that a simple retry would resolve, and infinite retry loops, where the orchestrator fails to detect that the retry budget is truly exhausted and never invokes this prompt. Implement a hard deadline check in the orchestrator that forces escalation if wall-clock time exceeds the task SLA, regardless of the retry counter state.