Escalation Decision with SLA Compliance Check Prompt

This prompt is designed for the specific moment in an agent orchestration layer when a task is in-flight and a decision must be made: continue processing, or escalate to a human or fallback system. It is not a simple timeout check. The core job-to-be-done is to force the model to reason about the remaining SLA time budget, the probability of a breach, and the cost of delay before making a routing decision. The ideal user is a platform operator or reliability engineer embedding this prompt into an agent harness that must enforce contractual time commitments and avoid silent SLA violations. You should use this when your system has a defined SLA (e.g., 5 minutes, 1 hour) and the current task's progress and latency are measurable.

To use this effectively, you must provide the prompt with real-time operational data. This includes the task's start time, the current time, the SLA deadline, the estimated time to completion, and the cost of a breach. The prompt template is designed to ingest these variables and output a structured decision. A concrete implementation would involve an upstream process that calculates the [REMAINING_TIME_BUDGET] and [BREACH_PROBABILITY] before injecting them into the prompt. The model's job is not to calculate these values but to reason about the trade-offs they represent. For example, a task with a 95% breach probability and a high breach cost should almost always trigger an immediate escalation, while a task with a 10% breach probability and a low cost might warrant continued processing with a follow-up check.

Do not use this prompt for simple, static timeout-based routing where the decision is a binary if elapsed_time > timeout then escalate. That logic belongs in application code, not an LLM call. This prompt is for scenarios where the decision is non-obvious and requires weighing the risk of a breach against the cost and disruption of an escalation. It is also unsuitable for tasks where SLA compliance is not a primary concern. The next step after implementing this prompt is to wire its structured output into your orchestration logic, ensuring that an escalate decision triggers the correct handoff workflow and that the decision itself is logged for auditability. Avoid using this prompt without a validation layer that checks the output schema and logs the decision context for future SLA compliance reporting.

This prompt template is designed to be pasted directly into your agent's system instructions or an escalation decision node. It forces the model to consider current SLA status, remaining time or budget, and breach risk before recommending an action. The output is a structured JSON object that your orchestration layer can parse to route the task to a human, a fallback agent, or a specialized queue. Every square-bracket placeholder must be replaced with live data from your SLA monitoring system before each invocation.

textCopy
You are an escalation decision engine for an autonomous agent platform. Your job is to evaluate whether the current agent should continue working on a task or escalate it based on SLA compliance risk.

## INPUT DATA
- Current Task: [TASK_DESCRIPTION]
- Agent Capability Assessment: [CAPABILITY_GAP_REPORT]
- SLA Target: [SLA_TARGET_IN_SECONDS]
- Elapsed Time: [ELAPSED_TIME_IN_SECONDS]
- Remaining Budget: [REMAINING_BUDGET_PERCENT]
- Breach Risk Score: [BREACH_RISK_SCORE_0_TO_1]
- Policy Rules: [APPLICABLE_POLICY_CLAUSES]

## DECISION RULES
1. If Breach Risk Score > 0.8, escalate immediately regardless of other factors.
2. If Elapsed Time exceeds 80% of SLA Target and the agent has not produced a verifiable partial result, escalate to a human reviewer.
3. If Remaining Budget < 10% and the task is not on a critical path, escalate to a lower-cost fallback agent.
4. If the Capability Gap Report indicates the agent cannot complete the task with confidence > 0.7, escalate to the specialized agent or human queue specified in the report.
5. Otherwise, allow the agent to continue.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "decision": "continue" | "escalate",
  "escalation_target": "human_review" | "fallback_agent" | "specialized_agent" | null,
  "reason_code": "BREACH_RISK" | "TIME_EXCEEDED" | "BUDGET_EXHAUSTED" | "CAPABILITY_GAP" | "POLICY_TRIGGER" | "NONE",
  "rationale": "A concise explanation citing the specific SLA metric, policy clause, or capability gap that drove the decision.",
  "breach_risk_at_decision": [BREACH_RISK_SCORE_0_TO_1],
  "context_for_target": "A structured summary of what the next agent or human needs to know to resume the task without rework."
}

## CONSTRAINTS
- Do not invent SLA metrics. Use only the values provided in the input data.
- If multiple escalation conditions are met, select the one with the highest severity (Breach Risk > Time Exceeded > Budget Exhausted > Capability Gap).
- The rationale must reference at least one specific input value.
- If the decision is "continue", escalation_target must be null and reason_code must be "NONE".

Before deploying this prompt, validate that your SLA monitoring system can supply every placeholder with accurate, real-time values. Stale or missing data will cause the model to either refuse the task or produce a decision based on incorrect assumptions. For high-risk production environments, add a post-processing step that verifies the output JSON against the schema and logs every escalation decision with the full input context for auditability. If the model returns a decision that contradicts the hard rules (e.g., continuing when Breach Risk Score > 0.8), your harness should reject the output and retry or fall back to a deterministic rule engine.

This prompt functions as a pre-action gate within an agent orchestration layer. It must be invoked before the agent executes each major step or whenever a step exceeds its expected duration. The primary integration point is a decision node in your agent graph that calls the LLM with this prompt, parses the structured decision field from the response, and routes execution accordingly. The harness is responsible for enforcing the SLA budget check, not the prompt itself. The prompt provides the decision logic; the harness enforces the hard constraints.

On receiving the output, parse the top-level decision field. If the value is escalate, immediately route the full context payload to the specified escalation_target and log the reason_code. If the value is continue, update the agent's remaining SLA budget in your state store and allow the agent to proceed to its next action. Always log the full decision payload—including sla_budget_remaining, breach_risk, and reason_code—to your immutable audit store. This log is your primary artifact for SLA compliance reporting and post-incident review. Implement a retry wrapper around the model call with exponential backoff (e.g., 1s, 2s, 4s), but include a critical guard: do not retry if the remaining SLA budget is below 10 percent of the target. In that low-budget scenario, bypass the model call entirely and force-escalate to the fastest available human path, logging the forced escalation with reason code SLA_BUDGET_EXHAUSTED.

For model choice, prefer a fast, instruction-following model (e.g., GPT-4o, Claude 3.5 Sonnet) with low latency, as this prompt sits on the critical path of agent execution. Set temperature=0 to ensure deterministic escalation decisions. Validate the output against a strict JSON schema before acting on the decision field; if parsing fails, treat it as an escalate decision with reason code PARSE_FAILURE. In high-risk domains, add a human approval step for any continue decision when breach_risk is high. Do not use this prompt for trivial steps where SLA budget is irrelevant—reserve it for state-changing operations, external API calls, or user-facing actions where an SLA miss carries business impact.