SLOs & Error Budgets for Agents

Correctness fails all three tests an SLI has to pass.

A service level indicator is a ratio of good events to valid events that you can compute, cheaply, from telemetry, in near real time. Classic SRE indicators qualify trivially — a 200 is good, a 503 is bad, and nothing has to interpret them. "The agent answered correctly" fails on each count, and the failures are structural rather than a tooling gap you can close.

• There is no label. In production nobody knows the right answer; that is why the user asked. Offline evals have labels because you constructed them, which is exactly what makes them an offline instrument.
• The proxy is a model with its own error rate. An LLM judge scoring live traffic gives you a number, and that number moves when the judge model changes, when prompt distribution shifts, or when the judge is itself fooled by fluency. An SLI whose measurement apparatus drifts independently of the system it measures cannot carry a budget. LLM-as-judge is useful and it is not instrumentation.
• The latency is wrong by an order of magnitude. Human adjudication or downstream outcome confirmation arrives in days. Burn-rate alerting assumes you learn about consumption within minutes. A budget you can only reconcile retrospectively is an accounting exercise, not an operational control.
• The denominator is not stable either. "Valid events" for an agent includes requests it should have refused, requests that were ambiguous, and requests where the user changed their mind mid-task. Classic SLIs get a clean denominator for free; agents do not, and an objective computed over a drifting denominator moves for reasons that have nothing to do with the agent.

Split the indicators into three tiers and give only the first one a budget.

The useful reframing is that you do not have one quality signal with a measurement problem — you have three different kinds of signal with different latencies, different trustworthiness and different jobs. Treat them differently and each becomes usable.

• Tier 1, mechanical. Deterministic, computed from traces, available in seconds: request availability, end-to-end latency at the tail, task completion rate (the loop terminated with a result rather than a step-limit, timeout, unhandled tool error or refusal-to-proceed), tool call error rate, retry rate, and cost per task against its ceiling. These behave exactly like classic SLIs. They get real objectives and a real error budget.
• Tier 2, proxy. Fast, cheap, correlated with quality but not quality: user retry within the session, edit distance between the agent's output and what the user shipped, abandonment before completion, escalation to a human, and thumbs-down rate. Minutes of latency, noisy, directionally honest. These get alert thresholds tuned for change, not absolute levels, because their baseline is meaningless in isolation.
• Tier 3, adjudicated. Sampled traffic scored by a judge or a human, and where it exists, the confirmed downstream outcome — the booking that held, the ticket that did not reopen, the refund that was not disputed. Days of latency, small n, high trust. These belong on a weekly control chart and in your release gate, never on a pager.
• Publish all three, and label the tier next to every number. Half the organisational damage from agent metrics comes from a tier-3 number being read as if it were tier 1. Putting "sampled, n=200, 3-day lag" beside the figure is a one-line fix that survives every reorg.

The mechanical tier is stronger than teams expect. Task completion rate in particular catches a large share of real degradation — a model change that makes the agent loop until the step limit, a tool schema drift that produces a run of errors, a prompt edit that makes it refuse a common request — all of which show up in seconds, deterministically, with no judge involved.

Derive the objective from what the consumer needs, and count "unknown" as a failure.

An objective set by picking a round number is a number nobody defends at three in the morning. Set it from the downstream contract, then write down what happens when it is missed — that second half is what makes it an SLO rather than a dashboard.

• Ask what the consumer does when the agent fails. If a failed run silently falls back to a human queue with spare capacity, your availability objective can be modest. If a failed run means an abandoned checkout, it cannot. The objective is a property of the workflow the agent sits in, not of the agent.
• Set latency objectives at the tail and per task class. A single p95 across a mixed workload is dominated by whichever class is most common that week. Agents have genuinely multi-modal latency — a one-tool lookup and a twelve-step research run are different services sharing an endpoint — so either split the objective by class or accept that the number means nothing.
• Count "completed but unverifiable" against you. If the agent finished and no downstream artefact confirms the effect, that is not a success, it is an unknown. Systems that book, write or pay have a queryable outcome and no excuse; treating unknowns as passes is how a broken write path stays green for a fortnight. This is the same discipline as verifying the outcome rather than the trajectory.
• Give refusals their own objective, in both directions. Refusal rate rising is a degradation; refusal rate falling can be a safety regression. Neither is visible in a completion metric that counts a refusal as a clean termination, so measure it separately and state a target band rather than a ceiling.
• Put cost per task in the SLO set, not just in the finance review. An agent whose token spend per task doubled is broken in a way that availability will never show, and it is one of the few agent failures with a direct linear cost. Pair the objective with the fail-closed ceiling from loop-level cost control.

