Escalation vs Refusal Decision Prompt for Support Agents

This prompt is designed for the decision layer of a customer support AI system, sitting between intent classification and response generation. Its job is to force a binary, auditable choice when a user request cannot be fulfilled automatically: refuse the request with a policy-grounded explanation, or escalate to a human agent with a packaged handoff context. The ideal user is an AI engineer or product developer integrating a support copilot where misrouting causes either safety gaps (a harmful request is answered) or queue overload (every difficult request is dumped on humans). You need this prompt when your system's authority is bounded by capability limits, safety policies, or regulatory constraints, and you cannot rely on a generic 'I can't help with that' response to handle every edge case.

Use this prompt when the cost of a wrong decision is high. For example, a healthcare support AI receiving a message like 'Is this chest pain normal after taking my medication?' must not attempt a clinical answer, but a blunt refusal without escalation could delay care. The prompt forces the model to weigh the request against a defined policy, classify the risk, and produce a structured verdict. It is not a post-hoc filter to catch bad outputs after they are generated; it is a pre-response gate. You should wire it into your application flow so that no response reaches the user without passing through this decision when a boundary condition is triggered. The output includes a machine-readable decision field (refuse or escalate), a human-readable rationale, and, for escalations, a handoff_package containing a summary, urgency level, and relevant context for the human agent.

Do not use this prompt for routine, low-risk requests that your system can handle autonomously. If you apply it to every user turn, you will create unnecessary latency and review queue noise. It is also not a replacement for a safety classifier that detects policy violations in raw user input; it assumes that a boundary has already been identified, and its job is to decide the routing outcome. Avoid deploying this prompt without a feedback loop: escalations that are consistently rejected by human reviewers indicate that your policy definitions or risk thresholds need recalibration. The next step after implementing this prompt is to build eval suites that measure false-positive escalation rates and refusal correctness against a golden dataset of boundary cases.

This prompt template is designed to be copied directly into your application's prompt management system or codebase. It instructs the model to analyze a customer support request against your defined policies and output a structured decision: refuse the request with a safe alternative, escalate it to a human agent with packaged context, or handle it autonomously. The square-bracket placeholders must be replaced with your specific inputs before every call. Do not send the raw template to the model.

textCopy
You are a support triage assistant for [COMPANY_NAME]. Your job is to decide whether a customer request should be refused, escalated to a human agent, or handled autonomously.

## POLICIES
[POLICY_DOCUMENT]

## ESCALATION CRITERIA
[ESCALATION_CRITERIA]

## REFUSAL CRITERIA
[REFUSAL_CRITERIA]

## CURRENT CONVERSATION
[CONVERSATION_HISTORY]

## LATEST USER MESSAGE
[USER_MESSAGE]

## USER CONTEXT
Account Tier: [ACCOUNT_TIER]
Previous Escalations: [PREVIOUS_ESCALATIONS]
Session Risk Score: [SESSION_RISK_SCORE]

## OUTPUT_SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "decision": "refuse" | "escalate" | "autonomous",
  "confidence": 0.0-1.0,
  "rationale": "string explaining the decision",
  "policy_reference": "string citing the specific policy clause",
  "refusal_message": "string with the user-facing refusal text (only if decision is refuse)",
  "safe_alternative": "string with a constructive alternative (only if decision is refuse)",
  "escalation_priority": "low" | "medium" | "high" | "critical" (only if decision is escalate),
  "handoff_context": {
    "summary": "string summarizing the issue for the human agent",
    "key_facts": ["fact1", "fact2"],
    "attempted_resolutions": ["step1", "step2"],
    "risk_factors": ["risk1"]
  } (only if decision is escalate),
  "autonomous_response": "string with the response to send (only if decision is autonomous)"
}

