Agent Timeout Escalation Prompt

This prompt is designed for Site Reliability Engineers (SREs) and orchestration platform operators who need a programmatic, deterministic decision when a specialized agent in a multi-agent workflow exceeds its defined Service Level Agreement (SLA) threshold. The core job-to-be-done is not just detecting a timeout, but producing a structured escalation payload that assesses the partial work, estimates user impact, and routes the incident to the correct human or agentic escalation target. It replaces ad-hoc log diving and manual impact assessment with a consistent, machine-readable escalation record that can trigger downstream automation like pager alerts or workflow suspension.

Use this prompt when an agent's execution time breaches a pre-defined wall-clock or step-count limit, and you have access to the agent's execution trace, its original task definition, and the partial state it produced before timing out. The ideal user is an orchestration engineer integrating this into a workflow controller (e.g., a supervisor agent, a state machine, or a job queue) that catches the timeout exception and invokes this prompt as the immediate next step. Required context includes the agent's SLA contract, the raw task input, any intermediate outputs or tool-call logs, and a map of available escalation targets (e.g., a human on-call rotation, a fallback agent with reduced capabilities). Do not use this prompt for proactive health checks or latency prediction; it is a reactive escalation trigger, not a forecasting tool.

Avoid this prompt when the timeout is caused by a known, transient infrastructure blip that a simple retry with exponential backoff can resolve—this prompt adds decision latency and should be reserved for cases where retries are exhausted or prohibited by the SLA. It is also unsuitable for agents that do not produce any partial state, as the assessment of 'partial progress' becomes speculative. In high-severity incidents where the timeout itself indicates a cascading system failure, pair this prompt's output with a circuit-breaker activation prompt to prevent further damage. After generating the escalation decision, always log the full payload to your agent audit trail and ensure the escalation target receives a structured handoff, not just a raw alert.

This prompt template is designed to be injected into an orchestrator or supervisor agent when a worker agent has timed out. It forces a structured escalation decision instead of a silent failure or an ambiguous retry loop. The placeholders allow you to pipe in runtime context—such as the task description, elapsed time, and any partial output—so the model can assess user impact and recommend a specific escalation target.

codeCopy
You are an escalation controller for a multi-agent system. A worker agent has exceeded its SLA threshold and timed out. Your job is to produce a structured escalation decision based on the provided context. Do not retry the task. Do not fabricate results.

[TASK_DESCRIPTION]
[AGENT_ROLE]
[SLA_THRESHOLD_SECONDS]
[ELAPSED_TIME_SECONDS]
[PARTIAL_OUTPUT_IF_ANY]
[USER_IMPACT_CONTEXT]
[AVAILABLE_ESCALATION_TARGETS]
[CONSTRAINTS]

Generate a JSON escalation record with the following schema:
{
  "escalation_decision": "ESCALATE" | "ABORT" | "HOLD_FOR_HUMAN",
  "urgency": "P1_CRITICAL" | "P2_HIGH" | "P3_MODERATE" | "P4_LOW",
  "timeout_context": {
    "task": "<summary of what the agent was doing>",
    "sla_threshold_seconds": <number>,
    "elapsed_seconds": <number>,
    "overtime_seconds": <number>
  },
  "partial_progress_assessment": {
    "completion_estimate_percent": <0-100>,
    "usable_output_summary": "<what partial results can be salvaged, or null>",
    "data_loss_risk": "HIGH" | "MEDIUM" | "LOW" | "NONE"
  },
  "user_impact_estimate": {
    "affected_users_or_workflows": "<description>",
    "severity": "BLOCKING" | "DEGRADED" | "TRANSPARENT",
    "time_sensitivity": "IMMEDIATE" | "WITHIN_HOUR" | "WITHIN_DAY"
  },
  "recommended_escalation_target": {
    "target_type": "AGENT" | "HUMAN_TEAM" | "FALLBACK_WORKFLOW",
    "target_id": "<from AVAILABLE_ESCALATION_TARGETS>",
    "reason": "<why this target is appropriate>"
  },
  "handoff_package": {
    "context_for_target": "<concise summary of what the next handler needs to know>",
    "preserved_partial_output": "<the usable partial output, or null>",
    "outstanding_work_items": ["<list of remaining sub-tasks>"]
  },
  "do_not_retry": true
}

