SLOs for AI Agents: Error Budgets for Nondeterminism

Key Takeaways

• There is no canonical framework for putting an AI agent on an error budget. A November 2025 paper states it directly: "currently there is no formalism to support the definition of SLAs for AI agents." Among the observability vendors we checked, none budgets the agent's correctness. The handful that use SLO language apply it to latency, cost, and judge-derived quality scores, not to whether the conclusion was right. Nobl9 puts it bluntly: "No lab publishes an agent SLO with a numeric target. No lab commits to an error budget."
• The industry is writing about AI doing SRE, not SRE for AI. Google's own AI in SRE paper is about agents running operations, and mentions SLOs only twice, never as a target for the agent itself.
• The closest thing to official guidance is one Google Cloud page. The AI and ML perspective on reliability in Google's Well-Architected Framework connects SLOs and error-budget burn rate to AI workloads, but stops at "consider adopting SRE practices to implement SLOs" without naming agent-specific SLIs.
• Your SLI cannot be "did it answer." It has to be "was it right, and could it prove it." OpenRCA 2.0 found agents name a correct service 76.0% of the time but ground it in a verified causal path only 61.5% of the time. An availability SLO would score both as success.
• The same input legitimately produces different output, and not for the reason most people think. Thinking Machines Lab showed the primary cause is that batch size varies with load, so "from the perspective of an individual user, the other concurrent users are not an 'input' to the system." Your reproduction can fail because traffic changed.
• OpenTelemetry has not standardised this yet. The GenAI semantic conventions are marked Development with zero releases, so anything you build now is ahead of the spec.
• The starter SLO set below is partly our synthesis, and we label which parts. Nobody should present this area as settled practice, because it is not.

An SLO for an AI agent is a reliability target set on the agent's decisions rather than its uptime: whether its conclusions were correct, whether it grounded them in evidence, whether it escalated when it should have, and what it cost. Classic availability and latency SLIs still apply, and they will tell you almost nothing about whether the agent is doing its job. This post assembles what actually exists, is candid about the large gaps, and proposes a starter set with each line traced to a source or flagged as ours.

Does anyone publish SLOs for AI agents?

Almost nobody, and the pattern of who stays silent is informative.

We checked eleven observability and LLM-ops vendors. The results:

What we looked for	What we found
Error budgets on the agent being correct	None. Dynatrace budgets "performance and cost control", Chronosphere ties alerts to burn rate, and Honeycomb's SLI is call-and-parse success. None budgets answer quality.
SLO language applied to LLM or agent behavior	A handful. Dynatrace is the furthest along, alerting on "quality score regressions using workflow engine, SLOs".
Paging on agent quality with no SLO abstraction	At least two: LangSmith and Arize AX, both routing evaluation regressions to PagerDuty.

The striking part is the near-silence from the vendors best equipped to speak. Datadog, New Relic and Grafana all sell mature SLO and on-call products, and on their AI pages that vocabulary largely disappears: Grafana's agent-observability evaluation guide sets a judge pass-rate threshold with no SLO wrapper, and New Relic offers tracing and user feedback in its place. Dynatrace is the exception, and the only vendor we found putting an SLO on a judge-derived quality score. Microsoft's Well-Architected guidance for AI workloads covers reliability only as a pillar table inside its design-principles article, with no mention of SLOs, error budgets or on-call, and has no agent-specific article at all.

The academic position is blunter. AgentSLA (Jouneaux and Cabot, November 2025) states that "currently there is no formalism to support the definition of SLAs for AI agents," and the paper never mentions SRE, error budgets or on-call.

And the practitioner who named the gap most precisely is Lorin Hochstein, writing in February 2026 about the surge of AI SRE tooling: "what none of these tools try to do, as far as I can tell, is incident management."

So this is not a solved problem with poor documentation. It is an open problem. Treat anything below, including our own proposal, accordingly.

Why don't normal SLOs work on an agent?

Four reasons, each with a different consequence for how you measure.

