A production AI agent ran at 99.4% uptime for a quarter, returned HTTP 200s on every request, and was functionally broken for three weeks — the model had silently regressed when a cheaper variant was swapped in, and the pipeline kept emitting success codes for outputs no human could use. That incident, documented by a reliability engineer who inherited a decade of traditional SRE practice, crystallises why measuring autonomous agent reliability with service-level metrics is operationally meaningless: an agent can be up and broken at the same time.
Why Traditional SRE Metrics Lie
The reason a 200 OK does not mean an agent worked is structural: the agent is not just serving a request — it is making decisions, calling tools, and generating outputs that have to be useful, not merely well-formed. None of that is captured by an HTTP status code, a latency histogram, or a process uptime number. A conventional service has a small, well-understood set of failure modes: the process crashes, the database is unreachable, the deploy was bad, the disk is full. Each has a clear signal and a clear remediation, and tools like Prometheus and PagerDuty solve most of it (Alex Cloudstar, 2026).
An agent inherits all of those failure modes plus a long tail of new ones that never surface as a 500. The model regresses on a class of inputs after a provider-side update. A tool call returns the right shape but the wrong content. The retrieval pipeline pulls a stale document. A prompt template picks up an extra newline that breaks JSON-mode parsing. A schema validator was relaxed during a deploy and now garbage flows downstream. The user phrases a request in a way that hits a known weak spot. Every one of these looks fine to the system and wrong to the user — and a dashboard that only tracks throughput will report a green quarter while customers churn.
The Three-Layer Agent SLO
The reliability target for an agent is not one number. Practitioners who have run agents in production for over two years now converge on at least three stacked layers, tracked separately because they fail independently and demand different remediations (Alex Cloudstar, 2026):
- Service-level reliability — Did the request hit the agent and return a non-error response in reasonable time? This is what existing tooling already covers: HTTP success rate, p95 latency, deploy success rate. Necessary but not sufficient. A conventional target of 99.5% works here.
- Output validity — Did the agent return something conforming to its contract? JSON that parses, tool calls with the right schema, outputs that pass the type check before rendering. A 200 with malformed JSON is not a success. This layer usually needs a tighter target, around 99.9%, because failures surface directly as broken UI.
- Task success — Did the agent actually do what the user wanted? This is the layer that takes real eval work to measure, graded by a human, a verifier program, or another LLM over a sample of production traffic. For serious applications the floor is rarely below 95%.
The reason all three are needed is that they fail independently. A model regression can collapse task success while service-level reliability sits at 100%. A bad deploy can tank service-level reliability while task success is unaffected on the requests that make it through. Track only one and you get a partial view of reality — and partial views are how customers leave while your dashboard glows green.
Splitting Budgets Per Failure Family
The classic SRE error budget assumes failures are independent, attributable, and roughly evenly distributed in time. None of that holds for agents. A model regression after a provider-side update is not independent — it hits every request in the affected class until you switch models. A retrieval-pipeline failure correlates across every user querying the same stale documents. A prompt-template change ships at one instant and affects every request afterward. The error budget burns in spikes, not smooth curves, and the alerting has to reflect that (Alex Cloudstar, 2026).
The pattern that works in 2026 is to assign a separate budget to each failure family, rather than lumping everything into one availability number. One team running autonomous agents on a distributed queue separates four distinct budgets (Cordum, 2026):
| Budget | Target | What burns it |
|---|---|---|
| Reliability | 99.9% over 30d | Execution failures and timeouts only |
| Governance availability | 99.95% over 30d | Policy service unavailable events |
| Latency | p99 dispatch < 1s | Sustained p99 dispatch breaches |
| Replay debt | Near-zero orphan trend | Growing orphan replays and stale job backlog |
The critical insight is that policy denials and reliability failures must never share one budget. When they do, incident reviews become unreadable: you cannot decide whether to freeze releases, tune policies, or add scheduler capacity, because everything is mixed into a single number that tells you nothing actionable.
Alert On Burn Rate, Not Totals
Because agent failures arrive in bursts, total-budget alerting is always late. By the time the cumulative budget is exhausted, the damage is done. The fix is multi-window, multi-burn-rate alerting — the same model Google’s SRE workbook prescribes for conventional services, now adapted to queue-driven agent control planes (Cordum, 2026).
For a 99.9% reliability SLO, two practical paging thresholds emerge. A fast-burn page fires when the failure ratio exceeds 14.4× the budget rate over both a 1-hour and a 5-minute window — meaning something just broke. A second fast-burn page fires at 6× over 6-hour and 30-minute windows. Sustained slow burn at 1× over 3 days and 6 hours opens a ticket rather than waking anyone, because it signals accumulating debt, not an active incident (Cordum, 2026). The rate tells you the story while there is still time to act; the total only explains it afterward.
The Six SLOs, Not One Score
When the three-layer model is fully expanded, a working production agent needs six distinct reliability SLOs — each mapping to a layer that can break in isolation, each with its own error budget and its own fix (Future AGI, 2026):
| SLO | What it measures | Baseline |
|---|---|---|
| Task completion | Trajectory delivered the user goal end-to-end | ≥ 90% |
| Tool-call success | Right tool, schema-valid args, payload used | ≥ 95% |
| Recovery rate | Recovered from a transient tool failure | ≥ 70% |
| p99 latency | Tail latency users actually feel | ≤ 30s chat / ≤ 5min batch |
| Guardrail trip rate | Scanner blocks at the gateway layer | 1–5% of traffic |
| Trace-grounded score | 4-D rubric: grounding, safety, instruction, plan | ≥ 4.0 / 5 per axis |
The case against a single aggregate agent_score is the bisection problem. When a production agent regresses, on-call has to determine which of six or more layers moved: did the planner pick the wrong tool, did the call carry a bad argument, did retrieval surface a stale chunk, did the model flip a number, did a safety filter turn aggressive, did a third-party endpoint start returning 429s? An aggregate of 0.83 answers none of this. Six metrics with six budgets turns a three-day bisect into a single alert that points at the right component.
When Failures Become Plausible Lies
The most dangerous failure class in agent systems does not merely hide — it fabricates. A longitudinal study published in June 2026 documented 22 incidents over eight weeks in a personal-assistant agent runtime: roughly 40 scheduled jobs, 8 LLM providers, a tool-governance proxy, and a knowledge-base memory plane, defended by 4,286 unit tests and 827 governance checks (Wu, 2026, arXiv 2606.14589).
One meta-pattern — a failure whose error signal never reaches a human in actionable form — manifested at least 28 times. The authors derived a five-class taxonomy, and identified Class D, “chained hallucination and fabrication,” as unique to LLM systems and the most dangerous: the system does not just fail to report an error, the model transforms it into fluent, plausible narrative delivered to the user. They term this fail-plausible — gray failure’s differential observability escalated, where the observer is not merely blind but convincingly lied to by the failure itself (Wu, 2026).
Three empirical findings from that study should reframe how agent teams spend engineering time. About 70% of silent failures were caught by human user-view observation, not tests or audits. A retrospective audit of 15 incidents found 0% ex-ante prevention but 87% regression blocking — meaning audits are regression engines, not prediction engines, and they only earn their cost after a failure has already occurred (Wu, 2026). And incident latency, ranging from 13 hours to 60 days, tracked failure mechanism rather than code complexity: the longest-lived failures lived in the seams between components, where no test runs.
Observability That Connects Layers
If 70% of silent failures are found by humans rather than tests, the implication is not to add more tests — it is to make the seams observable. The failure modes that survive longest are the ones that cross boundaries: between the planner and the tool registry, between retrieval and the prompt template, between the model provider and the schema validator. Each boundary is a place where an error can be swallowed, diluted, or rewritten into a plausible answer.
The defense framework that falls out of the longitudinal data is built around three principles. Make failures loud: an agent that returns a confident wrong answer is worse than one that errors out, so the gateway layer must trip and surface a real signal when outputs fall outside validated distributions. Make failures attributable: distributed tracing must connect the user-facing output back through every layer — retrieval chunk, tool call, model invocation, prompt revision — so a regression bisects in minutes, not days. And make failures boring: the goal of an agent SLO program is not zero incidents, it is incidents that are fast to detect, easy to localise, and cheap to regression-test out of existence (Wu, 2026).
What Classic SRE Cannot Fix
Teams that try to retrofit a traditional SRE playbook onto agents ship dashboards that do not match user reality. The legacy assumptions break in specific, predictable ways. Independent failures become correlated bursts. A single availability budget becomes four or six budgets split by failure family. Static percentage alerts become multi-window burn-rate paging. Uptime targets become task-success targets measured by evals, not by probes. And “the service is healthy” becomes a question with at least three different answers depending on which layer you ask.
The analyst signal points the same direction. Gartner’s March 2026 Market Guide for AI Assistants for Infrastructure as Code projects that 90% of IT operations organisations will integrate context-aware AI assistants into their IaC workflows by 2029, up from 5% in 2026 (Gartner, 2026). A 18× adoption curve into infrastructure-critical workflows means the cost of getting agent reliability wrong stops being a churn metric and starts being an outage metric — and the teams that win will be the ones who learned, before the curve hit, that an agent’s 200 OK is not the same thing as its success.
Related Reading
References
- Alex Cloudstar — AI Agent Reliability Engineering 2026: SLOs and Failure Modes
- Cordum — AI Agent SLOs and Error Budgets: Production Policy Playbook (2026)
- Future AGI — AI Agent Reliability Metrics: Six SLOs (2026)
- Wu, W. (2026) — When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime, arXiv 2606.14589
- Gartner (2026) — Market Guide for AI Assistants for Infrastructure as Code