Rules:
- If PARTIAL_OUTPUT_IF_ANY is empty or null, set completion_estimate_percent to 0 and usable_output_summary to null.
- If the task is user-facing and blocking, urgency must be at least P2_HIGH.
- Never recommend retrying the same agent with the same input.
- If no escalation target fits, set escalation_decision to "HOLD_FOR_HUMAN" and target_type to "HUMAN_TEAM".

To adapt this template, replace each bracketed placeholder with data from your agent runtime. [TASK_DESCRIPTION] and [AGENT_ROLE] should come from the original dispatch instructions. [SLA_THRESHOLD_SECONDS] and [ELAPSED_TIME_SECONDS] are measured by your orchestrator. [PARTIAL_OUTPUT_IF_ANY] is whatever the agent emitted before timing out—pass it as a raw string or structured JSON. [USER_IMPACT_CONTEXT] should be a brief description of who is waiting on this task and what happens if it fails. [AVAILABLE_ESCALATION_TARGETS] is a list of agent IDs, team channels, or fallback workflow names. [CONSTRAINTS] can include policy rules like "never escalate billing tasks to the general-support agent." After generation, validate the JSON against the schema and check that the urgency level matches your internal severity definitions before routing the escalation.

The Agent Timeout Escalation Prompt is designed to be called by an orchestrator or supervisor agent when a worker agent exceeds its SLA threshold. The orchestrator should capture the worker's partial output, the elapsed wall-clock time, the SLA limit, and any tool-call logs before invoking this prompt. The prompt itself does not make the escalation decision—it produces a structured escalation recommendation that your application code must validate and act on. Treat the model's output as a decision-support artifact, not an autonomous trigger.

Wire the prompt into your orchestration layer as a synchronous call with a strict timeout of its own (e.g., 10 seconds). Pass the required placeholders: [AGENT_ID], [TASK_SUMMARY], [ELAPSED_TIME], [SLA_THRESHOLD], [PARTIAL_RESULTS], [TOOL_CALL_LOG], and [ESCALATION_TARGETS]. The model should return a JSON object matching the [OUTPUT_SCHEMA] you define—typically containing escalation_decision (boolean), urgency_level (low/medium/high/critical), partial_progress_assessment, user_impact_estimate, recommended_escalation_target, and reasoning. Validate this output in your application layer before routing: check that urgency_level is one of the allowed enum values, that recommended_escalation_target exists in your configured escalation registry, and that partial_progress_assessment does not fabricate completed work that the agent log doesn't support. If validation fails, retry once with the validation errors appended to the prompt context. If the retry also fails, fall back to a default escalation to the on-call human with a templated notification.

Log every invocation with the full prompt input, raw model output, validation result, and final routing decision. This audit trail is critical for SRE postmortems and for tuning SLA thresholds over time. For high-severity escalations (urgency high or critical), require human acknowledgment before the escalation target is notified—do not automate the notification path. Use a model that supports structured output (JSON mode or function calling) to reduce parsing failures. If you are using a model without native JSON mode, add a repair step using the Output Repair and Validation Prompts pillar to handle malformed responses. Avoid wiring this prompt directly into customer-facing surfaces; the escalation decision should always pass through an application-level circuit breaker that can suppress duplicate escalations, enforce cooldown periods, and respect maintenance windows.

Before deploying, run eval suites that test correct SLA breach detection (elapsed time above threshold should trigger escalation, below should not), appropriate urgency calibration (a 5-second overrun on a batch job should not produce critical urgency), and hallucination resistance in partial_progress_assessment (the model must not claim completion of steps absent from the tool-call log). Use the LLM Judge and Evaluation Rubrics pillar to build automated pass/fail checks on these dimensions. Start with a human-in-the-loop deployment where all escalations are reviewed for at least two weeks before enabling automated routing for low-urgency cases.