The output is not stable, and the reason is unintuitive. The common explanation for LLM nondeterminism is floating-point non-associativity under concurrency. Thinking Machines Lab showed that is incomplete: "running the same matrix multiplication on the same data repeatedly will always provide bitwise equal results." The actual driver is that "the primary reason nearly all LLM inference endpoints are nondeterministic is that the load (and thus batch-size) nondeterministically varies." Their framing has a sharp operational edge: "from the perspective of an individual user, the other concurrent users are not an 'input' to the system but rather a nondeterministic property."

Consequence: your postmortem repro can fail because other people's traffic changed. Any SLI defined on a single run is noise. You need distributions across repeated runs.

The failure is silent. Anthropic's postmortem of three infrastructure bugs that degraded output quality contains the sentence every SRE should internalise: "The evaluations we ran simply didn't capture the degradation users were reporting, in part because Claude often recovers well from isolated mistakes." Error rate did not move. Latency did not move. Quality did.

Consequence: an availability SLO will read green through a quality outage.

Being right is not one thing. OpenRCA 2.0's separation of naming from grounding is the cleanest demonstration: 76.0% versus 61.5% on identical runs. A binary correct/incorrect SLI collapses a 14.5-point distinction that is the whole difference between a useful agent and a confident one.

Confidently wrong costs more than silent. Parasuraman and Manzey's review in Human Factors found automation bias "cannot be prevented by training or instructions" and affects experts as much as novices. So a wrong answer that your responder acts on is not one unit of badness like a failed request. It is worse than no answer, which means your SLI needs to weight it that way.

What can you actually measure?

Here is the candidate SLI catalogue, sorted by how hard each is to instrument today. This is the practical core of the post.

Tier 1: measurable today, from telemetry you already have.

SLI	Definition	Why it works now
Tool-call success rate	Non-error tool invocations / total	Ordinary instrumentation
Investigation completion rate	Runs reaching a conclusion / runs started	Needs only a terminal-state marker
Time to first useful hypothesis	Start to first conclusion a human can act on	Wall-clock, though "useful" needs a human label
Escalation rate	Runs handed to a human / total runs	Requires an explicit escalation path
Cost per investigation	Token and query spend per run	Aurora persists this per LLM call and rolls it up per incident
Runaway rate	Runs exceeding a step, time or token ceiling	Aurora's defaults: 240 graph steps (~120 reasoning turns), 600s per sub-agent, 2 synthesis waves maximum

Cost belongs in your SLO set, not in a finance dashboard. Two independent 2026 evaluations, SREGym and Artificial Analysis, found that spending more does not buy accuracy, so an agent whose cost per investigation is climbing is usually degrading, not improving.

Tier 2: needs an evaluation harness you have to build.

SLI	Definition	What it requires
Diagnostic precision	Correct conclusions / conclusions offered	Labelled ground truth from resolved incidents
Groundedness	Conclusions with a reviewer-accepted evidence chain	Reasoning logs plus human or judge review
Confidently-wrong rate	Wrong conclusions asserted with high confidence	A confidence or strength label must be captured per finding
Abstention correctness	Cases where "inconclusive" was the right call	Ground truth on the genuinely ambiguous set
Reliability across repeats	Success across k repeated runs of the same case	Repeated execution, which costs k times as much

The last one matters more than it looks. Because output varies run to run, a single-run pass rate overstates reliability. Measuring success across repeated attempts is the honest version, and both ITBench-AA (3 repeats per task) and SREGym build it in.

Tier 3: research problems. Do not put an SLO on these yet.

Calibration, meaning whether stated confidence tracks actual correctness, is not something you can currently trust. Nor is trustworthy self-reported reasoning: Anthropic's own research found that models frequently do not verbalise what actually drove an answer, with one model mentioning an influential hint 25% of the time and another 39%. Detecting silent capability drift after a provider-side model change is likewise unsolved. Treat all three as monitoring signals to eyeball, not targets to defend.

Is OpenTelemetry going to standardise this?

Not yet, and you should know that before you build on it.

