Agent Role Escalation Policy Prompt

This playbook is for reliability engineers and platform architects who need to define a structured escalation policy for an agent. Use this prompt when you have an agent with a defined role and capability boundary, and you need to specify the exact conditions under which it must stop its own execution and hand off work. The prompt generates a decision tree with clear triggers, confidence thresholds, risk classifications, and the expected format for the handoff payload. It is not for defining the agent's core role or tool access; those should already be established before applying this escalation policy.

Apply this prompt when you are integrating an agent into a production system where silent failures, overconfident actions, or unhandled capability gaps could cause downstream harm. Typical triggers include: the agent encounters a task outside its declared scope, its confidence score drops below a defined threshold, a tool returns an unrecoverable error, a safety policy is violated, or a human approval gate is required. The output is a machine-readable escalation policy that an orchestrator or agent harness can enforce programmatically. Do not use this prompt for defining the agent's primary role, tool contracts, or input/output schemas—those are separate contracts that this policy references.

Before running this prompt, you must have the agent's role definition, capability boundary contract, and tool access policy available as input context. The prompt expects these as structured inputs so it can reason about what falls inside versus outside the agent's authority. After generating the escalation policy, wire it into your agent harness as a pre-action and post-action check. Test it with both in-scope and out-of-scope requests, and validate that the handoff payload format is compatible with your orchestrator's ingestion contract. The most common failure mode is an escalation policy that is too permissive, allowing the agent to continue past its boundary, or too restrictive, causing unnecessary escalations that flood a human review queue.

The following prompt template is designed to be integrated into an agent orchestration layer or a reliability engineering workflow. It takes a structured description of an agent's role, its known capability gaps, and the operational risk context, and produces a concrete escalation policy. The output is a decision tree that can be directly translated into application logic, with clear triggers, expected handoff payloads, and test cases for validating the policy before deployment.

textCopy
You are an escalation policy designer for a multi-agent system. Your task is to produce a strict, machine-actionable escalation decision tree for a single agent role.

## AGENT ROLE DEFINITION
[AGENT_ROLE_DEFINITION]

## KNOWN CAPABILITY GAPS
[CAPABILITY_GAPS]

## OPERATIONAL CONTEXT
- Risk Level: [RISK_LEVEL]
- Human Reviewer Available: [HUMAN_AVAILABLE]
- Sibling Agents: [SIBLING_AGENT_LIST]
- Fallback Paths: [FALLBACK_PATHS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "agent_id": "string",
  "policy_version": "string",
  "escalation_tree": [
    {
      "trigger_id": "string",
      "trigger_condition": "string describing the exact condition in plain language",
      "condition_type": "confidence_threshold | capability_gap | risk_threshold | policy_violation | tool_failure | timeout | ambiguous_request",
      "threshold_value": "number or string, null if not applicable",
      "escalation_target": "agent_id | human_reviewer | fallback_path | stop_execution",
      "handoff_payload_schema": {
        "required_fields": ["field_name"],
        "context_summary": "string template with placeholders",
        "evidence_package": ["list of artifacts to include"]
      },
      "priority": "critical | high | medium | low",
      "cooldown_seconds": "number, minimum seconds before this trigger can fire again"
    }
  ],
  "default_no_escalation_behavior": "string describing what happens when no trigger fires",
  "test_cases": [
    {
      "scenario": "string description",
      "expected_trigger": "trigger_id or null",
      "input_conditions": {}
    }
  ]
}

## CONSTRAINTS
- Every trigger_condition must be evaluable by application code without an LLM call.
- Escalation targets must exist in the provided sibling agent list or fallback paths.
- Include at least one test case for each trigger and at least two test cases where no escalation should occur.
- For risk_level "high" or "critical", default to escalation when uncertain rather than silent continuation.
- Handoff payloads must include enough context for the receiver to act without re-asking the user.

Generate the escalation policy.

To adapt this template, replace each square-bracket placeholder with concrete values from your agent registry and operational runbooks. The [AGENT_ROLE_DEFINITION] should be the output of an Agent Role Definition Prompt or a structured role contract. The [CAPABILITY_GAPS] field should list specific tasks or domains the agent is not authorized or able to handle. For high-risk deployments, ensure the generated policy is reviewed by a human before it is encoded into orchestration logic, and run the included test cases against a simulated agent environment to verify that escalation triggers fire correctly and that no trigger condition produces a false negative under load.

This prompt is not a standalone chatbot interaction. It is a policy-generation step that runs at agent registration time or during a policy refresh cycle. The output—a structured escalation decision tree—must be consumed by an orchestrator or agent runtime, not displayed directly to an end user. Treat the prompt as a configuration artifact generator: it produces a machine-readable policy that the system enforces at runtime. The implementation harness must validate the output against the expected schema, store it in a policy registry, and surface any ambiguity or missing triggers for human review before the policy goes live.

Wire the prompt into a policy provisioning pipeline. When a new agent role is defined or an existing role's scope changes, the pipeline assembles the prompt with the agent's capability boundary contract, tool access manifest, and risk classification as [CONTEXT]. The model returns a JSON escalation tree with trigger conditions, target escalation paths (agent ID, human queue, or fallback procedure), and required handoff payload schemas. Before accepting the output, run a structural validator that checks: every trigger has a non-empty condition, every target is a valid registered endpoint, and every handoff schema references known fields from the agent's output contract. Reject and retry with a repair prompt if validation fails. For high-risk domains, route the validated policy to a human reviewer through an approval queue before activation.

At runtime, the orchestrator evaluates escalation triggers after each agent step. If the agent's confidence score drops below the threshold defined in the policy, or if a stop-condition matches, the orchestrator reads the escalation target and assembles the handoff payload using the schema from the policy. Log every escalation event with the trigger that fired, the agent state at the time, and the target that received the handoff. This log becomes your audit trail for debugging incorrect escalations. Avoid hardcoding escalation paths in the orchestrator; always read them from the validated policy artifact. When updating the policy, run the new version through the same validation and review pipeline, and keep the previous version active until the new one passes all checks.