Agent Escalation Circuit Breaker Prompt

This prompt is designed for SRE and platform engineering teams who need to protect multi-agent systems from cascading failures. Its job is to act as an automated decision point that evaluates recent failure history for a specific agent or tool and determines whether the circuit should be OPEN (stop routing work), HALF_OPEN (allow a single probe request), or CLOSED (resume normal routing). The ideal user is an engineer building or operating an agent orchestration layer that can programmatically enforce routing decisions based on the structured circuit state output. You should use this prompt when you have a system where a single failing agent can cause upstream backpressure, resource exhaustion, or degraded user experience across the entire agent graph.

To use this prompt effectively, you must provide a structured input containing recent failure events (with timestamps and error types), the current circuit state, and your configured thresholds for failure count, failure rate, and cooldown duration. The prompt is not a simple retry wrapper or a static timeout mechanism. It performs a reasoned state transition by weighing the recency and density of failures against your recovery parameters. For example, if an agent has experienced 5 timeout errors in the last 60 seconds and your threshold is 3, the prompt should recommend transitioning from CLOSED to OPEN and specify a cooldown period before attempting HALF_OPEN. The output includes the new state, a rationale, and a recommended cooldown timestamp, which your orchestration layer can consume directly.

Do not use this prompt for simple retry logic where a static exponential backoff is sufficient, or in systems where failure is expected and handled gracefully without affecting other components. It is also inappropriate for workflows where the cost of stopping all traffic to an agent is higher than the cost of occasional failures—for instance, in best-effort advisory agents that do not block critical paths. Before implementing this prompt, ensure your orchestration layer can enforce the circuit state transitions and that you have a monitoring system to track state changes, failure counts, and recovery success rates. Human review of circuit state transitions is recommended during initial tuning and for high-risk production systems where an incorrect OPEN state could cause widespread service degradation.

This prompt template is the core decision engine for an agent escalation circuit breaker. It is designed to be wired into your orchestration layer, receiving structured inputs about recent agent failures, the current circuit state, and operational thresholds. The model's job is not to execute the agent's task, but to act as a reliability safeguard, evaluating whether the system should continue, pause, or reroute work to prevent cascading failures. The template uses square-bracket placeholders for all dynamic inputs, making it ready for parameterization in your application code before each inference call.

textCopy
You are a circuit breaker controller for an autonomous agent system. Your sole responsibility is to evaluate the health of an agent execution path and decide whether to allow, throttle, or block further requests.

# CURRENT CIRCUIT STATE
- Circuit State: [CIRCUIT_STATE]
- Consecutive Failures: [FAILURE_COUNT]
- Total Requests in Window: [REQUEST_COUNT]
- Window Duration (seconds): [WINDOW_DURATION]
- Last Failure Timestamp: [LAST_FAILURE_TIME]
- Last Failure Type: [LAST_FAILURE_TYPE]

# CONFIGURATION THRESHOLDS
- Failure Threshold for Open: [FAILURE_THRESHOLD]
- Cooldown Period (seconds): [COOLDOWN_PERIOD]
- Half-Open Max Test Requests: [HALF_OPEN_MAX_REQUESTS]

# RECENT FAILURE DETAILS (last 5)
[FAILURE_DETAILS]

# AVAILABLE FALLBACK PATHS
[FALLBACK_PATHS]

# INSTRUCTIONS
1. Analyze the current circuit state and failure history against the configuration thresholds.
2. Determine the next circuit state: CLOSED, OPEN, or HALF_OPEN.
3. If the state is OPEN, calculate the remaining cooldown time and recommend a fallback path from the provided list.
4. If the state is HALF_OPEN, specify the maximum number of test requests to allow.
5. Provide a concise, evidence-based rationale for the decision.

# OUTPUT SCHEMA
Return a single JSON object with the following fields:
- "decision": {
    "next_state": "CLOSED" | "OPEN" | "HALF_OPEN",
    "allow_request": boolean,
    "cooldown_remaining_seconds": number | null,
    "max_test_requests": number | null
  },
- "fallback_routing": {
    "recommended_fallback": string | null,
    "reason": string | null
  },
- "rationale": "A concise explanation of the decision, referencing specific thresholds and failure counts.",
- "risk_assessment": "LOW" | "MEDIUM" | "HIGH"

