Circuit Breaker State Verification Prompt

This prompt is designed for resilience engineers, SREs, and agent operators who need to programmatically verify the health of circuit breakers protecting downstream services before an agent executes a call. The core job-to-be-done is preventing wasted work: an agent should not attempt to call a service whose circuit breaker is already open, as this guarantees a failure, consumes resources, and can trigger cascading timeouts. The ideal user is someone integrating this check into an agent's precondition validation step, typically within a workflow engine, an agent harness, or a service mesh sidecar. You must already be collecting structured circuit breaker state data—such as failure counts, success counts, cooldown timestamps, and current state (CLOSED, OPEN, HALF_OPEN)—from your resilience library (e.g., Polly, Resilience4j, Hystrix), API gateway, or service mesh control plane. The prompt assumes this raw data is available and can be formatted as a structured input, such as a JSON object, for the model to interpret.

Concretely, use this prompt when you need a human-readable, structured summary of breaker state that an agent can reason about to decide its next action. For example, if a payment processing agent is about to call a fraud detection service, the harness should first run this prompt with the fraud service's breaker metrics. The output will tell the agent whether the circuit is open, how many failures have accumulated, when the cooldown period ends, and whether a half-open probe is advisable. This allows the agent to choose a fallback path—such as using a cached risk score or escalating for manual review—instead of failing mid-transaction. The prompt is also valuable for generating a pre-flight dashboard or log entry that gives operators visibility into why an agent chose a degraded path. However, do not use this prompt as a real-time circuit breaker itself; it does not make tripping decisions. It is a verification and summarization tool for an existing breaker mechanism, not a replacement for one. It is also not a substitute for a metrics dashboard or alerting system; its value is in providing an agent with a structured, contextualized state report at decision time.

Before implementing this prompt, ensure you have a reliable data pipeline that feeds breaker state into the prompt's [CIRCUIT_BREAKER_STATE] placeholder. The data must be fresh—stale state can cause the agent to attempt calls against a newly opened circuit or skip a service that has already recovered. If your breaker implementation does not expose a cooldown timestamp or half-open state, you should adapt the prompt template to remove those fields rather than providing null values, as the model may hallucinate a recovery timeline. Finally, recognize that this prompt is a single step in a larger resilience strategy. It should be paired with a fallback action selector prompt and a post-call result recorder to close the loop. If your agent operates in an environment where circuit breaker state changes faster than your data refresh interval, you should augment this prompt with a direct health-check probe instead of relying solely on the reported state.

This prompt template is designed to be pasted directly into your agent's system instructions or a dedicated verification task step. It forces the model to act as a deterministic resilience checker, not a conversational assistant. The model's job is to ingest raw breaker metrics, apply explicit threshold rules, and produce a structured state summary. It must not invent metrics, guess at cooldown timers, or recommend actions without evidence from the provided [BREAKER_METRICS] payload.

codeCopy
You are a circuit breaker state verification agent. Your sole task is to analyze the provided breaker metrics and return a structured state report. Do not perform any other action, call any tool, or generate conversational text.

## INPUT
Analyze the following circuit breaker metrics payload:
[BREAKER_METRICS]

## CONSTRAINTS
- Classify each breaker's state as CLOSED, OPEN, or HALF_OPEN based *only* on the provided failure count, threshold, and cooldown fields.
- If a breaker is OPEN, calculate the remaining cooldown seconds as (cooldown_period_seconds - seconds_since_last_failure). If this value is negative, treat it as 0.
- If a breaker is HALF_OPEN, flag it as requiring a probe attempt before full recovery.
- Do not infer state from breaker names or downstream service names.
- If any required field (failure_count, threshold, cooldown_period_seconds, last_failure_timestamp) is missing for a breaker, flag its state as UNKNOWN and include a `missing_fields` list in the output.

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "overall_status": "ALL_CLOSED" | "DEGRADED" | "OPEN_CIRCUIT",
  "breakers": [
    {
      "name": "string",
      "state": "CLOSED" | "OPEN" | "HALF_OPEN" | "UNKNOWN",
      "failure_count": number,
      "threshold": number,
      "cooldown_remaining_seconds": number | null,
      "probe_recommended": boolean,
      "missing_fields": ["string"] | null
    }
  ],
  "fallback_available": boolean,
  "summary": "A one-sentence operational summary of the overall breaker state."
}

## EXAMPLES
Input: {"breaker": "payment-api", "failure_count": 5, "threshold": 10, "cooldown_period_seconds": 60, "last_failure_timestamp": "2024-01-01T00:00:00Z"}
Output state: CLOSED

Input: {"breaker": "inventory-db", "failure_count": 12, "threshold": 10, "cooldown_period_seconds": 120, "last_failure_timestamp": "2024-01-01T00:00:30Z"}
Output state: OPEN (calculate remaining cooldown)

Input: {"breaker": "shipping-svc", "failure_count": 0, "threshold": 5, "cooldown_period_seconds": 30, "last_failure_timestamp": null}
Output state: HALF_OPEN (probe recommended)

To adapt this prompt, replace [BREAKER_METRICS] with a JSON object containing an array of breaker status objects collected from your metrics aggregator (e.g., Polly, Hystrix dashboard, or a custom collector). Ensure the timestamp fields are in ISO 8601 format for consistent parsing. The fallback_available field in the output schema should be populated by your application harness based on static configuration, not by the model, but including it in the schema ensures the model's output structure is ready for that value. If your system uses different state names or threshold logic, update the CONSTRAINTS and EXAMPLES sections accordingly before deploying.

The Circuit Breaker State Verification Prompt is not a standalone utility; it is a precondition gate that must be wired into the agent's execution harness before any downstream service call is attempted. The harness should invoke this prompt as part of a PreFlightCheck sequence, passing the target service name, the breaker's current state snapshot (from your resilience library, e.g., Polly, resilience4j, or a custom state store), and the planned action's criticality. The model's structured output—a breaker state summary with failure counts, cooldown status, and fallback availability—is then parsed by the harness to make a binary decision: proceed, wait, or fallback. Do not rely on the model's recommendation alone; the harness must enforce the decision programmatically to prevent a hallucinated "proceed" from bypassing an actually open breaker.

To integrate this into a production agent, implement a validation layer that parses the model's JSON output and cross-references it against the authoritative breaker state from your infrastructure. For example, if the model reports "state": "closed" but your circuit breaker library reports IsOpen == true, the harness must discard the model's output, log a STATE_MISMATCH error, and default to the safe path (abort or fallback). The harness should also enforce a retry policy with backoff for half-open probing: if the model recommends a probe, the harness issues a single trial request with a tight timeout, and on failure, immediately re-opens the breaker and increments the failure count. Log every decision—breaker state input, model output, harness override, and final action—into a structured audit trail for post-incident review. For high-risk services (payments, PII access, destructive operations), require a human approval step before the harness executes a fallback that could degrade the user experience or skip a critical step.

When wiring this into an agent framework like LangChain, CrewAI, or a custom orchestrator, treat the prompt as a tool with a required pre-check contract. The tool's function signature should accept service_name, breaker_state_snapshot, and action_criticality, and return a typed BreakerDecision object. The orchestrator's planning loop should call this tool before every gated action, not just at the start of the plan, because breaker states can change mid-execution. Avoid the common mistake of caching the breaker decision for the entire agent run; instead, re-verify before each distinct downstream call. If the model's output fails schema validation after a configurable number of retries, the harness must escalate to the on-call channel and halt the agent to prevent silent failures in production.