Escalation Prompt for Repeated Agent Failures

This prompt is designed for orchestration systems that detect an agent has failed the same task or task type repeatedly. Instead of letting the agent loop indefinitely or silently dropping the work, this prompt produces a structured escalation package. It aggregates failure patterns across attempts, identifies the most likely root cause, and recommends a concrete resolution path: reassign to a different agent, redesign the task or agent instructions, or escalate permanently to a human operator. Use this when your retry budget is exhausted and you need a decision, not another attempt.

The ideal user is an AI platform engineer or orchestration developer building a supervisor or controller agent that monitors worker agents. The required context includes the original task definition, the agent's role and capabilities, a log of each failed attempt with error traces, and the retry policy that was exhausted. This prompt is not for single-attempt failures, transient errors that a retry with backoff would resolve, or cases where the failure is clearly a tool outage that should be handled by infrastructure alerting. Do not use this prompt when the agent's output is non-deterministic and a simple majority-vote across parallel runs would suffice.

Before wiring this prompt into your system, define clear thresholds: maximum retry count, maximum wall-clock time, and a circuit-breaker for cascading failures. The prompt's value is in forcing a structured root-cause analysis and a concrete recommendation rather than producing another opaque failure log. After receiving the escalation output, your harness should log the decision, update the task state, and route to the recommended resolution path—not simply retry again. For high-risk domains such as finance or healthcare, always require human review of the escalation recommendation before automated reassignment or redesign actions are executed.

This prompt template is designed to be injected into your orchestration layer when a monitoring system detects that an agent has failed the same task or task type beyond a configured threshold. It consumes structured failure logs, not raw agent traces, and produces an escalation payload that a human operator or a supervisor agent can act on. The template uses square-bracket placeholders for all variable inputs, making it safe to paste directly into your prompt assembly code. Populate these placeholders from your agent execution logs, error telemetry, and task definitions before sending the request to the model.

textCopy
You are an escalation analyst for a multi-agent orchestration system. Your job is to review repeated agent failures, identify the most likely root cause, and recommend a resolution path.

## FAILURE CONTEXT
- **Failing Agent ID:** [AGENT_ID]
- **Agent Role:** [AGENT_ROLE_DESCRIPTION]
- **Task Type:** [TASK_TYPE]
- **Task Description:** [TASK_DESCRIPTION]
- **Failure Threshold:** [FAILURE_COUNT] failures within [TIME_WINDOW]

## FAILURE LOG
Below is a structured log of each failure attempt. Each entry includes the attempt number, timestamp, error code, error message, and a summary of the agent's state at failure time.

[FAILURE_LOG_ENTRIES]

## AGENT CAPABILITY BOUNDARY
[AGENT_CAPABILITY_DEFINITION]

## AVAILABLE ESCALATION PATHS
[ESCALATION_PATH_OPTIONS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "escalation_id": "string, unique identifier for this escalation",
  "failure_pattern": "string, categorized pattern: TRANSIENT_ERROR | CAPABILITY_GAP | INPUT_MALFORMATION | DEPENDENCY_FAILURE | POLICY_BLOCK | AMBIGUITY_LOOP | OTHER",
  "root_cause_assessment": "string, concise explanation of the most likely root cause based on the failure log",
  "supporting_evidence": ["string, specific failure log entry or pattern that supports the root cause assessment"],
  "recommended_action": "string, one of: RETRY_WITH_FIX | REASSIGN_TO_AGENT:[agent_id] | REDESIGN_TASK | ESCALATE_TO_HUMAN | DISABLE_TASK | NO_ACTION",
  "action_rationale": "string, why this action is recommended given the failure pattern and agent capability boundary",
  "handoff_package": {
    "summary_for_reviewer": "string, human-readable summary of what happened and what is needed",
    "pending_decisions": ["string, specific questions a human reviewer must answer"],
    "blocked_dependencies": ["string, any upstream systems or data that are blocking resolution"]
  },
  "confidence": "string, LOW | MEDIUM | HIGH indicating confidence in the root cause assessment",
  "requires_human_approval": "boolean, true if the recommended action should not be executed without human review"
}

