👋 Hey {{first_name|there}},
The vendor's status page is green. Your dashboards are green. The feature has been quietly useless for six hours, and the only reason you know is that a customer got bored with it and wrote in.
Why this matters
We've spent years on this newsletter, making systems fail well. Circuit breakers so a sick dependency stops taking calls. Bulkheads so one slow thing can't drown the pool. Retry budgets so a blip doesn't turn into a storm. That toolkit works, and it rests on an assumption nobody says out loud: failures announce themselves. Something times out, or throws, or returns a 500, your breaker can count. Then the pattern engages.
An AI feature breaks that assumption twice.
The first way is familiar but mistuned. When the model provider degrades, it usually degrades by getting slower, not by erroring. Your breaker is showing an error rate that never moves. Meanwhile, every request sits there for eleven seconds holding a connection, and the thing you should have been protecting was never the AI feature at all.
The second way has no equivalent in the systems you're used to. The model is up, fast, and wrong. It returns a perfectly formed answer built on nothing, with a 200 and a healthy latency number. There is no error to catch, no signal to count, no breaker to trip. Availability stays at four nines while the feature is, functionally, broken. Your monitoring will tell you it's fine right up until the customer tells you it isn't.
🧭 The shift
From: "What happens when the AI call fails?"
To: "What does the user get when we can't trust the answer, and who decided that?"
The first question has an engineer's answer: catch it, log it, show an error. The second is a product question wearing an architecture costume, and it can't be settled in the code review. Somebody has to decide what the person on the other end is left holding.