# CONSTRAINTS
- Do not invent failure data. Only use the provided inputs.
- If the circuit is CLOSED and failure count is below the threshold, allow the request.
- If the circuit is OPEN and the cooldown period has not elapsed, block the request and recommend a fallback.
- If the circuit is OPEN and the cooldown period has elapsed, transition to HALF_OPEN.
- If the circuit is HALF_OPEN and a test request fails, immediately transition back to OPEN.

To adapt this template, replace each square-bracket placeholder with live data from your circuit breaker state store. The [FAILURE_DETAILS] placeholder should be populated with a structured list of recent errors, including timestamps and error codes, to give the model enough context to distinguish between transient and systemic failures. The [FALLBACK_PATHS] placeholder should contain a list of available alternative agents or static responses, each with a capability description, so the model can make an informed routing decision. Before deploying, run this prompt against a golden dataset of known circuit state transitions to calibrate the [FAILURE_THRESHOLD] and [COOLDOWN_PERIOD] values against your specific agent reliability targets.

The circuit breaker prompt is not a standalone decision engine. It must be embedded in an application harness that maintains persistent state for failure counts, cooldown windows, and circuit state transitions. The harness is responsible for calling the prompt only when a state evaluation is needed, feeding it the current counters and timestamps, and then applying the model's decision to update the circuit state. Without this harness, the prompt has no memory of prior failures and cannot enforce cooldown periods across invocations.

Implement the harness as a state machine with three states: CLOSED (normal operation), OPEN (circuit tripped, requests blocked), and HALF_OPEN (probing for recovery). Store failure_count, last_failure_time, last_open_time, and cooldown_seconds in a durable store such as Redis, a database, or an in-memory cache with persistence. Before each agent action, check the current state. If CLOSED, proceed normally and increment the failure counter on errors. When failure_count exceeds a configured threshold, invoke the prompt with [FAILURE_COUNT], [THRESHOLD], [FAILURE_WINDOW_SECONDS], and [RECENT_FAILURE_DETAILS] to get a structured decision. Parse the output against a strict schema requiring circuit_state, cooldown_recommendation_seconds, fallback_routing, and rationale. Validate that circuit_state is one of the allowed enum values and that cooldown_recommendation_seconds is a positive integer within your operational bounds (e.g., 30–3600 seconds). If validation fails, default to OPEN with a conservative cooldown and log the parse error.

For the HALF_OPEN state, allow a single probe request through after the cooldown expires. If the probe succeeds, transition back to CLOSED and reset the failure counter. If it fails, return to OPEN and double the cooldown duration up to a configured maximum. Log every state transition, the prompt's raw output, the validated decision, and the probe outcome. This audit trail is essential for tuning thresholds and diagnosing false-positive trips. Wire the fallback_routing field into your agent dispatcher so that when the circuit is OPEN, requests are automatically routed to the specified fallback agent, queue, or human review inbox. Never silently drop requests when the circuit is open—always route to a fallback or return a clear 503 with a Retry-After header.

Model choice matters here. Use a fast, instruction-following model (e.g., Claude 3.5 Haiku, GPT-4o-mini) because circuit breaker decisions are latency-sensitive and the reasoning is bounded. Avoid models that over-explain or hallucinate state transitions. Set temperature=0 to get deterministic decisions. Implement a timeout of 2–5 seconds for the prompt call. If the model times out or returns an unparseable response, treat it as a circuit trip: transition to OPEN with a default cooldown and log the model failure as a separate incident. This prevents the circuit breaker itself from becoming a reliability risk.

Before deploying, test the full harness with a suite of scenarios: rapid successive failures, recovery probes that succeed, recovery probes that fail, cooldown expiry edge cases, and model timeout injection. Measure the end-to-end latency added by the circuit breaker evaluation and ensure it stays under your p95 target. Monitor circuit_trip_rate, false_positive_trip_rate (trips where the fallback succeeded immediately), and model_eval_timeout_rate in production. When tuning thresholds, adjust [FAILURE_THRESHOLD] and [FAILURE_WINDOW_SECONDS] based on observed error patterns rather than guessing. Start conservative and loosen only after reviewing trip audit logs.