## CONSTRAINTS
- Do not fabricate failure details not present in the failure log.
- If multiple failure patterns are present, select the dominant one and note others in the root cause assessment.
- If the failure log is incomplete or contradictory, set confidence to LOW and require human approval.
- For any recommended action that modifies agent configuration or disables a task, set requires_human_approval to true.
- If the failure pattern is POLICY_BLOCK, do not recommend workarounds that violate the policy.

To adapt this template, start by mapping your agent telemetry to the placeholders. [FAILURE_LOG_ENTRIES] should be a structured array of failure records, not raw stack traces—each entry needs an attempt number, timestamp, error code, error message, and a brief state summary. [AGENT_CAPABILITY_DEFINITION] should come from your agent's role specification or system prompt, describing what the agent is authorized and equipped to do. [ESCALATION_PATH_OPTIONS] should list the concrete paths available in your system, such as specific agent IDs for reassignment, human review queues, or task redesign workflows. The output schema is designed to be machine-readable so your orchestrator can parse the JSON and route the escalation automatically, but the handoff_package field ensures a human reviewer gets a readable summary without needing to inspect raw logs.

Before deploying this prompt, validate that your failure log entries contain enough signal for pattern detection. A log with only generic error codes like 'agent failed' will produce low-confidence escalations. Instrument your agents to capture categorized error codes, the input that triggered the failure, and any tool or dependency failures. Wire the prompt into a retry-aware escalation path: the orchestrator should only invoke this prompt after the agent has exhausted its configured retry budget, not on the first failure. For high-risk domains such as finance or healthcare, set requires_human_approval to true unconditionally in your harness logic, overriding the model's output if necessary.

Common failure modes for this prompt include: the model defaulting to ESCALATE_TO_HUMAN for every case because the failure log lacks sufficient detail; misclassifying a dependency failure as an agent capability gap; and recommending REASSIGN_TO_AGENT without verifying that the target agent actually has the required capability. Test this prompt with a golden dataset of failure logs that covers each failure pattern category, and measure whether the recommended action matches the expected resolution. If your system allows automatic reassignment or task disabling, add a hard gate that requires human approval before executing any destructive action, regardless of the model's output.

This prompt is designed to be invoked by an orchestrator or agent framework after a monitored agent has exceeded a configurable failure threshold for the same task. The harness should track attempts per task ID, classify failure types (tool error, parse error, timeout, policy refusal), and only trigger this escalation prompt when the retry budget is exhausted. Do not call this prompt on the first failure; it is a circuit breaker, not a retry mechanism. The orchestrator must pass the full failure log, the original task definition, and the agent's role specification into the [FAILURE_LOG], [TASK_CONTEXT], and [AGENT_SPEC] placeholders respectively.

Before sending the prompt, the harness must validate that the failure log contains at least two distinct attempts with the same task ID and that the failure types are not transient infrastructure errors (e.g., a 503 from an upstream API that should be handled by exponential backoff at the transport layer). The model choice should favor reasoning-capable models (such as Claude 3.5 Sonnet or GPT-4o) because the prompt requires pattern recognition across failure traces and root cause analysis. Set temperature to 0.1 or lower to reduce variance in the escalation recommendation. The output must be parsed into a typed object matching the [OUTPUT_SCHEMA] defined in the prompt, with fields for root_cause_category, recommended_action (one of reassign, redesign, escalate_permanently), and human_summary. If the model returns an invalid action or the JSON is malformed, the harness should log the raw output and default to escalate_permanently as a safe fallback, then notify the on-call channel.

For high-risk domains such as healthcare, finance, or safety-critical operations, the harness must route the generated escalation to a human review queue regardless of the model's recommendation. The human_summary field should be rendered in a ticket or incident management system (e.g., Jira, ServiceNow, PagerDuty) with a link to the full trace. Implement a feedback loop: when a human reviewer resolves the escalation, capture their decision and the actual root cause. This data becomes the evaluation set for measuring whether the escalation prompt's root cause classification and recommended action align with human judgment over time. Track the false-positive rate of escalations (cases where the agent could have recovered with a different retry strategy) and the miss rate (cases where the agent was not escalated but should have been). Use these metrics to tune the failure threshold and the prompt's instructions, not to automate the decision away from human review in high-stakes workflows.