Escalation Prompt with Business Impact Analysis

Use this prompt when an autonomous agent or multi-agent system encounters a situation that has measurable business consequences and requires human judgment before proceeding. The job-to-be-done is structuring an escalation that a human reviewer can act on without reconstructing context: the agent must explain what happened, quantify or qualify the business impact, justify the urgency, and propose a response timeline. The ideal user is an AI platform engineer, reliability engineer, or product manager building agent workflows where downtime, revenue loss, compliance risk, or customer harm are possible outcomes of a wrong decision.

Do not use this prompt for routine status updates, low-stakes informational handoffs, or cases where the agent can safely proceed with a fallback action. This prompt is specifically for escalations that require a human to weigh business trade-offs. Required context includes: the triggering event, affected systems or user segments, a quantified or qualified impact assessment (e.g., estimated revenue at risk, number of users impacted, SLA breach proximity), the agent's confidence in its assessment, and any actions the agent has already taken or ruled out. Without this context, the human reviewer receives an incomplete escalation that forces a back-and-forth clarification loop.

Before deploying this prompt in production, wire it into an escalation threshold configuration that defines what constitutes a business-impact escalation versus a technical escalation or a routine handoff. Pair it with an eval harness that checks for impact accuracy (does the stated impact match the evidence?), urgency appropriateness (is the recommended timeline proportional to the impact?), and completeness (are all required fields populated?). In regulated domains, always require human review and log the full escalation payload as an audit artifact. The most common failure mode is over-escalation—agents flagging every anomaly as business-critical—so monitor escalation rates and tune thresholds after deployment.

This prompt template is designed for agents that need to escalate issues with business consequences to a human reviewer. It structures the escalation around a quantified or qualified impact assessment, identifies affected systems or user segments, justifies the urgency level, and recommends a response timeline. The template uses square-bracket placeholders that your application must populate before sending the request to the model. Each placeholder represents a variable your agent runtime, monitoring system, or upstream workflow should supply.

textCopy
You are an escalation agent responsible for structuring issues that require human review due to business impact.

## Context
[SYSTEM_STATE_SUMMARY]

## Escalation Trigger
[TRIGGER_EVENT_DESCRIPTION]

## Instructions
Analyze the escalation trigger and produce a structured handoff for a human reviewer. Your output must follow the schema below exactly.

### Required Analysis
1. **Impact Assessment**: Quantify or qualify the business impact. Include affected revenue, users, SLAs, or operational capacity where data is available. If exact numbers are unavailable, provide a bounded estimate with confidence.
2. **Affected Scope**: List the systems, services, user segments, or business functions affected. Distinguish between confirmed impact and potential blast radius.
3. **Urgency Justification**: Explain why this escalation requires attention now rather than later. Reference time-sensitive factors such as SLA windows, revenue loss rate, regulatory deadlines, or cascading failure risk.
4. **Recommended Response Timeline**: Propose a response window (e.g., within 15 minutes, within 1 hour, within 24 hours) with reasoning tied to the impact assessment.
5. **Evidence Summary**: Provide the key observations, metrics, or logs that support the impact assessment. Cite specific sources where available.

### Constraints
- Do not minimize or exaggerate the impact. State what is known and what is uncertain.
- If the impact cannot be quantified, explain why and provide the best available qualitative assessment.
- Flag any assumptions you are making about business context that the human reviewer should validate.
- If the escalation trigger suggests a false positive or low-impact event, state that explicitly rather than escalating unnecessarily.

### Output Schema
Return a JSON object with the following structure:
{
  "escalation_id": "string",
  "severity": "critical|high|medium|low",
  "impact_assessment": {
    "quantified_impact": "string | null",
    "qualitative_impact": "string",
    "confidence": "high|medium|low",
    "assumptions": ["string"]
  },
  "affected_scope": {
    "systems": ["string"],
    "user_segments": ["string"],
    "confirmed_impact": ["string"],
    "potential_blast_radius": ["string"]
  },
  "urgency": {
    "level": "immediate|elevated|routine",
    "justification": "string",
    "deadline_if_known": "string | null"
  },
  "recommended_response": {
    "timeline": "string",
    "suggested_actions": ["string"],
    "fallback_if_no_response": "string"
  },
  "evidence": [
    {
      "source": "string",
      "observation": "string",
      "timestamp": "string"
    }
  ],
  "human_decision_required": ["string"]
}

### Examples
[FEW_SHOT_EXAMPLES]

