Retry Budget for Human Approval Handoff Prompt

This prompt is designed for product teams building human-in-the-loop (HITL) workflows where an AI system attempts autonomous repair before handing off to a human reviewer. The primary job-to-be-done is to enforce a strict retry budget, limiting the number of autonomous repair attempts to prevent infinite loops that waste compute, increase latency, and delay resolution. The ideal user is an AI engineer or platform architect integrating an LLM into a production system where the cost of a wrong autonomous decision is high, such as in customer support ticket resolution, code deployment, or clinical documentation review. Required context includes the original task, the repair history, and a clear definition of what constitutes a failed attempt.

You should use this prompt when you need an auditable trail of AI repair attempts and a clean handoff to a human reviewer. For example, if an agent fails to generate a valid JSON output after three repair attempts, this prompt will package the malformed outputs, the validator errors, and the original instruction into a single payload for a support engineer. Do not use this prompt for low-risk, fully autonomous workflows where a fallback default response is acceptable, or for systems where latency is so critical that a human review step is impossible. A key implementation detail is to track the retry count in your application state, not in the prompt's conversational context, to prevent tampering or accidental reset. The prompt itself acts as a stateless handoff generator, receiving the current state and producing the escalation payload.

Before implementing this prompt, define your escalation target: a review queue, a Slack channel, or a ticket system. Ensure your application harness can inject the [RETRY_HISTORY] and [CURRENT_STATE] accurately. The next step is to pair this prompt with an evaluation suite that checks for handoff payload completeness, ensuring no critical context is dropped before a human sees it.

This prompt template acts as a guardrail inside your AI harness. It instructs the model to track repair attempts against a defined budget, stop retrying when the budget is consumed, and produce a structured handoff payload for a human reviewer. The template is designed to be injected as a system message or appended to the user message when a validator detects a failure that requires correction. It assumes the harness already classifies the error, counts attempts, and provides the current retry state as input variables.

textCopy
You are a recovery agent operating under a strict retry budget. Your task is to correct a failed output, but you must not exceed the allowed number of repair attempts.

## RETRY BUDGET
- Maximum repair attempts allowed: [MAX_RETRIES]
- Current attempt number: [ATTEMPT_NUMBER]
- Remaining attempts: [REMAINING_ATTEMPTS]
- Retry budget exhausted: [BUDGET_EXHAUSTED] (true/false)

## ORIGINAL TASK
[ORIGINAL_TASK_DESCRIPTION]

## FAILED OUTPUT
[FAILED_OUTPUT]

## FAILURE REASON
[ERROR_CLASSIFICATION] : [ERROR_DETAIL]

## CORRECTION HISTORY
[PREVIOUS_ATTEMPTS_SUMMARY]

## INSTRUCTIONS
1. If [BUDGET_EXHAUSTED] is false, analyze the failure reason and produce a corrected output that addresses the specific error while preserving the original intent. Output your correction in the format specified by [OUTPUT_SCHEMA].
2. If [BUDGET_EXHAUSTED] is true, do NOT attempt another correction. Instead, produce a HUMAN HANDOFF PAYLOAD using the exact structure below. The payload must contain all context a human reviewer needs to understand the failure and complete the task.

## HUMAN HANDOFF PAYLOAD SCHEMA (use only when budget is exhausted)
{
  "handoff_type": "RETRY_BUDGET_EXHAUSTED",
  "original_task": "[ORIGINAL_TASK_DESCRIPTION]",
  "failure_summary": "A concise explanation of what failed and why, synthesizing the correction history.",
  "last_error": "[ERROR_CLASSIFICATION]: [ERROR_DETAIL]",
  "attempts_made": [ATTEMPT_NUMBER],
  "correction_history": [
    {
      "attempt": 1,
      "error_encountered": "...",
      "correction_applied": "..."
    }
  ],
  "last_failed_output": "[FAILED_OUTPUT]",
  "recommended_human_action": "A specific, actionable suggestion for the reviewer based on the failure pattern.",
  "urgency": "[RISK_LEVEL]"
}

## CONSTRAINTS
- Do not invent facts or data not present in the original task or failure context.
- If the failure reason indicates a safety policy violation, do not attempt to bypass it; escalate immediately regardless of remaining budget.
- Preserve all successful partial results from previous attempts when escalating.

To adapt this template, replace each square-bracket placeholder with values from your harness. The [ERROR_CLASSIFICATION] should come from your validator's error taxonomy (e.g., SCHEMA_VIOLATION, HALLUCINATION_DETECTED, TOOL_CALL_INVALID). The [PREVIOUS_ATTEMPTS_SUMMARY] should be a concise log of what was tried and what failed, built by your harness across retry cycles. Wire the [BUDGET_EXHAUSTED] flag to a simple counter comparison in your application code—do not rely on the model to decide if the budget is spent. For high-risk domains, ensure the handoff payload is logged, routed to a review queue, and never silently discarded. Test this prompt with both budget-available and budget-exhausted states to confirm the model switches behavior cleanly at the boundary.

The Retry Budget for Human Approval Handoff prompt operates inside a retry loop managed by your application harness, not by the model itself. The harness tracks the number of repair attempts, the cumulative cost or latency consumed, and the error types encountered. When the retry budget is exhausted, the harness invokes this prompt to produce a structured handoff payload for a human reviewer. The prompt's job is to package the failure context—original request, retry history, attempted corrections, and the specific reason for escalation—into a format that a review queue or ticketing system can ingest without requiring the reviewer to reconstruct what happened.

Wire the prompt into your harness by maintaining a retry state object that includes: attempt_count, max_attempts, error_history (list of error messages and timestamps), original_input, last_output, and budget_type (e.g., count, token, cost, time). When attempt_count >= max_attempts or the budget is otherwise exhausted, call the prompt with these fields mapped into the [RETRY_STATE] placeholder. The prompt should return a JSON payload conforming to [OUTPUT_SCHEMA], which your harness then validates before routing. Validation checks must confirm: (1) the output is valid JSON matching the schema, (2) the escalation_reason field is non-empty and references specific errors from the retry history, (3) the recommended_action field contains a concrete next step, not a generic placeholder, and (4) the context_package includes all required fields for the downstream reviewer. If validation fails, log the failure and fall back to a pre-defined escalation template rather than retrying the handoff prompt itself—you should never retry the escalation prompt, as that defeats the purpose of the budget.

For model choice, use a model with strong instruction-following and structured output capabilities. The prompt is a packaging task, not a reasoning-heavy one, so a smaller, faster model often suffices. If your review queue expects a specific format (e.g., Jira ticket fields, Slack message blocks, PagerDuty incident payload), include that schema in [OUTPUT_SCHEMA] and add a [TARGET_SYSTEM] field to the prompt so the model can adapt field names and structure accordingly. Logging is critical: record every handoff invocation with the full retry state, the generated payload, and the validation result. This audit trail lets you tune retry budgets later—if you see many escalations where the reviewer immediately approves the original output, your budget may be too tight. If reviewers consistently find the context package incomplete, the prompt needs improvement. Human review routing should use the urgency and error_category fields from the output to direct the payload to the right team or queue, avoiding a single catch-all escalation bucket that slows response times.