Circuit Breaker Activation Prompt for Failing Dependencies

This prompt is a control-plane component for an agent runtime or orchestration layer. Its job is to protect downstream services from cascading retry storms by making a structured, machine-readable decision to open, close, or keep a circuit breaker in its current state. It is not designed for end users or natural-language explanation. The ideal user is an AI engineer or agent infrastructure developer integrating this prompt into an execution loop that monitors tool call outcomes. The prompt must be invoked before every call to a dependency that has recently failed, using a sliding window of recent outcomes, latency metrics, and error classifications as input. The required context includes a failure rate threshold, a latency degradation threshold, a cooldown duration, and a list of error types that should be treated as immediate triggers for opening the breaker.

Use this prompt when your agent's tool-calling layer needs a fast, deterministic signal to prevent resource exhaustion on a known-fragile dependency. It is appropriate for production systems where a single degraded API can cause a cascade of retries across multiple agent instances, consuming token budgets and violating latency SLAs. Do not use this prompt for one-off debugging, for dependencies that have no history of failure, or as a replacement for client-side SDK retry policies. It is a state machine decision prompt, not a diagnostic tool. The output is a strict state change instruction (e.g., OPEN, CLOSE, HOLD) with a cooldown duration and a fallback mode, which your application code must enforce. If you need a human-readable summary of why a circuit breaker tripped, pair this prompt with a separate error context collection or human handoff prompt.

Before integrating this prompt, ensure your agent runtime tracks the necessary inputs: a rolling window of call outcomes (success/failure with error types), p50/p95/p99 latency for recent calls, and the current breaker state with its opened_at timestamp. The prompt is designed to be stateless; all state is passed in via the input context. After receiving the output, your application layer is responsible for enforcing the decision—blocking calls, routing to a fallback, or resetting the breaker after the cooldown. Do not rely on the model to remember the breaker state across invocations. For high-risk dependencies where an incorrect decision could cause data loss or a critical outage, always log the full input and output of this prompt and consider a human-in-the-loop approval step before opening a breaker on a previously healthy service.

This prompt template is designed to be injected into your agent's pre-call guard or a dedicated circuit breaker evaluation step. It receives a structured snapshot of recent dependency call outcomes, the current breaker state, and your configured thresholds. The model's job is not to execute the breaker logic in application code—that should be handled deterministically—but to reason about edge cases where simple threshold comparisons are insufficient, such as when failures are clustered, error types vary in severity, or partial degradation suggests a different response than pure failure counting.

textCopy
You are a circuit breaker evaluator for an agent infrastructure system. Your role is to analyze recent dependency call history and recommend a breaker state transition based on configured thresholds and failure patterns.

## Current State
- Breaker State: [CURRENT_STATE]
- Consecutive Successes: [CONSECUTIVE_SUCCESSES]
- Cooldown Start Time: [COOLDOWN_START_TIME]
- Current Time: [CURRENT_TIME]

## Failure History (most recent first)
[FAILURE_HISTORY]

Each record includes:
- timestamp
- error_type (TIMEOUT, CONNECTION_REFUSED, RATE_LIMITED, INTERNAL_ERROR, INVALID_RESPONSE, UNKNOWN)
- latency_ms
- retry_attempted (true/false)

## Threshold Configuration
- Failure Rate Threshold (sliding window): [FAILURE_RATE_THRESHOLD]%
- Minimum Requests in Window: [MIN_REQUESTS]
- Consecutive Failure Threshold: [CONSECUTIVE_FAILURE_THRESHOLD]
- Latency Degradation Threshold: [LATENCY_DEGRADATION_THRESHOLD]%
- Cooldown Duration Seconds: [COOLDOWN_DURATION]
- Half-Open Max Requests: [HALF_OPEN_MAX_REQUESTS]
- Error Type Weights: [ERROR_TYPE_WEIGHTS]

## Evaluation Rules
1. If state is CLOSED and failure rate exceeds threshold with minimum requests met, recommend OPEN.
2. If state is CLOSED and consecutive failures exceed threshold, recommend OPEN.
3. If state is CLOSED and average latency exceeds baseline by degradation threshold, recommend OPEN.
4. If state is OPEN and cooldown duration has elapsed, recommend HALF_OPEN.
5. If state is HALF_OPEN and any request fails, recommend OPEN.
6. If state is HALF_OPEN and all requests in probe succeed, recommend CLOSED.
7. Weight error types by severity: TIMEOUT and CONNECTION_REFUSED indicate infrastructure failure; RATE_LIMITED may indicate self-inflicted load; INVALID_RESPONSE may indicate upstream changes.
8. Consider failure clustering: if failures are concentrated in a short burst followed by recovery, this may indicate a transient spike rather than persistent degradation.

