Agent Circuit Breakers
When should an agent stop calling a failing dependency?
Reference notes by Min · Reviewed October 15, 2026
Definition
A circuit breaker temporarily blocks calls to a dependency after defined failure conditions occur. In an agent workflow, it prevents repeated tool attempts from amplifying an outage while making the unavailable capability explicit to the caller.
Repeated attempts can make a struggling service less able to recover. An agent may interpret failure as a reason to try harder, so dependency protection should not depend on conversational judgment. The workflow needs a distinct result for temporarily unavailable capability.
What it covers
- Failure signal
- Which errors indicate dependency trouble.
- State
- Whether calls are allowed, blocked or being probed.
- Isolation
- Which tool or resource the breaker affects.
- Recovery
- How limited traffic establishes readiness.
Choose the isolation boundary deliberately. A single failing tenant should not necessarily block every tenant, while thousands of independent breakers may still overload a shared provider. Match the control to the resource whose capacity or reliability is actually constrained.
In practice
Practical design patterns by Min.
- Separate transient service errors from permission denials.
- Place the breaker outside the model’s control.
- Observe transitions and define a safe unavailable-tool response.
Define failure classes, observation windows and recovery criteria from the workload. Keep those settings reviewable. Test that blocked calls do not consume the same scarce resources as live calls and that the caller does not invent a success result.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Controlled recovery
Azure describes closed, open and half-open states for preventing repeated calls to a failing dependency. Selecting agent-specific thresholds and fallback behavior remains an operating decision.
Source: Microsoft Azure Architecture Center: Circuit Breaker pattern ↗
Working example
A shipping lookup service fails
An agent keeps trying to retrieve shipment status.
- Stop new lookups after the configured failure condition.
- Tell the workflow that status is unavailable.
- Resume through limited probes rather than release every queued request at once.
Why the controls matter
The shipping agent can provide the last known status only if it is clearly dated and suitable for the task. It should not report a current delivery confirmation based on stale data. Recovery probes should avoid consequential side effects.
Common pitfalls
- Letting the agent bypass the breaker through another route.
- Treating a policy denial as a retryable outage.
- Using one global breaker for unrelated customers and services.
A breaker is not a complete incident response mechanism. It does not reverse actions already accepted by a dependency or establish that restored service responses are correct. Reconcile uncertain work separately before resuming normal automation.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which failures open the breaker?
- Can another tool route bypass it?
- How are queued requests handled when service recovers?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- Microsoft Azure Architecture Center: Circuit Breaker pattern ↗Accessed October 15, 2026
- Microsoft Azure Architecture Center: Bulkhead pattern ↗Accessed October 15, 2026