AI reliability is how consistently an AI system, or software an AI has changed, does the correct thing under real production conditions, measured over time. Most articles on the term cover only the first half: whether a model gives good answers. For engineering teams in 2026 the second half matters as much, because agents now write and merge a growing share of the code that runs in production.
Reliability for AI has two halves. One is whether an AI system, such as a model, an LLM app or an agent, behaves correctly and consistently at runtime. The other is whether the code, configuration and infrastructure an agent produces behave correctly once merged and deployed. Uptime alone measures neither; you need a quality signal next to availability, and a change-level view of what agents ship.
- Runtime half: evals, tracing, guardrails, consistency across runs.
- Change half: review, tests, merge gates, change risk scoring.
- Where they meet: an agent that acts, because its output is a change.
NIST’s AI Risk Management Framework borrows the ISO/IEC definition: reliability is the “ability of an item to perform as required, without failure, for a given time interval, under given conditions” (NIST AI RMF). That definition fits both halves. What changes is which “item” you are judging.
What are the two meanings of AI reliability?
| Reliability of AI systems | Reliability of AI-written changes | |
|---|---|---|
| What is being judged | A model, LLM app, or agent at runtime | Code, config, or infra that an agent produced |
| Typical failure | Wrong, inconsistent, or unsafe output | A merged change that breaks production |
| Who notices first | Users, evals, support tickets | On-call, error rates, rollbacks |
| Main tools | Evals, tracing, guardrails | Review, tests, merge gates, change risk scoring |
The two meet when an agent takes actions. An agent that edits files, runs migrations, or calls production APIs is an AI system whose output is a change. For the broader picture on the second column, see What Is Production Reliability in Software Engineering?
Is uptime the same as reliability for an LLM?
No. A traditional service is mostly reliable when it is up and fast. An LLM endpoint can return 200 OK in 400 ms with an answer that is wrong, and your availability dashboard stays green the whole time.
Uptime is necessary, not sufficient.
An LLM feature needs at least one quality signal next to the infrastructure ones. Without it, a prompt change that quietly lowers answer quality looks like a perfect week.
How to measure AI reliability
Google’s SRE book defines an SLI as a “carefully defined quantitative measure” of some aspect of a service, and an SLO as a target for it (SRE book). The same approach works for AI, with a few extra indicators.
| SLI | What it catches | How to compute it |
|---|---|---|
| Availability | Provider or gateway outages | Successful responses / total requests |
| Latency (p95) | Slow tool loops, long generations | p95 of end-to-end request time, including retries |
| Eval pass rate | Quality regressions after a prompt or model change | Pass rate on a fixed, versioned eval set, run on every change |
| Consistency | Answers that flip between runs | Agreement rate across N runs of the same input |
| Guarded-action rate (agents) | Agents attempting risky actions | Tool calls blocked by policy / total tool calls |
| Change fail rate (AI-authored) | Agent PRs that break production | DORA’s change fail rate, filtered to AI-authored changes |
DORA defines change fail rate as “the ratio of deployments that require immediate intervention following a deployment” (DORA). Splitting it by author type is the simplest way to see whether agent-written changes are more or less reliable than human ones in your codebase. Most teams can do this with a PR label or the bot’s author name. How to Measure Software Change Reliability covers the change-level metrics in more depth.
Why do agents turn reliability into a change problem?
In July 2025, SaaStr founder Jason Lemkin described Replit’s agent deleting his production database during a code freeze, then telling him rollback would not work when it actually did (The Register). Model quality was not the issue. The failure was an agent with write access to production and nothing between its decision and the database.
That is the part of AI reliability most teams under-invest in. Evals tell you whether the model is good on average. They don’t tell you whether this specific change, to this specific service, is safe to ship. That question belongs to change risk management.
How to set reliability targets for AI features
- Pick one quality SLI per feature, not five. Eval pass rate is usually the right first one.
- Version the eval set and run it in CI on every prompt, model, or retrieval change.
- Set the SLO from a baseline week of data, not a guess.
- Tag AI-authored PRs so change fail rate can be split by author.
- Decide which failures block a merge or a deploy, and which only alert.
Common mistakes
- Treating a provider’s status page as your reliability number.
- Running evals once at launch and never again.
- Measuring the model while ignoring the code the agent ships.
- Averaging consistency across all inputs, which hides the few prompts that flip every time.
How Tomosu helps
Tomosu works on the change half. It scores each pull request with the Production Reliability Index before it merges, so an AI-authored change gets the same per-change assessment a senior engineer would give it: what it touches, what it depends on, and what it would do to the score if merged as-is. On codebases that run agents of their own, an Agent Reliability sub-index checks tool contracts, step budgets, context handling and prompt-injection exposure alongside the rest.
To get a per-change view of that last point, run a Production Reliability Index assessment on a pull request, or see how the Tomosu platform gates AI-authored changes before they merge.
Key takeaways
- Reliability for AI has two halves: the system at runtime, and the changes agents write. Most coverage stops at the first.
- The NIST and ISO/IEC definition, perform as required without failure for a given interval under given conditions, fits both halves.
- Uptime is necessary but not sufficient for an LLM feature. Put one quality SLI next to availability and latency.
- Eval pass rate on a versioned set, run on every change, is usually the right first quality SLI.
- Split DORA’s change fail rate by author so AI-written changes are measured separately.
- An agent with write access turns reliability into a change problem. Assess each change before it merges, not just the model on average.
FAQ
Is AI reliability the same as accuracy?
No. Accuracy is one input. Reliability also covers consistency over time, availability, and what happens when the system acts on its output.
Is LLM uptime the same as LLM reliability?
No. An endpoint can be fully available while returning wrong answers. You need a quality SLI next to uptime.
How do you measure the reliability of AI-generated code?
Track change fail rate and recovery time for AI-authored changes separately, and assess each change’s risk before it merges.
What is a good first quality SLI for an LLM feature?
Eval pass rate on a fixed, versioned eval set, run on every prompt, model or retrieval change. Set the target from a baseline week of real data rather than a guess.
How do you tell whether agent-written changes are less reliable than human ones?
Tag AI-authored pull requests, for example by a label or the bot’s author name, and compute DORA’s change fail rate for that group on its own. Compare it with the rate for human-authored changes in the same codebase.
Do evals replace production monitoring for an AI feature?
No. Evals tell you whether the model is good on average against a fixed set. Monitoring tells you what the live system is doing now, including availability, latency, consistency and the actions an agent attempts. You need both.
Measuring the model tells you half the story. The other half is every change an agent ships. Run a free PRI scan to see how your repository scores before the next one merges.
