Fail Fast, Recover Smart

[joshua-temple]

The Proposal

Design AI systems for failure, not just success. Every component that calls a model should know what it does when the model is wrong, slow, or unavailable, before it ships. Failure handling is part of the design, not an ops afterthought.

Why This Matters

Traditional software fails loudly and deterministically: exceptions, error codes, stack traces. AI systems fail silently and probabilistically. A confident wrong answer looks exactly like a right one: no exception fires, no test goes red.

• Silent failures compound: bad output feeds downstream steps, and by the time a human notices, the cause is buried.
• Costs fail open: a retry loop against an LLM burns real dollars per iteration, not just CPU.
• Trust is the product: one confidently wrong answer shown to a user costs more than an honest "I can't do that."

Systems that fail fast and recover deliberately keep failures cheap, visible, and survivable.

AI-Specific Failure Modes

• Confident wrong or harmful output (no error raised)
• Refusal of a valid request
• Context window overflow and silent truncation
• Rate limits and provider outages
• Latency spikes and timeouts
• Runaway cost from loops and retries

Fail Fast

• Validate inputs and preconditions before the expensive call
• Set hard timeouts and per-request / per-session budgets
• Check intermediate outputs against schemas or invariants; abort on violation
• Cap retries; never retry an un-retriable failure

Recover Smart

• Define an explicit fallback hierarchy: cheaper model, then cached response, then static default, then honest error
• Prefer partial results with a clear caveat over nothing
• Retry with backoff only on transient failures (429s, timeouts), never on refusals or bad output
• Surface errors humans can act on: what failed, what was tried, what to do next

Open Questions

1. Failure taxonomy: which failure classes do we standardize, and which are retriable vs terminal? (e.g., 429 gets backoff and retry; a refusal is never retried)
2. Budgets: what default timeout and cost ceiling does a single agent task get, and who can override them?
3. Fallback hierarchy: for each production workload, what is the ordered fallback chain, and where is it declared: code, config, or platform?
4. Detecting the silent failure: how do we catch the confident-wrong-answer case: evals, canaries, output validation, user feedback loops?
5. Acceptable failure rates: per use case, what error or refusal rate triggers rollback or escalation?

[joshua-temple]

Accepted. Documented in #13.