### Risk Level
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with data from your application context. [SYSTEM_STATE_SUMMARY] should contain the agent's current understanding of the system, including recent actions, observations, and any prior escalations. [TRIGGER_EVENT_DESCRIPTION] is the specific event, metric threshold breach, or agent determination that triggered the escalation. [FEW_SHOT_EXAMPLES] should include 1-3 examples of well-formed escalations at different severity levels to calibrate the model's output. [RISK_LEVEL] should be set to high when the escalation involves revenue loss, regulatory exposure, or safety concerns, which tells the model to be more conservative in its assessments and to flag uncertainty explicitly.

Before deploying this prompt, validate that your application can supply all required placeholders with real data. If [FEW_SHOT_EXAMPLES] is empty, the model may still produce reasonable output but will be less calibrated to your organization's severity definitions. Test the prompt against a golden dataset of known escalation scenarios and measure whether the severity classification, urgency level, and impact quantification match expected labels. For high-risk domains, always route the model's output through a human reviewer rather than acting on the escalation automatically. Log every escalation output alongside the trigger event for auditability and retrospective analysis.

This prompt is designed to sit at the boundary between an autonomous agent and a human operations queue. It should fire when an agent detects a condition that exceeds its authority, confidence, or capability threshold—specifically conditions with measurable business impact. In practice, this means the prompt is called by an orchestration layer (e.g., a task graph, a supervisor agent, or a workflow engine) after the primary agent has already attempted to resolve the issue or has determined that resolution requires human judgment. The orchestration layer must supply the agent's internal state: what it observed, what it attempted, the affected business entities, and any quantified impact metrics it can compute. Do not call this prompt for trivial errors, retryable failures, or informational alerts; it is for escalation events that carry operational or financial consequences.

Wire the prompt into a structured handoff pipeline with the following components. Input assembly: collect the agent's trace, error context, affected system IDs, user-impact counts, and any SLI/SLO breaches into the [CONTEXT] block. If your system tracks business metrics (revenue impact, latency penalties, user churn risk), include those as structured fields. Model selection: use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). The prompt requires the model to produce a JSON escalation record with fields for impact_assessment, urgency_level, recommended_response_timeline, and required_decisions. Validation layer: after generation, validate the output against a strict schema. Reject any escalation record where urgency_level is not one of the allowed enum values (critical, high, medium, low), where recommended_response_timeline is missing or implausible, or where the impact_assessment lacks a quantified or qualified business consequence. If validation fails, retry once with the validation errors appended to the prompt as feedback. If the retry also fails, escalate the raw agent context to a human reviewer with a flag indicating the automation could not structure the escalation.

For high-risk domains (finance, healthcare, infrastructure), add a human review gate before the escalation reaches any downstream system. The structured output should be rendered into a review UI that shows the original agent context alongside the model's impact analysis, with explicit approve/revise/reject actions. Log every escalation event—including the raw agent state, the generated escalation record, the validator result, and the human decision—into an audit trail. This traceability is essential for post-incident review and for tuning the escalation thresholds over time. Retry and fallback logic: if the model call fails due to a transient error, retry with exponential backoff up to three attempts. If the model consistently produces invalid output, flag the prompt version for review and fall back to a simpler template that asks for a free-text summary with structured headings, which a human can triage manually. Tool integration: if your agent platform supports tool calls, consider exposing a log_escalation function that writes the validated escalation record to your incident management system (PagerDuty, ServiceNow, Jira) and a page_oncall function for critical urgency levels. The prompt's output schema should map directly to the tool's input parameters so the orchestration layer can call the tool without additional parsing.

Before deploying, build a small eval suite with 10–15 escalation scenarios covering different impact types (revenue loss, user-facing degradation, data integrity risk, security concern) and urgency levels. For each scenario, define the expected urgency_level and key fields that must appear in the impact_assessment. Run the eval suite on every prompt change and gate deployment on passing all cases. Monitor production for drift signals: escalation records with urgency_level: critical that are consistently downgraded by human reviewers, impact assessments that use vague language instead of specific metrics, and escalation volume spikes that suggest the agent's escalation threshold is too low. These signals indicate the prompt or the upstream agent logic needs adjustment. The most common failure mode is the model producing a well-formatted but substantively wrong urgency classification because it overweights the agent's alarmed language and underweights the actual business metrics—calibrate with few-shot examples that teach the model to anchor on numbers, not tone.