De-escalation Refusal Prompt for Agitated User Inputs

This prompt is designed for customer support and community moderation systems that must refuse a user request while the user is visibly frustrated, angry, or escalating. The goal is to de-escalate emotional tension, maintain a firm policy boundary, and preserve the user relationship. Use this when sentiment analysis or keyword detection flags a high-arousal negative state in the current or previous turn. The prompt assumes you have access to the conversation history, the specific policy being invoked, and a set of permissible alternative paths. Without these inputs, the model cannot calibrate its tone to the user's emotional trajectory or offer grounded alternatives, which risks producing a generic refusal that may further inflame the situation.

Do not use this prompt for routine refusals where the user is calm; a standard empathetic or firm refusal template is more appropriate and less likely to over-index on emotion that is not present. Overusing de-escalation language on a neutral user can come across as patronizing or evasive, damaging trust. Before routing to this prompt, your application should evaluate a sentiment trajectory across at least two turns. A single-turn spike in negative sentiment may be a false positive from sarcasm, poor translation, or all-caps emphasis on a non-emotional topic. Implement a gating check: if the user's sentiment score crosses a configurable threshold (e.g., below -0.6 on a -1 to 1 scale) and the previous turn was also negative or trending downward, route to this prompt. Otherwise, fall back to your standard refusal path.

This prompt is also inappropriate for high-severity safety violations such as threats of violence, child safety content, or self-harm. In those cases, de-escalation language can be misinterpreted as negotiation or leniency. Route those inputs to a dedicated crisis or safety escalation workflow with human review, not to a tone-modulated refusal. After deploying this prompt, monitor two key metrics: escalation rate (does the user escalate further or accept the refusal?) and sentiment recovery (does sentiment improve in the turn following the refusal?). If escalation rates remain high, the prompt's de-escalation language may be too weak or the alternative paths too narrow. If sentiment recovery is strong but policy boundary clarity drops, the prompt may be prioritizing agreeableness over firmness. Adjust the [CONSTRAINTS] block to tune this trade-off.

This template is designed to be placed into your system prompt or as a turn-level instruction block. It instructs the model to detect frustration signals, acknowledge the user's emotional state, and deliver a refusal that de-escalates tension without compromising on safety or policy boundaries. The template uses square-bracket placeholders that you must replace with your specific policies, tone guidelines, and escalation rules before deployment.

textCopy
You are an AI assistant operating in a customer support environment. Your primary directive is to be helpful while strictly adhering to the safety policies defined below.

When a user's input contains signals of frustration, anger, or agitation—such as all-caps text, accusatory language, or repeated demands—you must follow this de-escalation protocol before addressing the content of their request:

1.  **Detect and Acknowledge:** Identify the emotional signal and acknowledge it without judgment. Use phrases like "I can see this is frustrating" or "I understand this is important to you."
2.  **Evaluate Against Policy:** Determine if the user's core request violates any of the following policies:
    [POLICY_LIST]
3.  **If the request is permissible:** Proceed to answer helpfully, incorporating the acknowledgment from step 1.
4.  **If the request must be refused:** Construct a refusal that follows this structure:
    - **Acknowledgment:** Restate your understanding of their frustration.
    - **Clear Boundary:** State clearly and firmly that you cannot fulfill the specific request, citing the relevant policy from [POLICY_LIST] without sounding robotic.
    - **De-escalation Statement:** Add a phrase aimed at reducing tension, such as "I want to help us move forward constructively" or "My goal is to find a solution that works within our guidelines."
    - **Permissible Alternative:** Offer a constructive, policy-compliant alternative or redirection from this list: [SAFE_ALTERNATIVES_LIST]. If no alternative exists, state clearly that you've exhausted available options.
    - **Re-engagement Offer:** End with an open-ended offer to help with something else, e.g., "Is there another issue I can help you with today?"

**Tone Guidelines:**
Maintain a tone that is [TONE_DESCRIPTOR, e.g., "calm, professional, and empathetic"]. Never mirror the user's anger, sarcasm, or accusatory language. Do not use phrases that could be perceived as dismissive, such as "Calm down" or "You need to understand."

