Agent Tool Circuit Breaker Test Prompt

This prompt is for reliability engineers and AI platform operators who need to verify that an agent's circuit breaker logic works before a production incident forces the issue. The job-to-be-done is generating a structured test plan that exercises circuit breaker thresholds—error rates, latency spikes, and resource exhaustion—and defines the expected open-circuit behavior, half-open probing, and recovery criteria. You use this when you have a tool contract, a known degradation profile, and a circuit breaker configuration (thresholds, windows, recovery parameters) that needs systematic validation. The prompt produces a test specification, not a runtime implementation.

The ideal user brings three concrete inputs: a tool contract or API specification, the circuit breaker configuration (error threshold percentage, latency ceiling in milliseconds, evaluation window size, half-open probe limit, and cooldown period), and the agent's expected behavior contract (what the agent should do when the circuit opens—fallback to a secondary tool, return cached results, escalate to a human, or abort with a structured error). Without these inputs, the prompt will generate plausible but untethered scenarios that won't match your actual system. The prompt assumes you already have a circuit breaker implementation in place; it tests the configuration and agent response, not the breaker library itself.

Do not use this prompt when you need runtime circuit breaker monitoring, when you're designing the circuit breaker configuration from scratch without an existing agent behavior contract, or when the tool under test has irreversible side effects that can't be safely exercised in a test environment. This prompt generates test plans for pre-production validation. For production observability of circuit breaker state, use the Agent Tool Observability Log Generation Prompt Template instead. For designing degradation behavior before you have a circuit breaker, start with the Agent Tool Graceful Degradation Test Prompt. If the tool under test mutates production data, customer state, or financial records, you must pair this prompt's output with a mocked or sandboxed execution environment and require human review of the test plan before execution.

This prompt template generates a structured test plan for validating that an agent's circuit breaker correctly opens, half-opens, and closes in response to tool degradation. It takes a tool contract, failure thresholds, and recovery parameters as inputs and produces executable test scenarios with pass/fail criteria. Use this before deploying any agent that depends on external tools where latency spikes, error bursts, or resource exhaustion could cascade into system-wide failure.

textCopy
You are a reliability test engineer designing circuit breaker validation scenarios for an AI agent that calls external tools. Your output must be a structured test plan that exercises the circuit breaker's open, half-open, and closed states under controlled failure conditions.

## INPUTS
- Tool Contract: [TOOL_CONTRACT]
- Circuit Breaker Configuration: [CIRCUIT_BREAKER_CONFIG]
- Failure Thresholds: [FAILURE_THRESHOLDS]
- Recovery Parameters: [RECOVERY_PARAMETERS]
- Agent Behavior Specification: [AGENT_BEHAVIOR_SPEC]

## CIRCUIT BREAKER CONFIGURATION
[CIRCUIT_BREAKER_CONFIG] includes:
- error_threshold_percentage: the error rate that triggers the open state
- latency_threshold_ms: the maximum acceptable latency before a call is counted as degraded
- window_size_seconds: the sliding window for error rate calculation
- open_state_duration_seconds: how long the circuit stays open before transitioning to half-open
- half_open_max_requests: the number of probe requests allowed in half-open state
- success_threshold_for_close: the number of consecutive successes required to close the circuit

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "test_plan_id": "string",
  "circuit_breaker_under_test": "string",
  "test_scenarios": [
    {
      "scenario_id": "string",
      "scenario_name": "string",
      "trigger_condition": "string describing how to induce the failure",
      "failure_injection": {
        "method": "timeout | error_code | latency_spike | resource_exhaustion | malformed_response",
        "parameters": {},
        "duration_seconds": number
      },
      "expected_circuit_state_transition": {
        "from_state": "closed | open | half_open",
        "to_state": "closed | open | half_open",
        "transition_trigger": "string"
      },
      "expected_agent_behavior": "string describing what the agent should do",
      "pass_criteria": ["string"],
      "fail_criteria": ["string"],
      "recovery_verification": {
        "probe_expected": true,
        "probe_count": number,
        "expected_probe_outcome": "string"
      }
    }
  ],
  "edge_cases": [
    {
      "case_id": "string",
      "description": "string",
      "expected_behavior": "string",
      "risk_level": "low | medium | high"
    }
  ],
  "test_execution_order": ["scenario_id"],
  "cleanup_instructions": "string"
}

## CONSTRAINTS
- Generate at least one scenario for each circuit state transition: closed-to-open, open-to-half-open, half-open-to-closed, and half-open-back-to-open.
- Include scenarios for threshold boundary conditions: error rate exactly at threshold, latency exactly at threshold, and one request below threshold.
- Include at least one scenario where the circuit breaker should NOT open despite elevated errors within the window.
- Every scenario must include explicit pass/fail criteria that can be evaluated automatically.
- Do not generate scenarios that require destructive actions against production systems.
- All failure injection methods must be safe for test environments.
- Recovery verification must include probe request expectations.

