Escalation Path Selection Prompt

This prompt is a gating function for workflow automation engineers who need a reliable, machine-readable decision inside an AI pipeline. Its job is to ingest structured failure telemetry—such as a confidence score, error type, retry count, and a predefined decision matrix—and output a single, unambiguous escalation path. The output includes both a machine-readable code for the orchestration layer (e.g., RETRY, CLARIFY, ESCALATE, ABORT) and a human-readable rationale for logs and review queues. Use this when the system must autonomously decide whether to loop back for another attempt, ask the user for more information, hand off to a human operator, or terminate the task entirely.

The ideal user has already codified their escalation policy into explicit thresholds and paths. The prompt requires a decision matrix as input, which maps combinations of failure types, confidence levels, and retry budget states to specific actions. For example, a PARSE_ERROR with high confidence and remaining retries might map to RETRY, while the same error with an exhausted budget maps to ESCALATE. Do not use this prompt for open-ended conversational escalation or for systems where the policy is still a set of vague guidelines. It is designed for production pipelines where the rules are known, the telemetry is structured, and the next step must be deterministic.

Before wiring this into your application, ensure you have instrumented your pipeline to capture the required input fields: failure_type, confidence_score, retry_count, max_retries, and the decision_matrix itself. The prompt's value is in enforcing consistency across hundreds of decision points. Avoid the temptation to use a generic chat model for this task without the structured matrix; without it, the model will improvise policy, leading to unpredictable handoffs and audit failures. The next section provides the copy-ready template and explains how to adapt the decision matrix to your specific operational policies.

This prompt template is designed to be the core decision engine in your escalation workflow. It takes structured inputs about the current failure state—including the type of error, the model's confidence, and the remaining retry budget—and outputs a clear, actionable escalation path. The paths are constrained to a predefined set of actions: RETRY, CLARIFY, HUMAN_REVIEW, or ABORT. The prompt's strength lies in its forced reasoning, requiring the model to justify its selection against a provided decision matrix before outputting the final structured result.

textCopy
You are an escalation decision engine for an AI system. Your task is to select the single most appropriate escalation path based on the provided failure context, confidence score, and retry budget state. You must reason step-by-step against the decision matrix before making your final selection.

# FAILURE CONTEXT
Failure Type: [FAILURE_TYPE]
Error Message: [ERROR_MESSAGE]
Original User Input: [ORIGINAL_INPUT]
Last Model Output (if any): [LAST_MODEL_OUTPUT]

# CONFIDENCE AND BUDGET STATE
Current Confidence Score (0.0-1.0): [CONFIDENCE_SCORE]
Retry Attempt Number: [RETRY_ATTEMPT]
Maximum Retry Budget: [MAX_RETRIES]

# DECISION MATRIX
Evaluate the following rules in order. The first rule that matches all conditions determines the path.
1. If Failure Type is 'TOOL_CALL_ERROR' and Retry Attempt < Max Retries: Path = RETRY
2. If Failure Type is 'VALIDATION_ERROR' and Retry Attempt < Max Retries: Path = RETRY
3. If Confidence Score < [LOW_CONFIDENCE_THRESHOLD] and Retry Attempt >= Max Retries: Path = HUMAN_REVIEW
4. If Failure Type is 'AMBIGUOUS_INPUT' and Retry Attempt < Max Retries: Path = CLARIFY
5. If Failure Type is 'POLICY_VIOLATION': Path = ABORT
6. If Retry Attempt >= Max Retries: Path = HUMAN_REVIEW
7. Default Path: RETRY

# OUTPUT INSTRUCTIONS
First, provide a brief step-by-step reasoning that applies the decision matrix to the provided context. Then, output a single JSON object with the following schema. Do not output any text outside the JSON object.

{
  "selected_path": "RETRY" | "CLARIFY" | "HUMAN_REVIEW" | "ABORT",
  "reasoning": "A concise explanation of the rule that was matched.",
  "retry_instruction": "A specific instruction for the next retry attempt, only if the path is RETRY. Otherwise, null.",
  "clarification_question": "A targeted question to resolve ambiguity, only if the path is CLARIFY. Otherwise, null.",
  "handoff_context": "A summary of the failure for a human reviewer, only if the path is HUMAN_REVIEW. Otherwise, null."
}

To adapt this template for your production system, you must replace the square-bracket placeholders with runtime values from your application state. The [LOW_CONFIDENCE_THRESHOLD] should be a constant defined in your configuration, typically a value like 0.6 or 0.7. The decision matrix itself is the most critical part to customize; the rules provided are a starting example. You should modify them to precisely reflect your operational policies, such as adding rules for specific error codes or defining different budget exhaustion behaviors. After the prompt returns, your application harness must parse the JSON and route the workflow based on the selected_path field, using the accompanying fields as direct input for the next step, whether that's a retry loop, a clarification request to the user, or a payload for a human review queue.

The Escalation Path Selection Prompt is designed to sit at a critical decision point in your AI workflow—after a failure, low-confidence signal, or ambiguity has been detected but before the system commits to a recovery action. It should be called by your application harness, not by the end user. The harness must supply a structured input payload containing the failure type, current confidence score, retry budget state, and the original request context. The prompt returns a structured decision (retry, escalate to human, request clarification, or abort) with a rationale. This decision then drives the next step in your orchestration logic.

To wire this into production, build a decision function that constructs the prompt payload from your system's state. The function should pull the failure_type from your error classifier, the confidence_score from your model's self-assessment or an external evaluator, and the retry_budget_remaining from a counter you maintain per request or session. Call the LLM with this prompt and parse the output against a strict schema. Validate the response before acting on it: check that the selected_path is one of your allowed enum values (retry, escalate, clarify, abort), that the rationale is non-empty, and that the decision is consistent with your retry budget (e.g., reject a retry decision if retry_budget_remaining is zero). If validation fails, default to escalate and log the mismatch. Implement a hard retry budget cap in your harness code—the prompt can recommend a retry, but your application must enforce the limit to prevent infinite loops.

Log every decision this prompt makes, including the full input payload, the raw model output, the validated decision, and the timestamp. This audit trail is essential for tuning your escalation thresholds, debugging unexpected escalations, and demonstrating governance controls. For high-risk domains, route all escalate decisions to a human review queue with the structured handoff payload from the Human Handoff Trigger Prompt. For clarify decisions, surface the clarification question to the user and re-enter the workflow with the additional context. For retry decisions, increment your retry counter and loop back to the appropriate recovery prompt. Avoid using this prompt for real-time safety-critical decisions without human-in-the-loop confirmation on the escalate path. Test the full loop with simulated failure scenarios before deployment, and monitor the ratio of retry to escalate decisions in production to detect drift in model confidence calibration.