Circuit Breaker Half-Open Probing Prompt

This prompt is for platform reliability engineers and SREs who need to safely test if a downstream tool or service dependency has recovered after repeated failures. It is designed to be used by an agent or automated workflow when a circuit breaker transitions from OPEN to HALF-OPEN state. The prompt instructs the model to act as a recovery testing planner, producing a structured, safe, and representative probe plan. It forces explicit reasoning about probe safety (read-only vs. mutating), request selection, success criteria, and automatic rollback conditions. Use this when you need a programmatically consumable probe plan that can be reviewed by a human or executed by a controlled test harness.

The ideal user is an SRE or platform engineer embedding AI-assisted decision-making into an operational toolchain. The required context includes the circuit breaker's configuration (failure threshold, timeout window, half-open max requests), the recent failure history that caused the circuit to open, the tool's API specification, and the current state of any fallback mechanisms. The prompt does not make the routing decision itself; it produces a plan that your application code must execute. This separation is critical—the model proposes a recovery test strategy, but your harness enforces safety constraints, executes probes, and evaluates results against the defined success criteria.

Do not use this prompt for real-time request routing decisions or for generating the circuit breaker logic itself. It is not a replacement for deterministic circuit breaker libraries like resilience4j, Polly, or Istio circuit breaking. It is also unsuitable when you lack a clear API contract for the downstream tool, when probe safety cannot be guaranteed by the execution harness, or when the half-open state must be resolved in sub-second latency. The prompt's value is in producing a reasoned, auditable probe plan for complex recovery scenarios where simple health checks are insufficient. After using this prompt, always route the output through a human review step if the probes involve mutating operations, and ensure your execution harness strictly enforces the probe limit and automatic rollback conditions defined in the plan.

This prompt template instructs an agent to act as a reliability controller for a tool dependency that has just transitioned from an open to a half-open circuit breaker state. The agent's job is not to blindly resume traffic but to design a safe, measurable probing strategy. The prompt forces the agent to select a representative sample of requests, define explicit success criteria, and pre-commit to rollback actions if the probe fails. Use this template as the system prompt for an agent that has access to a tool execution harness and a circuit breaker state store.

textCopy
You are a circuit breaker recovery controller for an AI agent platform. Your task is to generate a controlled probe plan for a tool that has just entered the half-open state.

## INPUTS
- Tool Name: [TOOL_NAME]
- Failure History (last [TIMEFRAME]): [FAILURE_SUMMARY]
- Circuit Breaker Configuration: failure_threshold=[FAILURE_THRESHOLD], success_threshold=[SUCCESS_THRESHOLD], timeout_ms=[TIMEOUT_MS]
- Pending Request Queue (sample): [PENDING_REQUESTS_SAMPLE]
- Tool Dependency Graph: [DEPENDENCY_GRAPH]

## CONSTRAINTS
- Do not propose probing with all pending requests. Select a maximum of [MAX_PROBE_COUNT] probe requests.
- Probe requests must be representative of distinct call patterns, not just the simplest ones.
- If the tool is idempotent, prefer read-only or safe-write probes. If non-idempotent, flag the risk explicitly.
- The probe plan must include a rollback or abort condition for each probe request.
- Do not propose a probe if the failure history indicates a systemic outage that a half-open test cannot validate (e.g., a known dead backend). In that case, recommend remaining open.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "probe_plan": {
    "recommendation": "PROCEED_WITH_PROBES" | "REMAIN_OPEN" | "ESCALATE_TO_MANUAL",
    "rationale": "string",
    "selected_probes": [
      {
        "request_id": "string",
        "request_summary": "string",
        "call_pattern_category": "string",
        "is_idempotent": true | false,
        "risk_flag": "NONE" | "NON_IDEMPOTENT" | "HIGH_COST" | "DATA_MUTATION",
        "success_criteria": {
          "max_latency_ms": number,
          "expected_response_schema": "string",
          "required_fields": ["string"]
        },
        "rollback_or_abort_action": "string"
      }
    ],
    "global_abort_conditions": ["string"],
    "probe_timeout_ms": number
  }
}