## EXAMPLES
Example failure injection methods:
- "timeout": configure the mock to delay response beyond latency_threshold_ms
- "error_code": configure the mock to return 503 for a specified percentage of requests
- "latency_spike": configure the mock to add progressive delay across requests
- "resource_exhaustion": configure the mock to return 429 rate limit responses

## RISK LEVEL
[RISK_LEVEL] is [high | medium | low]. If high, add a human_review_required flag to each scenario and include escalation criteria.

Generate the complete test plan now.

Adaptation guidance: Replace [TOOL_CONTRACT] with the full OpenAPI spec, MCP tool definition, or function schema for the tool under test. [CIRCUIT_BREAKER_CONFIG] should contain the actual threshold values from your resilience configuration—do not use defaults. [FAILURE_THRESHOLDS] can be a subset of the circuit breaker config if you want to test specific boundary conditions. [RECOVERY_PARAMETERS] should include your half-open probe strategy and any cooldown periods. [AGENT_BEHAVIOR_SPEC] should describe what the agent is expected to do when the circuit is open: fallback to a cached response, escalate to a human, use a degraded alternative tool, or abort the workflow. Set [RISK_LEVEL] to high for tools that affect financial transactions, patient data, or infrastructure changes—this will add human review gates to every scenario. For lower-risk tools, medium or low will produce scenarios suitable for fully automated CI pipelines.

After copying the template, validate that your circuit breaker configuration values are consistent with the failure injection parameters you can actually produce in your test harness. A common mistake is defining thresholds that your mocking infrastructure cannot simulate precisely—for example, sub-millisecond latency thresholds when your mock framework only supports whole-millisecond resolution. Adjust either the thresholds or the injection method before generating scenarios. Run the generated test plan through your existing eval framework and flag any scenario where the pass/fail criteria cannot be evaluated programmatically; those scenarios need manual review criteria added.

This prompt is designed to be called programmatically as part of a pre-deployment reliability gate or a scheduled chaos engineering run. It should not be used as a one-off chat interaction. The harness must supply a structured tool contract, known failure thresholds, and the expected recovery policy. The prompt returns a test plan—a set of scenarios—that your test runner then executes against the actual agent and tool infrastructure. The prompt does not execute tests; it generates the specification for them.

Wire the prompt into a test orchestration pipeline (e.g., a CI/CD stage or a reliability workflow in Temporal, Airflow, or a custom test harness). The caller must provide: [TOOL_CONTRACT] (the full tool schema, description, and endpoint metadata), [CIRCUIT_BREAKER_CONFIG] (error rate threshold, latency p95 threshold, concurrency limit, half-open probe count, recovery timeout), and [DEGRADED_BEHAVIOR_POLICY] (the expected agent fallback: use stale cache, escalate to human, skip tool, or abort). The output is a JSON array of test scenarios. Validate the output before execution: each scenario must have a unique scenario_id, a trigger block (how to induce the failure), an expected_circuit_state (open, half-open, closed), and assertions (specific agent behaviors to check). Reject any scenario that lacks these fields or that proposes destructive actions against production endpoints. Use a strict JSON schema validator in your harness.

For model choice, prefer Claude 3.5 Sonnet or GPT-4o for their strong instruction-following on structured generation tasks. Avoid smaller models (e.g., GPT-3.5, Claude Haiku) for this prompt because they tend to conflate test scenario structure or omit required assertion fields. Set temperature=0.1 to minimize creative drift in scenario design. Implement a retry wrapper with up to 2 attempts if the output fails JSON schema validation; on the second retry, append the validation error to the prompt as [PREVIOUS_VALIDATION_ERROR]. Log every generated test plan to your observability stack (e.g., a tool_circuit_breaker_test_generation span) with the prompt version, model, input config hash, and validation pass/fail status. This trace is essential for debugging when generated scenarios are too permissive or miss failure modes.

Do not run the generated test scenarios directly against production tool endpoints without a safety review. The prompt may suggest latency injection or error simulation that requires a mocking layer (e.g., WireMock, a service mesh fault injection rule, or a dedicated test sandbox). If your tool has irreversible side effects (writes, sends, deletes), the test harness must route all generated scenarios through a read-only mock or a shadow endpoint. For high-risk tools, insert a human approval step: the generated test plan is reviewed by an on-call reliability engineer before the harness executes it. The prompt is a planning tool, not an autonomous test executor.