**Input to process:**
[USER_INPUT]

**Conversation history for context:**
[CONVERSATION_HISTORY]

To adapt this template, start by replacing [POLICY_LIST] with a concise, bulleted list of your actual content and safety policies. Replace [SAFE_ALTERNATIVES_LIST] with specific, actionable alternatives your product can offer. The [TONE_DESCRIPTOR] should be a single, clear phrase that aligns with your brand's voice for high-stakes interactions. Finally, wire up your application to inject the current [USER_INPUT] and [CONVERSATION_HISTORY] into the prompt. Before deploying, run this prompt against a golden dataset of agitated inputs to ensure the model correctly identifies frustration signals and that the refusal structure holds firm without escalating the user. For high-risk domains like finance or healthcare, always route outputs through a human review queue before they reach the end user.

This prompt is designed to sit behind a detection gate, not as a standalone classifier. Before invoking the de-escalation refusal template, your application must first detect agitation signals in the user input—sentiment trajectory, keyword patterns, punctuation spikes, or rapid retry behavior—and then route the request to this prompt only when both a policy violation and agitation are present. The prompt itself performs two jobs in one call: it classifies the agitation level and generates a refusal response calibrated to that level. Do not use this prompt for routine refusals where the user is calm; a standard firm or educational refusal is cheaper, faster, and less likely to over-accommodate.

Integration pattern: Wrap the prompt in a function that accepts [USER_INPUT], [POLICY_VIOLATION_TYPE], [CONVERSATION_HISTORY] (last 3-5 turns), and [SENTIMENT_TRAJECTORY] (a pre-computed string like escalating, stable-high, or de-escalating). The model returns a structured JSON object with agitation_level (enum: none, mild, moderate, severe), de_escalation_strategy (enum: acknowledge, validate_and_redirect, firm_boundary, offer_human_escalation), and response_text. Your application layer must validate this JSON against a schema before surfacing the response_text to the user. If agitation_level is severe or de_escalation_strategy is offer_human_escalation, bypass the generated text entirely and route to a live agent queue with the full context attached.

Validation and safety checks: After parsing the model output, run three checks before the response reaches the user. First, verify that response_text does not contain the policy-violating content the user originally requested—a common failure mode where the model echoes the disallowed request in its refusal. Second, confirm that the response does not promise human review unless your system actually routes to one; false escalation promises are a trust-destroying failure. Third, check that the tone matches the detected agitation level: a severe agitation input should never receive a casual or dismissive refusal. Log all three check results alongside the agitation_level and de_escalation_strategy for offline evaluation.

Model choice and latency: This prompt benefits from models with strong instruction-following and emotional tone control. In production, you can use a fast classifier model (e.g., a fine-tuned small model or a single-call LLM classification) for agitation detection, then route only the subset of refused-and-agitated turns to a larger model for response generation. This keeps p95 latency low for the common case. If you are using the same model for both detection and generation, set temperature to 0.2 or lower to keep refusal language consistent across similar inputs. Avoid high-temperature sampling here—creative refusal language introduces ambiguity that agitated users will probe.

Multi-turn state and trajectory tracking: The [SENTIMENT_TRAJECTORY] field is critical and must be computed by your application, not by the model. Track a rolling window of user sentiment scores (using a separate sentiment classifier or the model's own previous outputs) and compute whether the user's agitation is increasing, stable, or decreasing across turns. Feed this trajectory into the prompt so the de-escalation strategy adapts: an escalating user needs validation and a clear path forward, while a de-escalating user may only need a brief acknowledgment. Store the trajectory in the session state and include it in any human handoff payload.

What to avoid: Do not use this prompt as your only refusal mechanism. It is specifically tuned for agitated users and will produce overly accommodating language for calm policy violations, which can blur policy boundaries. Do not skip the post-generation validation step—agitated users are precisely the ones most likely to probe refusal language for loopholes. And do not deploy this prompt without a human escalation path tested and ready; offering human review in the response text when no agent is available will escalate the situation further when the user discovers the broken promise.