Traditional software has familiar reliability metrics.
Uptime. Error rate. Latency. Failed jobs. Queue depth. The classics. They are boring, measurable, and very useful when production decides to become a performance art installation.
AI systems need those metrics too.
They also need something else: an error budget for weirdness.
Because AI systems often fail in ways that are technically successful and operationally ridiculous.
Weird Is a Failure Mode
The request completed. The API returned 200. The job did not crash. The model produced a well-formatted answer with three bullet points and the confident energy of a consultant who has not read the appendix.
And yet the output was wrong.
Not always catastrophically wrong. Sometimes just weird. A summary that missed the important clause. A code review that focused on naming while ignoring a broken permission check. A support draft that was technically polite and emotionally generated by a refrigerator.
If you do not track these failures, they become anecdotes. Anecdotes become Slack complaints. Slack complaints become “AI is not ready” from someone who is not entirely wrong.
Define Weirdness Before Scaling
Teams often start measuring AI systems only after people lose trust.
That is too late.
Before scaling, define the behaviors that count against the weirdness budget. Confident wrong answers. Outputs requiring human rescue. Low-confidence actions that proceeded anyway. Handoffs that lack evidence. Retrieved sources that were stale. Tool calls that were technically allowed but contextually absurd.
The point is not to punish the model for being probabilistic. The point is to make reliability visible.
If weirdness is invisible, leadership sees only speed. Users see only damage.
Track Review Load
One of the most useful AI reliability signals is review load.
How often does a human have to repair the output? How long does review take? Which task types produce the most corrections? Which workflows create reviewer fatigue?
This matters because an AI system can appear productive while quietly moving work from execution to cleanup.
That is not automation. That is outsourcing the mess to the reviewer.
I touched this problem in measuring AI agent ROI: productivity metrics are useless if they ignore rework. Weirdness is rework with better branding.
If humans are constantly rescuing the workflow, the system is not autonomous. It is delegated cleanup.
Stop Scaling When the Budget Burns
An error budget only matters if it changes behavior.
If confident wrong outputs exceed the threshold, stop expanding the workflow. If review load doubles, investigate before adding more users. If mystery handoffs appear, fix evidence logging. If stale retrieval causes bad answers, repair the memory system before pointing the model at more documents.
The worst response is to scale through the warning signs because the demo looked good.
Demos do not have error budgets. Production should.
The Takeaway
AI reliability is not just uptime.
It is whether the system behaves usefully, recoverably, and explainably across the strange edge cases that real users create all day.
Give your AI system an error budget for weirdness.
When the budget burns, do not call it personality. Fix the system.