Run a second budget for harm, because a perfectly available agent can still be doing damage.

This is the part with no analogue in classic SRE, and it is the reason importing the SRE playbook unmodified leaves a hole. A web service that is up is, by and large, not hurting you. An agent that is up is taking actions, and the actions are the product. Availability and harm are close to independent axes, so they need separate budgets.

• Define the harm events concretely, per action type. A write that was reverted. A message sent to the wrong recipient. A refund issued outside policy. A ticket closed that reopened within a day. An escalation that should have happened and did not. These are countable, they have an owner, and they are the events your leadership actually fears.
• Budget them as a rate against actions taken, not against requests served. An agent that doubles its action volume at a constant error rate has doubled the harm, and a request-denominated metric will report it as flat. The denominator has to be the thing that can hurt someone.
• Weight by reversibility rather than by frequency. Three reverted drafts and one irreversible external payment are not the same incident. Keep at least two classes — recoverable and not — with different budgets, and let the irreversible class have a budget close to zero. Reversibility is what buys you the room to run an agent at all.
• Harm budget exhaustion reduces autonomy; it does not necessarily stop the service. This is the most useful property of the second budget. When it burns, the correct response is usually to move the affected action class behind human approval, or to narrow the tool scope, while the agent keeps serving everything else. That is a graduated control the availability budget cannot express.
• Feed every harm event back as a regression test. The event already contains the trace, the inputs and the wrong outcome. An incident that does not become a test case will recur, and incident response for agents exists mostly to make that loop mandatory.

Alert on burn rate for tier 1, on change detection for tier 2, and never on tier 3.

Standard multi-window burn-rate alerting works unmodified on the mechanical tier, and works badly or not at all on everything else. Matching the alerting mechanism to the signal's latency is most of what separates a page that means something from a rota that stops reading them.

• Tier 1 gets multi-window burn rate. A fast window to catch an outage and a slow one to catch a steady drip, with the fast alert requiring the slow one to agree before it pages. Nothing about agents changes this.
• Tier 2 gets change detection, not thresholds. "Retry rate is 8%" means nothing; "retry rate moved from 4% to 8% and stayed there for two hours" means something. Use a rolling baseline and a shift test, which is exactly the machinery quality regression detection builds — and remember every tier-2 signal is confounded by traffic mix, so always segment before you believe a move.
• Tier 3 gates releases and never pages. A judged score with a three-day lag cannot inform an on-call decision, and putting it on a pager teaches the rota to ignore alerts. Its job is the promotion gate in rollout and versioning and the weekly review.
• Alert on the input distribution too. A shift in what users are asking is a leading indicator that arrives before any quality signal, and it explains a large fraction of moves that would otherwise be misdiagnosed as model regressions. Cheap to compute from traces, and it makes the segmentation above possible.
• Every alert names the version triple. Model, prompt, tool schema. Without it, the first twenty minutes of every incident is spent establishing what changed, and for agents the answer is frequently "nothing of ours" — a provider changed underneath you.

An error budget only exists if spending it changes what you are allowed to ship.

The budget is not a measurement, it is a pre-negotiated decision. Written before the incident, when nobody is under pressure and no release is at stake, it converts an argument into a lookup. Skip this step and you have built a very careful dashboard.

• Write the policy as a table of consequences, and get it agreed by whoever can overrule it. Budget healthy: ship, widen autonomy, raise limits. Budget half spent: releases require an eval gate and a canary. Budget exhausted: freeze behaviour changes, roll back to the last known-good triple, and the next work item is reliability.
• Give the agent a rollback target that is a pinned triple, not a git commit. Behaviour is (model, prompt, tools) together; rolling back your code while the provider silently upgraded the model underneath restores nothing. This is why the pinning discipline is a prerequisite for having an SLO at all.
• Make autonomy the first lever, ahead of a full stop. Between "running normally" and "kill switch" there is a wide band: narrower tool scope, human approval on the risky action class, lower step limits, a cheaper fallback path. Design these as configuration flips so the on-call can reach for them without a deploy — the same gradations feature flags for agents exist to provide.
• Budget the planned spend, and actually spend it. A budget that is never consumed means the objective is too loose or the team is too cautious; both are worth knowing. Deliberate experiments — a new model in canary, a widened scope — are what the budget is for.
• Review the objectives quarterly against reality. Agent workloads change shape faster than classic services because the tasks people bring grow with their confidence. An objective set against last quarter's traffic mix is measuring a service you no longer run.

Related: tracing and observability for the telemetry all of this is computed from, incident response and runaway containment for what happens when a budget burns fast, and agent observability for the ground floor.