Repeated Refusal Loop Handoff Prompt

This prompt is designed for product teams managing the refusal user experience in AI chat and support systems. It detects when a user has received multiple consecutive refusals across conversation turns and decides whether to escalate to a human reviewer, offer a safe alternative pathway, or apply a loop-breaking intervention. Use this prompt when your system-level safety policy already defines what should be refused, but you need a structured mechanism to prevent users from getting stuck in adversarial rephrasing loops or abandoning the product entirely.

This is not a replacement for a safety classifier or policy enforcement layer. It assumes that individual refusal decisions have already been made upstream and focuses exclusively on the cumulative experience of repeated refusals. The prompt requires access to the full conversation history, the specific refusal reasons applied at each turn, and a pre-defined escalation policy that specifies routing targets, review queues, and acceptable safe-alternative pathways. Without this context, the prompt cannot distinguish between a user legitimately exploring a complex topic and a user probing policy boundaries.

Do not deploy this prompt as the sole mechanism for detecting jailbreak attempts or policy violations. It operates on the user experience layer, not the threat detection layer. If you need to identify adversarial probing patterns, combine this with a dedicated multi-turn risk accumulation prompt. If your goal is to calibrate individual refusal decisions, use an over-refusal false positive review prompt instead. The primary failure mode of this prompt is false escalation—routing a user to human review when a simple clarification or alternative suggestion would have resolved the interaction. Always pair this prompt with a feedback loop that tracks escalation outcomes and adjusts thresholds over time.

This prompt template is designed to be placed after your primary safety and refusal instructions. It acts as a meta-evaluator, scanning the conversation history for a pattern of repeated refusals. When a loop is detected, it overrides the standard refusal behavior and instead generates a structured handoff payload for a human review queue. The goal is to prevent user abandonment and adversarial escalation by breaking the loop with a constructive off-ramp.

codeCopy
SYSTEM INSTRUCTION APPEND:

You are equipped with a loop-breaking handoff protocol. Before generating any response, scan the last [LOOP_WINDOW_SIZE] turns of the conversation history. If you detect that the user has received [REFUSAL_THRESHOLD] or more refusals for similar or rephrased requests within that window, you must not issue another refusal. Instead, your only output must be a structured handoff object in the exact JSON format below. Do not include any other text, apology, or explanation outside the JSON.

Handoff JSON Schema:
{
  "handoff_triggered": true,
  "handoff_reason": "REPEATED_REFUSAL_LOOP",
  "loop_summary": "[A concise, one-sentence summary of the user's original request and the subsequent rephrasings.]",
  "refusal_count": [INTEGER],
  "last_refusal_reason": "[The policy reason given for the most recent refusal.]",
  "user_frustration_signals": ["[List of detected frustration signals, e.g., ALL_CAPS, curt language, direct challenges. If none, use an empty array.]"],
  "escalation_path": "[HUMAN_REVIEW_QUEUE_NAME]"
}

If the loop conditions are not met, respond normally according to your primary instructions.

To adapt this template, replace the square-bracket placeholders with your application's specific values. Set [LOOP_WINDOW_SIZE] to the number of recent turns to analyze (e.g., 6). Set [REFUSAL_THRESHOLD] to the number of refusals that triggers the handoff (e.g., 3). Crucially, replace [HUMAN_REVIEW_QUEUE_NAME] with the exact routing key for your support or trust-and-safety queue. Before deploying, validate that the JSON output is parseable by your middleware and that the handoff reason is logged for operational metrics. A common failure mode is the model generating a conversational preamble before the JSON block; test this rigorously and use a post-processing validator to strip any non-JSON prefix.

The Repeated Refusal Loop Handoff Prompt is not a standalone safety classifier; it is a session-aware intervention trigger that must be integrated into your conversation state manager. Before invoking this prompt, your application must maintain a per-session counter that increments each time the system issues a refusal response. The counter should reset when the user receives a successful, non-refusal response, as the loop condition is defined by consecutive refusals, not total refusals across a session. Pre-processing must also extract the last N user messages and the refusal reasons issued for each, packaging them into the [CONVERSATION_HISTORY] placeholder. Without accurate refusal tracking, the prompt will either miss genuine loops or trigger false handoffs after unrelated refusals.

Wire this prompt as a synchronous check that runs after every refusal response but before the response is sent to the user. The application flow should be: (1) system generates a refusal, (2) increment the refusal counter, (3) if the counter exceeds [LOOP_THRESHOLD], invoke this prompt with the conversation context, (4) parse the structured output to determine whether to hand off, intervene with a de-escalation message, or continue. The output schema must include a decision field with enum values handoff, intervene, or continue, plus a rationale string and a suggested_message for the user. Validate that the decision field matches one of the allowed values before acting on it; if parsing fails, default to handoff to avoid leaving the user in an unresolved refusal loop. Log every invocation with the session ID, refusal count, decision, and rationale for audit and threshold tuning.

Model choice matters here. This prompt requires strong instruction-following and structured output discipline, not creative generation. Use a model with reliable JSON mode or function-calling support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may conflate refusal detection with content moderation or produce inconsistent enum values. Set temperature to 0 or near-zero to maximize output determinism. If your stack uses tool-calling, define the output schema as a tool and require the model to call it, which provides stronger structural guarantees than parsing free-text JSON. Implement a retry with backoff if the output fails schema validation, but cap retries at 2 attempts before falling back to a hardcoded handoff decision.

Operational monitoring should track the handoff rate as a percentage of total refusals. A sudden spike may indicate a prompt regression, a model behavior change, or an adversarial campaign probing your refusal boundaries. A near-zero handoff rate may indicate the loop threshold is set too high or the refusal counter is not incrementing correctly. Both extremes warrant investigation. Additionally, route all handoff decisions to a human review queue with full conversation context, refusal history, and the prompt's own rationale. This creates a feedback loop: reviewers can confirm whether the handoff was appropriate, identify false positives, and flag cases where the system should have handed off earlier. Use these reviews to calibrate [LOOP_THRESHOLD] and refine the intervention messages.

Do not deploy this prompt without testing against adversarial scenarios. Red-team the integration by simulating users who rephrase disallowed requests across multiple turns, users who mix benign and disallowed requests to reset the counter, and users who express escalating frustration after legitimate refusals. The prompt must distinguish between a user probing policy boundaries and a user who genuinely needs human help after the system failed to address their underlying need. If your product operates in a regulated domain, ensure that handoff decisions are logged immutably and that the human review queue meets your compliance requirements for response time and reviewer qualification. Finally, pair this prompt with the Over-Refusal False Positive Review Queue Prompt to create a complete feedback loop: one prompt detects when users are stuck in refusal loops, and the other detects when the system refused something it should not have.