Escalation Criteria Definition Prompt for Agent Systems

This prompt is for system architects and platform engineers who need to convert operational requirements, risk policies, and capability boundaries into a structured, machine-readable escalation policy document. The job-to-be-done is not just writing a policy in prose, but producing a set of explicit conditions, thresholds, and routing rules that an agent harness can evaluate at runtime. Use this when you are designing a new multi-agent system, hardening an existing agent's handoff logic, or preparing for a compliance review that requires traceable escalation decisions. The ideal user has access to the system's service-level objectives (SLOs), known model capability limits, a risk matrix, and a topology of available downstream agents or human review queues.

Do not use this prompt when you need a runtime escalation decision for a single event. This prompt defines the policy; it does not execute it. For live decisions, pair the output of this prompt with the Risk-Based Escalation Decision Prompt or the Agent Escalation Confidence Threshold Prompt Template. Also avoid this prompt if your agent topology is undefined or if you lack concrete operational constraints—the output will be generic and untestable. The prompt requires square-bracket placeholders for [AGENT_CAPABILITIES], [RISK_MATRIX], [OPERATIONAL_CONSTRAINTS], [AVAILABLE_ESCALATION_TARGETS], and [EDGE_CASE_SCENARIOS]. If you cannot populate these with real data, stop and define them first.

After generating the policy document, you must validate it against the provided edge-case scenarios and run it through a structured output parser. The policy should be stored as a versioned artifact in your agent orchestration layer, not as a one-off chat response. Wire the resulting JSON policy into your agent's handoff evaluator so that every stop_and_escalate decision is logged with a reference to the specific policy clause that triggered it. For high-risk domains, require human review of the generated policy before it goes live, and schedule a review cadence tied to model updates or topology changes.

This prompt template is designed to be dropped into an agent orchestration layer or a policy-generation workflow. It takes raw operational requirements—such as capability boundaries, risk thresholds, and tool availability—and produces a structured escalation policy document. The output is intended to be parsed by downstream routing logic or reviewed by a reliability engineer before being encoded into agent configuration. The template uses square-bracket placeholders for all variable inputs, making it safe to wrap in a string formatting function or a prompt assembly pipeline without accidental token collision.

textCopy
You are an escalation policy architect for an autonomous agent system. Your task is to produce a structured escalation criteria document based on the operational requirements provided.

## SYSTEM CONTEXT
[SYSTEM_DESCRIPTION]

## AGENT CAPABILITIES
Current agent scope and known limitations:
[AGENT_CAPABILITIES]

## AVAILABLE ESCALATION TARGETS
List of agents, humans, or fallback paths that can receive escalations:
[ESCALATION_TARGETS]

## RISK TOLERANCE
[RISK_TOLERANCE]

## REGULATORY OR COMPLIANCE CONSTRAINTS
[COMPLIANCE_CONSTRAINTS]

## OPERATIONAL REQUIREMENTS
[OPERATIONAL_REQUIREMENTS]

## OUTPUT SCHEMA
Produce a JSON document with the following structure:
{
  "policy_name": "string",
  "version": "string",
  "escalation_rules": [
    {
      "rule_id": "string",
      "trigger_condition": "string (precise, machine-evaluable description)",
      "trigger_category": "capability_gap | confidence_threshold | risk_threshold | policy_violation | tool_failure | timeout | ambiguity | deadlock | circuit_breaker",
      "thresholds": {
        "metric": "string",
        "operator": "lt | lte | gt | gte | eq | neq",
        "value": "number | string"
      },
      "escalation_target": "string (must match an entry in AVAILABLE ESCALATION TARGETS)",
      "priority": "critical | high | medium | low",
      "required_context_payload": ["field1", "field2"],
      "cooldown_seconds": "number (minimum time before this rule can fire again)",
      "human_review_required": "boolean"
    }
  ],
  "default_fallback": "string (target when no rule matches)",
  "circuit_breaker": {
    "max_consecutive_escalations": "number",
    "reset_window_seconds": "number",
    "breaker_action": "halt | route_to_human | route_to_fallback"
  },
  "audit_requirements": ["field1", "field2"]
}

