> ../patterns/a2a_circuit_breaker.md
§ 01 · The assumption that just broke
Retry logic, timeouts, circuit breakers, the standard reliability toolkit, was designed around calling APIs with predictable failure modes. A 429 means slow down. A 500 means try again later. A timeout means the service is overloaded. None of that logic accounts for what happens when the thing you're calling is itself an agent: something that can fail slowly and confidently, returning a well-formed, plausible-looking wrong answer instead of an error code.
── The wrong signal ──
§ 02 · Why a standard circuit breaker doesn't catch this
A circuit breaker trips on error rate or latency. An agent-to-agent call that returns a confident, malformed, or subtly wrong result looks like a success to every metric a standard circuit breaker watches. The call didn't fail. It just didn't do what you needed, and your circuit breaker has no way to know that, because it's watching the wrong signal.
── The pattern ──
§ 03 · The pattern
Add a second failure category, quality failure, that trips independently of the standard error-rate breaker.
1. Validate the shape before you trust the content. Every response from an external agent gets checked against an expected schema before anything downstream touches it. This catches a large share of quality failures cheaply, before you need any semantic judgment at all.
2. Sample for semantic drift, don't just check the schema. Periodically, not on every call, that's too expensive, run a known-good test case through the external agent and compare the result against an expected answer. A schema-valid response that's drifted away from correct won't trip a shape check, but it will trip this.
3. Trip the breaker on quality failures, not just errors. When validation or sampling detects a bad result, treat it exactly like a 500 for circuit-breaker purposes, back off, fall back, or fail safe. Don't let "technically returned a 200" override "the content was wrong."
4. Never let one agent's failure silently propagate as another agent's fact. If agent A returns a low-confidence or failed-validation result, agent B should receive that as a flagged, uncertain input, not as ground truth to build the next decision on. Multi-agent systems that skip this step are how a false consensus forms: several agents individually operating "correctly" on a bad input none of them flagged.
5. Keep a fallback that doesn't depend on the failing agent. A cached last-known-good result, a simpler deterministic rule, or a human escalation, anything other than "retry the same agent and hope."
── Where it compounds ──
§ 04 · Where this matters most
The risk compounds with every additional agent in the chain. A single agent-to-agent call with a quality circuit breaker is a safety net. A four-agent pipeline where only the last hop validates anything is a system where an early, unflagged error gets progressively more confident-looking at each stage, exactly the failure mode we've seen in production multi-agent deployments that reach a wrong answer with more certainty than any single agent in the chain actually earned.
── Checklist ──
§ 05 · Checklist
[ ] Does every agent-to-agent call validate response shape before use?
[ ] Do you sample for semantic correctness, not just schema validity?
[ ] Does a quality failure trip your circuit breaker the same way an error code does?
[ ] Does a low-confidence result from one agent get passed downstream as uncertain, not as fact?
[ ] Is there a fallback path that doesn't depend on the same agent that just failed?
── End of pattern ──
◆ If your circuit breaker only watches HTTP status codes, it's blind to the failure mode that actually costs you in a multi-agent system.
ORBIRESEARCH