Escalation Trigger Definition Prompt for Sub-Task Failures

This prompt is for reliability engineers and platform operators who need to define precise, machine-readable escalation rules for sub-task failures in a multi-agent orchestration system. Use it when you have an existing task decomposition, a pool of agents with defined capabilities, and a set of failure modes that require different responses: retry, reassign, escalate to a supervisor agent, escalate to a human, or trigger a fallback workflow. The prompt produces a structured escalation policy that your orchestrator can execute programmatically, including thresholds, evidence requirements, and routing instructions.

The ideal user has already completed task decomposition and agent role assignment. You should have a list of sub-tasks with clear input/output contracts, a known set of failure modes observed or anticipated in your system, and access to the agent capability registry. The prompt requires you to supply the failure modes, agent pool, risk tolerance levels, and any regulatory or SLA constraints that govern escalation timing. Without these artifacts, the prompt will produce generic rules that lack the specificity needed for production execution. Do not use this prompt for defining agent roles, decomposing tasks, or designing handoff summaries. It assumes those artifacts already exist and focuses solely on the failure-to-escalation mapping.

Before running this prompt, validate that your failure mode catalog is complete and that each mode has a measurable trigger condition. The output should be directly consumable by your orchestrator's policy engine, so plan to test the generated rules against historical failure traces and synthetic edge cases. Pay particular attention to false-escalation and missed-escalation rates, as poorly calibrated thresholds will either flood your human review queue or allow critical failures to go unnoticed. After generating the escalation policy, run it through a dry-run simulation against your last 100 production failures to verify routing accuracy before deploying to production.

This prompt template is designed to be pasted directly into your orchestration layer. It instructs a model to act as a reliability engineer, analyzing a sub-task's failure context and producing a structured escalation rule. The rule must define clear thresholds, required evidence, and a specific routing target to prevent ambiguous or premature escalations in production.

codeCopy
You are a reliability engineer defining escalation rules for an autonomous agent system. Your task is to analyze a sub-task failure and produce a strict, machine-readable escalation trigger definition.

**Sub-Task Context:**
- Task ID: [TASK_ID]
- Task Description: [TASK_DESCRIPTION]
- Assigned Agent Role: [AGENT_ROLE]
- Failure Mode: [FAILURE_MODE] (e.g., Timeout, Validation Error, Tool Failure, Low Confidence)
- Retry Attempts Made: [RETRY_COUNT]
- Last Error Message: [LAST_ERROR]
- Current State of Upstream Dependencies: [UPSTREAM_STATE]
- Current State of Downstream Dependencies: [DOWNSTREAM_STATE]
- Business Impact if Task is Abandoned: [BUSINESS_IMPACT] (e.g., Low, Medium, High, Critical)

**Constraints for Escalation Rule:**
- [CONSTRAINTS] (e.g., "Must not escalate for transient timeout if retries < 3", "Must escalate immediately for PII access violations")

**Available Routing Targets:**
- [ROUTING_TARGETS] (e.g., "supervisor_agent", "human_review_queue", "fallback_workflow_v2")

**Output Schema:**
Produce a JSON object with the following structure:
{
  "rule_id": "string",
  "trigger_condition": "string (a precise, testable boolean expression)",
  "required_evidence": ["string"],
  "routing_target": "string",
  "handoff_payload_schema": {
    "summary": "string",
    "failure_context": "string",
    "last_input": "string",
    "last_output": "string"
  },
  "false_escalation_risk": "string (Low, Medium, High)",
  "missed_escalation_risk": "string (Low, Medium, High)",
  "cooldown_period_seconds": "integer"
}

**Examples of Good Trigger Conditions:**
- "retry_count >= 3 AND error_type == 'tool_timeout'"
- "confidence_score < 0.7 AND business_impact == 'High'"
- "error_message CONTAINS 'authorization' AND agent_role != 'admin'"

Do not include any text outside the JSON object.

To adapt this template, replace the square-bracket placeholders with values from your agent execution context. The trigger_condition field is the most critical; it must be a boolean expression that your orchestration engine can evaluate programmatically. Before deploying any rule generated by this prompt, run it through a validation harness that simulates the trigger condition against historical failure logs to measure the false-escalation and missed-escalation rates. For high-risk workflows where business_impact is 'Critical', always route the generated rule to a human for approval before activation.

This prompt is not a one-off analysis tool—it is a configuration generator for your agent orchestration layer. The output should be consumed programmatically by a supervisor agent, workflow engine, or incident management system. Treat the generated escalation rules as machine-readable policy that gets loaded into a rules engine, not as a document for humans to read and manually apply. The prompt expects structured inputs about the failing sub-task, its dependency graph, and the current execution state, and it must produce a deterministic JSON schema that downstream systems can parse without ambiguity.

Wire the prompt into a post-failure hook in your agent orchestrator. When a sub-task fails (tool error, timeout, validation rejection, or confidence below threshold), the orchestrator should assemble the required inputs—[FAILED_TASK_DEFINITION], [FAILURE_DETAILS], [DEPENDENCY_GRAPH], [EXECUTION_HISTORY], [AGENT_CAPABILITY_REGISTRY], and [OPERATIONAL_CONSTRAINTS]—and invoke this prompt. The model's output must be validated against the escalation rule schema before any action is taken. Implement a schema validator that checks for required fields (escalation_decision, routing_target, evidence_summary, false_escalation_risk, missed_escalation_risk), enum constraints on routing_target (must be one of human_operator, supervisor_agent, fallback_workflow, retry), and numeric ranges on risk scores (0.0–1.0). If validation fails, log the malformed output and retry with a repair prompt that includes the schema violation details.

For high-risk domains—finance, healthcare, safety-critical operations—add a human approval gate before executing the escalation decision, even when the model routes to human_operator. The prompt's output should be surfaced in a review queue with the evidence summary, failure context, and recommended action. The human reviewer can override the routing decision, and that override should be logged as a calibration data point for future prompt improvement. Track false-escalation rate (escalations that a human reviewer dismisses as unnecessary) and missed-escalation rate (failures that should have escalated but didn't, discovered through post-incident review). Use these metrics to tune the prompt's risk thresholds and evidence requirements over time. Model choice matters: use a model with strong structured output capabilities and low refusal rates on operational decision prompts. Avoid models that over-refuse on risk-assessment tasks, as they will produce unhelpful null escalations when you need a decision.