## CONSTRAINTS
- Every trigger_condition must be specific enough to evaluate programmatically.
- Every escalation_target must reference an entry from AVAILABLE ESCALATION TARGETS.
- Include at least one rule for each trigger_category that applies to this system.
- If COMPLIANCE_CONSTRAINTS are provided, every rule that touches regulated data must set human_review_required to true.
- The circuit_breaker configuration must prevent infinite escalation loops.
- Do not invent capabilities or targets not listed in the inputs.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## OUTPUT
Return only valid JSON. No markdown fences, no commentary.

To adapt this template, replace each square-bracket placeholder with concrete values from your system design documents. The [FEW_SHOT_EXAMPLES] placeholder is optional but strongly recommended: provide one or two example escalation rules that match your domain's expected trigger conditions and routing patterns. If your system has no compliance constraints, set [COMPLIANCE_CONSTRAINTS] to "None" and the constraint about human_review_required will not activate. Before wiring this into an automated pipeline, validate the output JSON against the schema and run a set of edge-case scenarios—such as simultaneous trigger conditions or missing escalation targets—through the policy to confirm the generated rules produce correct routing decisions. For high-risk domains, always route the generated policy through a human review step before deploying it to production agent orchestration.

This prompt is designed as a policy generation step, not a runtime decision point. It should be called during system configuration or policy update workflows—whenever operational requirements change, new agent capabilities are added, or post-incident reviews reveal gaps in existing escalation rules. The output is a structured document that downstream agent orchestrators, circuit breakers, and handoff routers will consume as their source of truth. Treat this prompt as a build-time artifact generator, not a per-request classifier.

Wire the prompt into a policy management pipeline with these components: (1) Input assembly—collect operational requirements, risk matrices, agent capability manifests, and regulatory policy documents into the [OPERATIONAL_REQUIREMENTS] and [POLICY_DOCUMENTS] placeholders. If using RAG, retrieve relevant policy clauses and agent capability specs before prompt assembly. (2) Schema validation—parse the generated JSON output against a strict schema that enforces required fields (condition_id, trigger_type, threshold, target_agent, priority, evidence_required). Reject and retry any output missing these fields. (3) Edge-case testing—run the generated policy through a battery of synthetic scenarios (agent timeout, tool failure, ambiguous intent, confidence below threshold, regulatory keyword match) and verify each scenario maps to exactly one escalation rule with a non-null routing target. (4) Human review gate—before the policy document is deployed to production agent routers, route it to a policy reviewer with a diff against the previous version. The reviewer approves, rejects, or amends. (5) Versioned deployment—store the approved policy with a semantic version, deploy it to agent orchestrators via a configuration store (not hardcoded in prompts), and log every policy change with the reviewer's identity and timestamp.

Model choice matters here. Use a model with strong structured output capabilities and long-context handling (GPT-4o, Claude 3.5 Sonnet, or equivalent). The prompt requires reasoning over multiple constraint sources simultaneously—operational requirements, risk matrices, capability boundaries, and regulatory text. Weaker models tend to drop edge-case conditions or produce overlapping rules. Set temperature low (0.0–0.2) for deterministic policy generation. Retry logic: if schema validation fails, retry up to 2 times with the validation errors injected into the [CONSTRAINTS] field as explicit corrections. If retries are exhausted, escalate to a human policy author with the partial output and error log. Observability: log the prompt version, input hash, output schema validation result, edge-case coverage percentage, and reviewer decision. This audit trail is essential for compliance environments where escalation policy changes must be traceable to specific operational triggers or regulatory updates.

What to avoid: Do not use this prompt at runtime inside an agent's decision loop. It is too expensive and slow for per-request escalation decisions. Instead, use the generated policy document to configure lightweight runtime prompts like the Escalation Confidence Threshold Prompt or Risk-Based Escalation Decision Prompt elsewhere in this pillar. Do not skip the edge-case testing harness—policies that look complete on first read often have blind spots around tool failure modes, timeout scenarios, or overlapping agent capabilities. Finally, never deploy a generated policy without human review if the escalation paths involve safety-critical systems, regulated data, or customer-facing handoffs. The cost of a bad escalation rule is higher than the cost of a review cycle.