## Output Schema
Return a JSON object with:
{
  "recommended_state": "CLOSED" | "OPEN" | "HALF_OPEN",
  "confidence": 0.0-1.0,
  "reasoning": "Brief explanation of the decision",
  "cooldown_seconds": 0 if not opening, otherwise suggested cooldown,
  "fallback_mode": "NONE" | "CACHED_RESPONSE" | "STALE_DATA" | "DEGRADED_FUNCTIONALITY" | "ERROR_RESPONSE",
  "risk_flags": ["List of any risk factors identified"],
  "override_rule": null or "String describing which rule triggered if standard thresholds were bypassed"
}

## Constraints
- Do not recommend OPEN if minimum requests haven't been met.
- Do not recommend CLOSED from HALF_OPEN unless all probe requests succeeded.
- If error types are predominantly RATE_LIMITED, consider whether the breaker itself is causing retry storms.
- Flag for human review if the pattern doesn't clearly fit threshold rules.

Analyze the failure history and current state, then return your recommendation.

To adapt this template for your system, replace the square-bracket placeholders with actual values from your circuit breaker state store and metrics collector. The [FAILURE_HISTORY] should be formatted as a JSON array of failure records. The [ERROR_TYPE_WEIGHTS] placeholder should contain a mapping of error types to numeric weights that reflect your system's severity hierarchy. Before deploying, validate that the model's output conforms to the schema using a JSON validator in your harness, and implement a hard guard that rejects any recommendation violating the explicit constraints—the model's reasoning informs the decision, but your application code must enforce the safety boundaries. For high-risk dependencies where an incorrect breaker state could cause data loss or user-facing outages, route CLOSED-to-OPEN transitions through a human approval queue before execution.

The circuit breaker activation prompt is not a standalone decision-maker. It is a gating step inside an agent's execution loop that runs before every outbound call to a protected dependency. The prompt receives aggregated failure statistics from the last monitoring window and returns a structured breaker state change. The surrounding harness is responsible for collecting those statistics, enforcing the prompt's decision, and preventing the model from overriding breaker logic with unsafe defaults.

Wire this prompt into your agent runtime by placing it after the failure counter update and before the next outbound call attempt. The harness must supply the prompt with real metrics: [FAILURE_COUNT], [TOTAL_CALLS], [WINDOW_DURATION_SECONDS], [ERROR_TYPES] (categorized as timeout, connection_refused, 5xx, 4xx, malformed_response), [CURRENT_BREAKER_STATE] (closed, half_open, open), [LAST_FAILURE_TIMESTAMP], and [LATENCY_P95_MS]. The prompt outputs a JSON decision with fields action (open, close, remain, half_open), cooldown_seconds, fallback_mode (stale_cache, degraded_response, skip_step, escalate), and reasoning. Validate this output before acting on it. Reject any decision where action is open but cooldown_seconds is zero or missing, where action is close while the error rate exceeds the configured threshold, or where the model invents error types not present in the input. These validation rules must live in application code, not in the prompt, because the model cannot be trusted to enforce its own safety constraints.

For production deployments, implement a hard-coded circuit breaker as the primary enforcement layer and use this prompt only for threshold tuning and exception handling. The application should maintain breaker state in a durable store (Redis, Postgres, or in-memory for single-process agents) with atomic state transitions. The prompt's role is to recommend state changes when the situation is ambiguous—for example, when error rates hover near the threshold, when error types suggest different recovery strategies, or when latency degradation indicates a degrading but not yet failed dependency. Never let the prompt's output bypass the hard-coded maximum cooldown cap (e.g., 300 seconds) or the minimum call volume required before opening (e.g., 5 calls in the window). Log every prompt invocation with input metrics, output decision, validation result, and the final action taken by the harness. This trace is essential for tuning thresholds and detecting prompt drift over time.

Model choice matters here. Use a fast, cheap model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) because this prompt runs on the critical path of every dependency call during degraded states. Latency added by the prompt must be a fraction of the dependency's own timeout. If the prompt call itself fails or times out, the harness must default to the safest breaker state—typically leaving the breaker in its current position or moving to open if the error rate already exceeds a hard threshold. Never default to close on prompt failure. For agents with strict latency budgets, consider pre-computing breaker decisions from a rules engine and invoking the prompt only when the rules engine returns an ambiguous result.

Before shipping, test this harness against simulated failure patterns: rapid-fire timeouts, slow degradation over 60 seconds, intermittent 5xx errors mixed with successes, and complete dependency disappearance. Verify that the combined prompt-plus-harness system opens the breaker within your target detection window, rejects calls during the cooldown period, transitions to half_open correctly, and closes only after sustained health. The most common production failure is a breaker that never opens because the prompt overweights recent successes or a breaker that never closes because the prompt fixates on a single error spike. Your eval suite should include both cases.