A circuit breaker in electrical engineering does one thing: when current exceeds a safe threshold, it opens the circuit and stops the flow. The house doesn't burn down because the breaker trips first.
In distributed systems, the circuit breaker pattern does the same thing for service calls. When a downstream service is failing — returning errors, timing out, or responding slowly — you stop sending it requests rather than queuing up failures. The caller gets a fast fail. The failing service gets breathing room to recover.
In agentic systems, the same problem appears in a different form: what happens when a sub-agent or tool provider fails? Without a circuit breaker, the orchestrator keeps calling the failing component, accumulating errors, burning token budget, and potentially degrading the quality of the entire workflow.
Why Agents Need Circuit Breakers
In a microservices architecture, a circuit breaker trips after N consecutive failures. In an agent system, the equivalent is more nuanced.
Agent workflows are often long-running and stateful. A sub-agent failure at step four of twelve doesn't just affect step four — it affects every downstream step that depended on step four's output. The orchestrator has three options: retry indefinitely (expensive and often futile), halt the entire workflow (costly for the work already done), or invoke a fallback path.
The circuit breaker pattern for agents makes the third option explicit rather than accidental.
The Three States
A circuit breaker for agent sub-calls has the same three states as in distributed systems:
Closed (normal operation). Calls pass through to the sub-agent or tool. Failures are counted. If failures exceed the threshold within the window, the breaker opens.
Open (failing fast). Calls to this sub-agent are immediately returned as failures without attempting the call. The orchestrator receives a fast fail and can route to a fallback path. The breaker stays open for a cooldown period.
Half-open (testing recovery). After the cooldown period, a limited number of calls are allowed through to test whether the sub-agent has recovered. If they succeed, the breaker closes. If they fail, it opens again with a longer cooldown.
What Constitutes a Failure in Agent Context
This is where agent circuit breakers differ from their distributed systems counterparts. A microservice failure is binary — the HTTP call either succeeds or fails. An agent sub-call can fail in several ways:
Hard failures: The tool throws an exception. The API returns a 5xx. The model call times out. The sub-agent returns a malformed response that the orchestrator cannot parse.
Soft failures: The sub-agent returns a response, but the response quality is below threshold. The orchestrator's validator rejects the output. The sub-agent completes but reports low confidence. The output contradicts a known constraint.
Hard failures are easier to detect. Soft failures require the orchestrator to have quality validation logic — and the quality threshold must be defined before the circuit breaker can use it. For most production systems, start by handling hard failures and add soft failure detection incrementally as you understand your system's failure modes.
Fallback Paths
A circuit breaker without a fallback is just a faster way to fail. The value of the pattern is in what the orchestrator does when the breaker is open.
Common fallback patterns for agent sub-calls:
Degrade gracefully. Skip the sub-agent's output and proceed with the workflow using the information already gathered. The final output is less complete but still useful. Appropriate when the sub-agent's contribution is enhancement rather than essential.
Route to an alternative provider. If the primary LLM is failing, route to a backup model. If the primary search tool is down, use a different search provider. Multi-provider orchestration is the prerequisite for this pattern.
Cache the last known good result. If the sub-agent is providing stable reference information (a product catalog lookup, a configuration value), serve the cached result while the sub-agent recovers. Appropriate only when staleness is acceptable for the use case.
Escalate to human. For high-stakes workflows where degraded output is worse than no output, open a human-in-the-loop checkpoint when the breaker opens. The workflow pauses rather than proceeding with incomplete information.
Implementation in Practice
Most agent frameworks don't include circuit breaker logic natively. You implement it in the orchestrator layer.
The minimal implementation tracks, per sub-agent or tool:
- Failure count in the current window
- Last failure timestamp
- Current state (closed / open / half-open)
- Cooldown expiry timestamp
Before every sub-agent call, check state. If open, return the fallback immediately. If half-open, allow the call and update state based on the result. If closed, make the call and update the failure counter.
The thresholds — failure count before opening, cooldown duration, number of half-open test calls — should be tuned per sub-agent based on observed failure rates and recovery characteristics. A fast API that occasionally rate-limits needs different settings than a model call that occasionally hallucinates outputs that fail quality validation.
The Observability Requirement
Circuit breakers are only useful if you can see when they're tripping. Log every state transition: when the breaker opens, what triggered it, how long it was open, and whether it closed cleanly or was reset manually. Track breaker trip rate per sub-agent over time.
A sub-agent whose circuit breaker trips frequently is telling you something: either the sub-agent is unreliable and needs to be replaced, or your failure threshold is miscalibrated and is being triggered by normal variance. You cannot distinguish between these without the observability.