The GenAI semantic conventions are marked Development across the board, the dedicated repository has zero releases and zero tags, with well over a hundred open issues against it. There is now a dedicated MCP semantic convention with metrics like mcp.client.operation.duration and mcp.server.session.duration, which is a genuine step forward, and a GenAI special interest group with a weekly agent track.

The practical read: instrument now, but expect attribute names to change. Do not let a spec that has not shipped a release become the reason you have no measurement at all.

What do the official frameworks say?

Three sources are worth reading, and it is worth being precise about what each does and does not cover.

Google Cloud's Well-Architected Framework, AI and ML perspective on reliability is the only major-cloud document that connects SLOs and error-budget burn rate to AI workloads. Its recommendation is to "consider adopting SRE practices to implement SLOs." That is the right instinct and it stops short of naming agent-specific SLIs, so it gives you the frame without the contents.

Google's SRE organisation on AI in SRE is about agents performing operations rather than reliability targets for agents, and mentions SLOs only twice, never as a target for the agent itself. What it does provide is the best published governance model for agents in production: the L0 to L4 autonomy ladder, automatic downgrade from L3 to L2 when "the agent detects an elevated risk score or an anomalous production state," and "emergency 'Red Button' endpoints that allow SREs to instantly pause all in-flight agentic actions." It also states a requirement that doubles as your instrumentation mandate: agents "must log their 'chain of thought', the signals used, the hypotheses considered, the reasons for choosing a particular action, and the confidence level." Without that log, every Tier 2 SLI above is unmeasurable.

Google's SRE team's published principles also include the requirement that "SRE AI agents need to provide a high level of reliability SLOs and have well-defined backup options (automated or manual)," which is the clearest statement from a credible source that this work needs doing, without specifying how.

A starter SLO set

What follows is a proposal. The SLI definitions draw on the sources above; the specific targets are ours and are not established practice. Nobody has published validated targets for this, so treat these as a starting point to argue with, and set your own from your own baseline.

Assume an investigation agent running at Google's L1, offering suggestions with a human approving all actions.

