Escalation Path Activation Prompt for Unresolved Requests

This prompt is for product and reliability engineers who need a conversational agent to stop retrying a failed task and activate a predefined escalation path. The job-to-be-done is a clean, auditable handoff: the model must recognize that its current role, tools, or context are insufficient to resolve a user request, produce a structured escalation decision with a reason code, and generate a user-facing transition message that preserves trust. The ideal user is an engineering lead or AI architect integrating this prompt into a customer-support bot, an internal ops agent, or any multi-step assistant where silent failure or infinite retry loops are unacceptable.

Use this prompt when the agent has exhausted its retry budget, encountered a permission boundary, detected a capability gap, or identified user frustration signals that require human intervention or a more capable role. It is designed to be wired into a state machine or orchestration layer that tracks retry counts, tool failure codes, and conversation sentiment. The prompt requires several inputs to function correctly: the original user request, a summary of attempted resolutions, the active retry count, the maximum retry budget, a list of available escalation paths with their capabilities, and the agent's current role constraints. Without these inputs, the model cannot make a reliable escalation decision and may hallucinate unavailable paths or escalate prematurely.

Do not use this prompt as a generic error handler for every model failure. It is specifically for unresolved requests that require a transition to a different actor or system. For transient failures like a single malformed tool call or a recoverable parsing error, use a retry recovery prompt instead. Avoid deploying this prompt in systems where the escalation target is undefined or where the user experience cannot gracefully handle a handoff message. The next step after reading this section is to gather the required input variables and review the prompt template to understand the exact output contract you will need to parse and act on in your application harness.

The following prompt template is designed to be inserted into the system instructions of a conversational agent or a dedicated escalation guard agent. It forces a structured decision when the primary resolution path has been exhausted. The template uses square-bracket placeholders for all dynamic inputs, constraints, and output schemas, making it ready for template engines or programmatic assembly in your application layer. Do not use this prompt for initial triage; it is strictly for the moment after retries have failed.

codeCopy
SYSTEM: You are an escalation decision engine. Your only job is to evaluate an unresolved user request against the available escalation paths and produce a structured decision. You do not apologize, re-explain, or attempt further resolution. You only decide and output the escalation payload.

[ESCALATION_PATHS]
Available paths:
- [PATH_ID_1]: [PATH_DESCRIPTION_1] (Eligibility: [ELIGIBILITY_CRITERIA_1])
- [PATH_ID_2]: [PATH_DESCRIPTION_2] (Eligibility: [ELIGIBILITY_CRITERIA_2])
- [PATH_ID_N]: [PATH_DESCRIPTION_N] (Eligibility: [ELIGIBILITY_CRITERIA_N])

[RETRY_CONTEXT]
Attempts made: [RETRY_COUNT]
Last error or blocker: [LAST_FAILURE_REASON]

[CONVERSATION_SUMMARY]
User's original request: [USER_REQUEST]
Key constraints mentioned by user: [USER_CONSTRAINTS]
User sentiment signals: [SENTIMENT_SIGNALS]

[OUTPUT_SCHEMA]
You must output a single JSON object with no other text:
{
  "escalation_decision": "ESCALATE" | "DO_NOT_ESCALATE",
  "reason_code": "[REASON_CODE_1]" | "[REASON_CODE_2]" | "[REASON_CODE_N]",
  "selected_path": "[PATH_ID]" | null,
  "rationale": "Concise explanation of why this path was selected, referencing the eligibility criteria and retry context.",
  "user_transition_message": "Exact text to send to the user before handoff. Must be empathetic, honest about the handoff, and set expectations for next steps.",
  "handoff_payload": {
    "priority": "[PRIORITY_LEVEL]",
    "summary": "Structured summary for the human or downstream system receiving the escalation.",
    "required_context": ["list of critical context fields"]
  }
}

[CONSTRAINTS]
- If no path matches the eligibility criteria, set escalation_decision to "DO_NOT_ESCALATE" and selected_path to null. In this case, the user_transition_message must direct the user to a general help channel.
- Do not invent new escalation paths.
- The user_transition_message must never promise a specific resolution time unless that time is defined in the selected path's description.
- If sentiment_signals indicate frustration or urgency, the handoff_payload priority must be "HIGH".

To adapt this template, replace each square-bracket placeholder with values from your escalation policy configuration. The [ESCALATION_PATHS] block should be populated from a source of truth like a configuration file or a database, not hardcoded. The [RETRY_CONTEXT] and [CONVERSATION_SUMMARY] fields must be injected by your application harness after the retry loop exits. The [OUTPUT_SCHEMA] is designed to be parsed by a downstream router that can read selected_path and handoff_payload to trigger the correct workflow, whether that is creating a ticket, paging an on-call, or queuing a human review. If you are operating in a regulated environment, ensure the rationale and handoff_payload fields are persisted to an audit log before any automated routing occurs.

The Escalation Path Activation Prompt is not a standalone artifact; it is a decision node inside a larger orchestration loop. The application should invoke this prompt only after a primary resolution attempt has failed or a retry budget has been exhausted. The prompt expects structured context about the unresolved request, including the conversation history, the resolution attempts made, the active retry count, and the available escalation paths. The output is a machine-readable escalation decision that the application must parse, validate, and act on—either by routing to a human queue, activating a fallback role, or logging a dead-end for later review.

Wire the prompt into your application as a gated step. Before calling the model, assert that retry_count >= max_retries or that a terminal failure reason (e.g., tool error, permission denied, confidence below threshold) has been set. Pass the prompt a structured input object containing conversation_summary, failed_attempts (an array of action/result pairs), available_escalation_paths (with IDs and descriptions), and user_sentiment if available. On the output side, enforce a strict JSON schema with fields: escalation_triggered (boolean), reason_code (enum of predefined failure categories), selected_path_id, user_facing_message, and audit_context. Use a validator like jsonschema or Pydantic to reject malformed responses and trigger a single retry with the validation error injected into the next prompt. If the retry also fails, fall back to a hardcoded safe escalation path and log the failure as a critical incident.

Logging and observability are non-negotiable. Emit a structured log event for every escalation decision, including the prompt version, model used, input context hash, output decision, and latency. This trace should feed into your existing monitoring stack so that premature escalation rates and failure-to-escalate rates can be tracked over time. For high-risk domains—healthcare, finance, legal—route every escalation decision through a human approval step before the user-facing message is sent. The audit_context field in the output should contain a concise, evidence-backed rationale that a human reviewer can quickly validate. Do not treat this prompt as a fire-and-forget decision engine; it is a recommendation that must be verified against your operational policies before execution.