Unavailable is a different problem than overloaded
An agent's best tool can be missing for reasons that have nothing to do with load: a third-party API is down, a permission scope was revoked, a specialist model was deprecated, a rate limit tripped for an unrelated tenant sharing the same key. This is a different failure than the one load shedding solves -- load shedding is about admission control and backpressure under too much traffic; this is about what an agent does when a specific capability it planned to use simply isn't there, at any traffic level.
The naive response -- catch the error, quietly substitute a worse capability, keep going -- is the one that causes the most damage, because it produces a response that looks exactly as confident as one produced by the intended, better capability. This article is about building the fallback chain as an explicit, ranked, disclosed decision rather than a silent exception handler.
The chain has to be designed, not discovered at runtime
A fallback chain is an ordered list, decided ahead of time, of what an agent tries when its first choice for a given capability isn't available: specialist tool, then a more general tool that covers a subset of the same ground, then an explicit request for human input, in that order, for a given capability slot. Discovering the chain at runtime -- catching whatever exception fires and reacting ad hoc -- produces inconsistent behavior across identical failures, because which fallback gets used ends up depending on incidental code paths rather than a considered ranking.
Ranking the chain requires answering one question honestly for each step down: what does this fallback lose relative to the step above it? A specialist code-search tool falling back to a generic grep loses semantic matching but keeps completeness; an agent falling back from a fine-tuned classification model to a general-purpose LLM prompt loses calibrated confidence but keeps rough correctness. Write that cost down per fallback level -- it's the input to the disclosure step later, and skipping it is how a team ends up with a fallback chain nobody can explain the tradeoffs of after the fact.
capability: "extract structured data from this invoice"
chain:
1. specialist-invoice-parser (cost if unavailable: none, best case)
2. general-document-ocr + LLM-extraction
(cost: lower field-level accuracy,
especially on non-standard layouts)
3. ask human to enter manually (cost: latency, but zero silent-error risk)
Why silent fallback is the dangerous default
The core risk isn't that a fallback capability is worse -- sometimes worse-but-available is the right call. The risk is that a response produced by the third-ranked fallback is, on the surface, indistinguishable from one produced by the first-ranked primary, and a user or a downstream system has no signal to treat it with appropriate skepticism. This is the same shape of problem as a system returning stale cached data during an outage without marking it as stale: technically available, silently wrong in a way nothing points at.
Concretely: an agent whose specialist data-extraction tool is down and falls back to a general LLM guess should not return that guess formatted identically to a verified extraction. If the caller (human or another agent in a pipeline) can't tell the two apart, every downstream decision built on that response inherits an invisible confidence gap. This is precisely the failure mode explored from the security angle in confused-deputy attacks -- there the ambiguity is exploited by an attacker; here it's self-inflicted by an agent's own fallback logic, but the underlying problem (a response that doesn't honestly represent its own provenance) is the same shape.