Infinite Loop Detection and Retry Storm Prevention Prompt

This prompt is a guardrail for reliability engineers and AI platform architects who need to protect production systems from runaway retry logic. Its job is to detect when an AI agent, tool-calling pipeline, or output-repair loop is stuck in a non-productive cycle—repeated identical failures, identical error messages, or outputs that do not improve across attempts—and force an escalation instead of allowing another retry. The ideal user is someone operating an AI harness where retries are automated and the cost of an infinite loop is measured in compute waste, latency degradation, and degraded user experience.

Use this prompt when you have a retry loop that already includes error context and prior outputs, and you need a decision layer that says 'stop retrying, escalate' before the budget is exhausted. It is not a replacement for a retry budget counter or a dead-letter queue; it is the reasoning step that interprets the pattern of failures. Do not use this prompt for single-attempt validation, for simple HTTP 429 backoff, or in workflows where every retry is guaranteed to be independent and non-overlapping. The prompt requires at minimum: the original task description, the sequence of prior attempts with their outputs and error messages, and the escalation path definition.

Before wiring this into production, define clear evaluation criteria for loop detection sensitivity. A prompt that is too aggressive will escalate recoverable transient errors; one that is too lenient will allow storms to continue. Test against a golden dataset of retry sequences that includes genuine loops, slow-but-improving sequences, and single unrelated failures. The next step after reading this section is to copy the prompt template, adapt the escalation target to your infrastructure, and run it against your retry harness with logging enabled for every escalation decision.

This prompt template acts as a circuit-breaker for your retry loop. It is designed to be called before the next retry attempt, receiving the history of previous attempts, their outputs, and their error signatures. Its job is not to fix the problem but to decide whether another retry is safe and likely to be useful. Use it when you have a retry budget defined and need a reliable mechanism to enforce it without relying solely on simple counters, which can be fooled by non-identical but semantically equivalent failures.

textCopy
SYSTEM: You are a production reliability guard for an AI system. Your sole task is to analyze a sequence of retry attempts and determine if a retry storm or infinite loop is occurring. You must prevent wasted compute, latency, and cost.

INPUT:
- [RETRY_HISTORY]: A JSON array of previous attempts, each containing:
  - attempt_number: integer
  - error_type: string (e.g., 'tool_call_invalid', 'output_schema_mismatch', 'api_error', 'empty_response')
  - error_message: string
  - output_summary: string (a 100-word summary of the model's output for that attempt)
  - retry_instruction_used: string (the instruction given to the model for that specific retry)
- [RETRY_BUDGET_REMAINING]: integer (number of retries left in the current budget)
- [CURRENT_RETRY_INSTRUCTION]: string (the instruction proposed for the next retry)
- [CONSTRAINTS]:
  - MAX_IDENTICAL_ERRORS: integer (threshold for identical error messages)
  - MAX_SEMANTIC_SIMILARITY_THRESHOLD: float (0.0-1.0) for output summary similarity
  - MAX_NON_IMPROVING_ATTEMPTS: integer

TASK:
1. Analyze the [RETRY_HISTORY] for the following loop conditions:
   a. **Identical Error Loop**: The exact same [error_message] has occurred [MAX_IDENTICAL_ERRORS] or more times.
   b. **Semantic Stagnation Loop**: The cosine similarity of the embeddings of the last [MAX_NON_IMPROVING_ATTEMPTS] [output_summary] fields is above [MAX_SEMANTIC_SIMILARITY_THRESHOLD], indicating no meaningful change in output.
   c. **Instruction Exhaustion**: The [CURRENT_RETRY_INSTRUCTION] is semantically equivalent to a [retry_instruction_used] that already failed in the history.
2. If any loop condition is met, you MUST recommend immediate escalation. Do not suggest further retries.
3. If no loop condition is met, you may approve the retry.

OUTPUT_SCHEMA:
{
  "decision": "retry" | "escalate",
  "loop_detected": boolean,
  "loop_type": ["identical_error" | "semantic_stagnation" | "instruction_exhaustion"] | null,
  "evidence": {
    "matching_attempt_numbers": [integer],
    "similarity_score": float | null,
    "exhausted_instruction": string | null
  },
  "escalation_reason": string (required if decision is 'escalate', else null),
  "approved_retry_instruction": string (required if decision is 'retry', else null)
}

CONSTRAINTS:
- Do not hallucinate attempt data. Only reference attempts provided in [RETRY_HISTORY].
- If [RETRY_BUDGET_REMAINING] is 0, you must escalate regardless of loop detection.
- Be conservative. Escalate if you are unsure.

To adapt this template, integrate it directly into your retry harness. After a model call fails validation, append the failure record to a retry_history list. Before dispatching the next retry, call this guard prompt with the history, remaining budget, and proposed next instruction. The guard's decision field becomes a hard gate: if escalate, break the loop and route the escalation_reason and full history to your human review queue or dead-letter handler. The MAX_SEMANTIC_SIMILARITY_THRESHOLD is a powerful control knob; start with a value like 0.92 and tune it based on your tolerance for near-duplicate outputs. For high-risk domains, always log the guard's full JSON output for auditability and post-incident review.

This prompt is not a standalone safety net—it is a guard component that must be wired into an existing retry loop. The harness should invoke this prompt after every retry attempt, passing the current attempt's output, error message, and the history of previous attempts. The prompt's job is to classify whether the system is in a non-progressing loop and, if so, to signal immediate escalation. The harness must treat the prompt's structured output as a control signal, not a suggestion. If the prompt returns loop_detected: true, the harness must break the retry loop, log the full failure context, and route to the escalation path defined in your retry budget policy.

State Tracking Requirements: The harness must maintain a retry history array containing, at minimum, the model's raw output, any error or validation messages, and a hash or embedding of the output for each attempt. Before calling this prompt, compute a similarity score between the current output and the previous output using a fast string-similarity metric (e.g., normalized Levenshtein distance, cosine similarity on embeddings). Pass this score as [SIMILARITY_SCORE] in the prompt. The harness should also track the count of consecutive attempts where the error message is identical. This pre-computation offloads simple pattern matching from the LLM, reducing token cost and latency while improving detection reliability. Validation: After the prompt returns, validate the JSON output against a strict schema that requires loop_detected (boolean), loop_type (enum: identical_output, identical_error, non_improving, oscillating, none), confidence (float 0-1), and escalation_reason (string, required if loop_detected is true). Reject and retry the detection prompt itself once if the schema is invalid; if it fails again, escalate as a harness-level failure.

Model Choice and Latency: This detection prompt should run on a fast, cheap model (e.g., a small Claude Haiku or GPT-4o-mini variant) because it is a meta-judgment call, not a content-generation task. Do not use the same model instance that is generating the primary output, as this creates a single point of failure. Logging and Observability: Log every detection prompt invocation with the retry attempt number, the similarity score, the prompt's raw output, and the final loop_detected decision. Emit a metric for retry_loop_detected_total with labels for loop_type and escalated. This data is critical for tuning the similarity threshold and identifying which failure modes most frequently cause loops. Avoiding False Positives: The most common failure mode is triggering escalation when the model is making genuine incremental progress (e.g., fixing one field at a time in a structured output repair loop). To mitigate this, set a minimum retry count (e.g., 3 attempts) before invoking the detection prompt, and require the similarity score to exceed a threshold (e.g., >0.85) for at least two consecutive attempts. Tune these thresholds against your golden dataset of known loop and non-loop retry sequences.