Grafana applies SLOs and error budgets to AI agent behavior

Grafana Labs published a proposal to address a problem that much of the teams who have put AI agents into production still can't quite name: how to measure whether the agent is behaving well, not just whether it's up. In an article covered by InfoQ, the company describes how to use evaluations, SLOs (service-level objectives), and error budgets to turn behaviors like hallucination, task fulfillment, toxicity, and cost into measurable targets over time.

The problem traditional observability doesn't solve

Conventional application metrics tell you whether an agent responded quickly, didn't throw a technical error, and consumed X tokens. None of them tell you whether the response was correct, whether it was grounded in the provided context, or whether it was actually useful to whoever asked. It's the classic gap between "the system is up" and "the system is doing what it should," only now applied to a component that decides, rather than just processes.

Grafana's answer is to evaluate the behavior itself and turn the result of that evaluation into an SLI (service-level indicator), the indicator that then becomes an SLO.

How it works: evaluation, SLI, SLO, and error budget

The first step is evaluation: examining an agent interaction and deciding whether it met a specific behavioral criterion. Grafana cites examples like checking whether the response was grounded in the provided context, whether it fulfilled the user's request, whether it contained toxic content, whether it exposed personal data, or whether it fell victim to a prompt injection attack. These checks can use another language model as a judge (LLM-as-judge) or deterministic methods, such as regular expressions, when the behavior can be identified without needing an LLM.

Here's an important distinction from the temptation to create a single "agent quality score." Grafana argues that quality is multidimensional: an agent can be well-grounded but expensive, useful but occasionally toxic, accurate but slow. Treating these dimensions as separate measurements allows setting different targets for the behaviors that matter in each application, instead of hiding relevant failures inside an average.

Once a behavior can be measured, classic SRE concepts apply directly: you define the SLI, the target (SLO), and the time window, exactly as Grafana's own SLO tool already does for the availability of traditional systems.

A practical example of an SLO for agents

Grafana gives a concrete example: an SLO requiring 95% of conversations to be judged as "fulfilled" over 30 days. The remaining 5% becomes the error budget, the amount of unacceptable behavior the team has explicitly decided to tolerate during that period.

The value of the model lies less in the chosen percentage and more in the decision it enables. With error budget to spare, the team can experiment with prompts, switch models, or adjust the agent's behavior. As the budget gets consumed, priority shifts from experimentation to quality remediation. It's the same logic SRE teams have used for years to balance reliability against the speed of change, only now applied to responses instead of uptime.

The silent degradation a traditional alert doesn't catch

This model becomes particularly useful when agent behavior worsens gradually rather than failing dramatically. A conventional alert detects a sudden spike in failed requests. But an agent can keep responding with technical success while its responses subtly become less useful.

A model switch, a prompt tweak, a change in the retrieval mechanism, or even a shift in user behavior can erode quality by fractions of a percentage point per day. Monitoring error budget consumption makes this kind of drift visible: a single bad interaction may not matter against a 30-day objective, but a persistent decline consumes the budget cumulatively. The relevant signal stops being "one run failed" and becomes "the system's aggregate behavior is drifting outside the agreed reliability envelope."

The hard part: defining what's acceptable

The hardest part isn't creating the SLO, it's deciding what counts as acceptable behavior. For availability, the industry has decades of operational experience to draw on. For knowing whether an agent should fulfill 85%, 95%, or 99% of tasks, or maintain what level of grounding in context, that consensus doesn't exist yet.

Grafana's approach is to establish a baseline through evaluations and use historical results to recommend an initial target, which can be tightened as the agent matures. The idea grew out of an internal problem: Grafana's own Agent Observability work emerged from the need to monitor the Grafana Assistant, when changes to prompts, models, and tools made traditional monitoring insufficient. In community discussions, Grafana engineers distinguish offline evaluations, which validate changes against known scenarios, from online evaluations, which measure behavior against real production interactions.

The limitations: the SLO is only as good as the evaluation

An SLO is only as reliable as the measurement behind it. If an LLM judge systematically misclassifies, the resulting error budget conveys a false sense of precision. Likewise, a poorly designed evaluation can reward an agent for producing outputs that technically satisfy a criterion but fail to meet the user's actual intent.

In practice, this means organizations still need representative evaluation datasets, clear definitions of what counts as acceptable behavior, deterministic checks where possible, human review for ambiguous cases, and ongoing validation of the evaluators themselves. The SLO provides the governance mechanism; it doesn't, by itself, make the quality measurement correct.

The bigger picture: Anthropic and OpenTelemetry

Grafana's proposal adds to a broader industry effort to make agent behavior measurable, with other companies attacking the problem from different angles. Anthropic has developed more formal evaluation practices for agents, using defined tasks, repeated testing, and multiple evaluators to measure whether an agent consistently achieves the intended outcome. The distinction between pass@k, which measures whether the agent succeeds at least once across multiple attempts, and pass^k, which measures whether it succeeds consistently across all attempts, is especially relevant for agents in production, where reliability matters more than eventually finding the right answer.

OpenTelemetry, meanwhile, attacks the problem at a different layer, working on standardized semantic conventions for agent telemetry, so that traces, metrics, and logs offer a consistent basis for evaluating behavior across different frameworks and vendors. The pattern that emerges: evaluations say whether the agent behaved correctly, observability provides the evidence, and SLOs give the operational threshold for deciding whether that behavior is acceptable.

What changes for those building agents in Brazil

Brazilian teams that already use Grafana and Prometheus for API and microservice SRE have the shortest technical path to adopting this model: the same SLI, SLO, and error budget mechanics already running for latency and availability can be extended to the customer service agent, the internal copilot, or the search assistant that went into production in recent months.

The practical gain is separating "the agent is up" from "the agent is trustworthy." A support bot can respond 200ms faster while giving increasingly less grounded answers relative to the knowledge base content, without triggering any traditional alert. Setting a fulfillment or groundedness SLO, even if arbitrary at first, gives the team an objective signal for deciding when to stop experimenting with prompts or models and invest in fixing quality before the next deploy.