## CONSTRAINTS
- If the request violates [REFUSAL_CRITERIA], you MUST refuse. Do not escalate refused requests unless the refusal itself is being challenged and the challenge meets escalation criteria.
- If the request meets [ESCALATION_CRITERIA], you MUST escalate. Package all relevant context for the human agent.
- If the request is routine and within policy, respond autonomously.
- Never fabricate policy. If a situation is not covered, escalate with low confidence.
- For regulated domains ([REGULATED_DOMAINS]), always escalate unless the request is purely informational and clearly labeled as not professional advice.
- If the user shows frustration signals across multiple turns, escalate regardless of other criteria.

Before integrating this prompt, replace every square-bracket placeholder with concrete values from your application context. The [POLICY_DOCUMENT] should contain your full support policy text, not a summary. The [ESCALATION_CRITERIA] and [REFUSAL_CRITERIA] should be explicit, machine-readable lists of conditions. For high-risk deployments, add a post-processing validation step that checks the output JSON against the schema before any action is taken. If the model returns invalid JSON or a decision that contradicts your hard policy rules, log the failure and default to escalation with a human agent.

This prompt is designed to sit at a critical decision point in a customer support AI pipeline: after the system has determined that a user request cannot be fulfilled autonomously, but before any response is sent to the user. The harness must invoke this prompt when the primary support agent's output is blocked by a safety policy, a capability boundary, or a regulated-domain restriction. The prompt's job is not to generate a user-facing message, but to produce a structured decision object that downstream routing logic can act on. The harness should treat this as a synchronous classification step with a strict latency budget—typically under 500ms—to avoid degrading the support experience.

Wire the prompt into your application by placing it behind a decision gateway that triggers on any refusal or policy-block event from the primary agent. The gateway should assemble the required inputs: the full conversation history up to the blocked turn, the specific policy or capability constraint that triggered the block, the user's account tier and authentication state, the current session's risk score, and the available human agent queues with their current load and expertise tags. Pass these into the prompt's [CONVERSATION_HISTORY], [BLOCK_REASON], [USER_CONTEXT], [SESSION_RISK_SCORE], and [AVAILABLE_QUEUES] placeholders. The model must return a JSON object with decision (enum: ESCALATE, REFUSE, REDIRECT), rationale, target_queue (if escalated), refusal_tone (if refused), and confidence (0.0–1.0). Validate this output against a strict JSON schema before acting on it. If validation fails, retry once with the validation error injected into the prompt's [PREVIOUS_ERROR] field. If the retry also fails, default to escalating to the general review queue and log the failure for investigation.

Log every decision this prompt makes, including the full input context, the raw model output, the validated decision, and the eventual routing action taken. This audit trail is essential for calibrating escalation thresholds, identifying over-refusal patterns, and demonstrating compliance in regulated domains. Implement a human feedback loop: when a human agent reviews an escalated case, capture their assessment of whether the escalation was appropriate and whether the refusal would have been acceptable. Feed this feedback into a periodic evaluation run using your LLM judge rubric to measure precision and recall of escalation decisions. Set up monitoring alerts for sudden spikes in escalation volume, drops in decision confidence below your configured threshold (default 0.7), and increases in schema validation failures. These signals often indicate model drift, policy changes that need prompt updates, or adversarial probing attempts.

For model selection, use a fast, instruction-tuned model capable of structured JSON output—Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Flash are good starting points. Avoid using the same model instance that generated the original blocked response, as this creates a conflict of interest in the decision. If your system uses tool-calling or RAG, ensure that the escalation prompt does not have access to tools that could modify user data or send messages; its only output should be the decision JSON. When the decision is ESCALATE, the harness should immediately package the conversation context, the decision rationale, and any relevant policy references into a handoff payload and route it to the specified queue via your agent routing API. When the decision is REFUSE, pass the refusal_tone and rationale to a separate refusal-generation prompt that crafts the user-facing message—do not send the raw decision JSON to the user. When the decision is REDIRECT, route to a safe-alternative generation workflow that offers the user a policy-compliant path forward. Never allow the system to proceed with the original blocked action, even if confidence is low; the default posture must be safety-preserving.