## INSTRUCTIONS
1. Analyze the failure history to determine if the failure pattern is transient (timeout, rate limit) or systemic (connection refused, invalid config).
2. If systemic, recommend REMAIN_OPEN or ESCALATE_TO_MANUAL and do not select probes.
3. If transient, select up to [MAX_PROBE_COUNT] probe requests from the pending queue that represent different call patterns.
4. For each probe, define concrete, measurable success criteria. Do not use vague terms like "works normally."
5. Define global abort conditions that, if triggered, should immediately transition the circuit breaker back to open.
6. Set a probe timeout that is shorter than the standard request timeout to prevent the half-open state from blocking the queue.

Adaptation guidance: Replace the square-bracket placeholders with values from your circuit breaker configuration store and request queue. The [DEPENDENCY_GRAPH] placeholder should be populated with a structured representation of which tools depend on the failing tool, so the agent can assess blast radius. If your agent does not have access to a live request queue, replace [PENDING_REQUESTS_SAMPLE] with a static set of representative request types. For high-risk production systems, add a [HUMAN_APPROVAL_REQUIRED] boolean flag that routes the probe plan to a review queue before execution.

This prompt is not a standalone chatbot interaction. It is a decision component inside a circuit breaker controller that manages tool call resilience. The controller maintains state (open, closed, half-open) and invokes this prompt only when transitioning into or operating within the half-open state. The prompt's job is to produce a structured probe plan—selecting which requests to allow through, defining success criteria, and specifying rollback conditions—that the controller then executes against the live tool dependency.

Wire the prompt into a state machine with explicit guardrails. Before calling the prompt, assemble the [TOOL_HEALTH_METRICS] payload from your observability stack: failure counts by error type over the last window, latency percentiles (p50, p95, p99), the current circuit state, the duration spent in the open state, and the configured probe limit. The controller should enforce a maximum probe count regardless of what the prompt suggests—this is a safety bound, not a suggestion. After receiving the probe plan, validate each proposed probe request against a safelist of read-only or idempotent operations. Reject any probe that would trigger a write, a charge, or a state mutation. Log the full prompt input, output, and validation result as a structured audit event before executing a single probe.

Implement a tight retry-and-escalation loop around probe execution. For each probe the plan authorizes, execute it with a short timeout (shorter than your standard tool timeout) and capture the result. Feed the aggregated probe outcomes back into the circuit breaker state machine: if the success rate meets the threshold defined in the prompt's output, transition to closed; if any probe fails, immediately transition back to open and increment the failure count. Do not give the prompt authority to override the circuit state directly—the controller owns state transitions. The prompt advises; the controller decides. If the prompt output fails schema validation or proposes unsafe probes, abort the half-open attempt, log the failure, and remain open. Escalate to on-call if three consecutive half-open attempts fail before a single probe succeeds.

Model choice matters here. Use a model with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or near-zero—this is a deterministic decision point, not a creative task. Enable structured output mode with a strict JSON schema matching the expected probe plan format. If your model provider doesn't support structured output natively, implement a post-generation validation step that parses the response, validates against the schema, and retries once on failure with the validation error included in the retry prompt. After two consecutive parse failures, abort and log the raw response for debugging.

Observability is non-negotiable. Every invocation of this prompt must emit: a trace span with the prompt input, output, and latency; a metric increment for the circuit state transition attempt; and a structured log line containing the probe plan, execution results, and final state decision. These artifacts are your primary debugging surface when a circuit breaker misbehaves in production. Without them, you cannot distinguish between a prompt that gave bad advice and a controller that executed probes incorrectly. Wire these logs into your existing incident response dashboards so on-call engineers can see circuit breaker decisions alongside tool health metrics during an outage.