SLI	Proposed target (Arvo's proposal, not established practice)	Window	Why this shape
Investigation completion rate	99%	28 days	Infrastructure reliability, not answer quality. Ordinary SLO.
Tool-call success rate	99.5%	28 days	A broken integration is a plain outage.
Confidently-wrong rate	< 2%	28 days	The one that protects your responders. Tightest budget of the set.
Groundedness	>= 80% of offered conclusions	90 days	Well above the 61.5% frontier benchmarks report, so expect to miss it at first and tighten from your own baseline. Needs review, so a longer window.
Abstention correctness	>= 90%	90 days	Rewards saying "inconclusive" instead of guessing.
p95 time to first hypothesis	< 10 minutes	28 days	Beat a human opening six tabs, or there is no point.
p99 cost per investigation	< 3x median	28 days	Catches runaway loops. Published eval data shows worst-case per-run costs more than an order of magnitude above the average.

Three deliberate choices worth explaining.

The confidently-wrong budget is the tightest, not availability. A 2% budget on 500 investigations a month allows ten confidently wrong conclusions. Given that automation bias cannot be trained away, that is already generous.

Groundedness gets a 90-day window, and an uncomfortable target. 80% sits well above the 61.5% that frontier models manage on OpenRCA 2.0, so most teams will miss it initially. That is deliberate: it is the number worth engineering toward, not the number you will hit in month one. It also needs human review, so a 28-day window on a small sample is mostly noise.

Nothing here is an autonomy SLO. At L1 the agent proposes and a human acts, so there is no unattended-action budget to spend. If you promote to L2 or L3, add SLIs for approval-gate compliance and unauthorised-action attempts, and pair them with the Red Button before you turn it on.

What breaks these SLOs in practice

Four failure modes to plan for, each documented.

A provider changes the model under you. Anthropic's deprecation policy warns that "Deprecated models are likely to be less reliable than active models" and retired models' requests "will fail." Partner platforms like Bedrock and Vertex "set their own retirement schedules," so identical code can be live on one cloud and dead on another. Treat model ID and prompt as versioned config with independent rollback, and re-baseline your SLIs on every model change. A model swap is a release.

Infrastructure degrades quality with no error signal. Anthropic's three-bug postmortem is the case study, including a context-window routing error that, at its worst hour, affected 16% of Sonnet 4 requests on the Claude API. Their fixes are the right lessons: more sensitive evaluations, and running quality evaluations "continuously on true production systems."

The agent burns budget instead of finishing. Over-investigation both costs money and produces false positives, per Artificial Analysis: "Models that over-investigate tend to surface upstream fault-injection mechanisms or co-occurring symptoms as false positives." Hard ceilings are the control. Aurora's are 240 graph steps (roughly 120 reasoning turns), 600 seconds per sub-agent, and a maximum of two synthesis waves; the specific numbers matter less than having them.

Your evaluation set goes stale. An agent tuned against last quarter's incidents will look excellent and help nobody. Google's approach is stratified sampling with tiered label quality, where Gold is "Verified by human experts," refreshed continuously as SREs accept or reject suggestions in their normal workflow.

Where we are honest about Aurora

Aurora instruments every Tier 1 SLI in this post: per-call token, latency and cost persisted and rolled up per investigation, a full per-tool execution timeline, hard step and time ceilings, and schema-validated findings: a finding missing its "what I ruled out" section or a valid strength label from a fixed set (strong, moderate, weak, inconclusive) is sent back for a retry, and after two failures is replaced with a failure stub rather than persisted as-is. A sub-agent that times out returns an honest stub marked timeout, with its strength recorded as inconclusive and no evidence claimed. That is the raw material Tier 2 needs.

What Aurora does not have is the harness that turns that material into a score. There is no golden dataset in the repository, no baseline, no scored run history for investigation quality. So we can hand you the telemetry and the labels; we cannot hand you our groundedness number, because we have not built the thing that computes it. We would rather say that than publish one.

The short version

Availability SLOs on an agent measure the wrong thing and will read green through a quality outage. The measurable set today is completion, tool success, escalation rate, time to first hypothesis, cost, and runaway rate. The set worth building toward is precision, groundedness, confidently-wrong rate, abstention correctness, and reliability across repeats. Calibration and drift detection are still research.

And the number to defend hardest is not uptime. It is how often the agent is confidently wrong, because that is the one your on-call engineer cannot defend themselves against.

Start collecting Tier 1 today

Every Tier 1 SLI needs the agent to emit per-call telemetry and honour hard ceilings. Aurora does both out of the box:

git clone https://github.com/arvo-ai/aurora.git && cd aurora

make init                # generates secrets and local config
nano .env                # add OPENROUTER_API_KEY, OPENAI_API_KEY or ANTHROPIC_API_KEY
make prod-prebuilt       # pulls prebuilt images and starts

Open http://localhost:3000 and register as admin. The runaway ceiling is a documented setting you can raise or lower, and the per-sub-agent timeout and synthesis-wave cap are fixed limits rather than advisory targets:

AGENT_RECURSION_LIMIT=240      # ~120 reasoning turns before the run is cut off

If cost per investigation is the SLI you are defending first, two settings move it materially:

RCA_OPTIMIZE_COSTS=true        # routes background RCA to a cheaper model
VISUALIZATION_ENABLED=false    # skips the LLM extraction behind the infra graph

The hosted version tracks the same per-investigation cost and tool-timeline data if you would rather not stand up Postgres, Memgraph and Weaviate to get a baseline.

• Start free: aurora-ai.net (hosted, no infrastructure to run)
• GitHub: github.com/Arvo-AI/aurora
• Related guides: AI SRE Accuracy: What the Benchmarks Show · What Does an AI Investigation Cost? · AI Agent Guardrails · Who Is Accountable When an AI Agent Changes Prod?

Sourcing note. SLI definitions and all quoted material link to primary sources: Google Cloud Well-Architected, Google SRE, Anthropic engineering and research, peer-reviewed human-factors research, and the arXiv papers cited. The proposed targets in the starter table are Arvo's synthesis, not established practice, and are labelled as such. Verified July 28, 2026.