Grafana Applies SLOs and Error Budgets to AI Agent Behaviour

Grafana Labs is proposing a familiar reliability engineering approach for one of the less familiar problems in modern software: how to measure whether an AI agent is actually behaving well. In a recent article, the company describes using evaluations, service-level objectives (SLOs) and error budgets to turn behaviours such as hallucination, task fulfilment, toxicity, and cost into measurable targets that can be monitored over time.

The idea addresses a fundamental limitation of conventional application observability. Traditional metrics can tell engineers that an agent responded quickly, encountered no technical errors, and consumed a certain number of tokens, but none necessarily indicate whether its answer was correct, grounded in available information, or useful to the user. Grafana's approach is to evaluate the behaviour itself and turn the result into an SLI that can be measured against an SLO.

The first step is evaluation. An evaluation examines an agent interaction and determines whether it met a particular behavioural criterion. Grafana describes examples including whether a response was grounded in its supplied context, fulfilled the user's request, contained toxic content, exposed personal information, or succumbed to prompt injection. Evaluations can use another language model as a judge, but deterministic checks such as regular expressions can also be used where the behaviour can be identified without an LLM.

This is an important distinction from trying to create a single "agent quality score." Grafana argues that quality is multidimensional: an agent might be well grounded but expensive, helpful but occasionally toxic, or accurate but slow. Treating these as separate measurements allows teams to establish different objectives for the behaviours that matter to a particular application rather than hiding important failures inside an aggregate score.

Once a behaviour can be measured, conventional SRE concepts become applicable. Grafana gives the example of setting 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 behaviour the team has explicitly decided it can tolerate within that period.

This approach matters less for the percentage itself than for the decision-making model it creates. When sufficient error budget remains, teams can experiment with prompts, models, or agent behaviour. As the budget is consumed, the priority can shift towards improving quality rather than introducing additional changes. This is conceptually the same trade-off SRE teams have long used to balance reliability against development velocity. Grafana's existing SLO tooling similarly defines an SLO through an SLI, target, and time window, with the error budget calculated from the gap between the target and 100%.

The approach becomes particularly useful when agent behaviour changes gradually rather than failing dramatically. A conventional alert might identify a sudden spike in failed requests, but an agent can continue responding successfully while its answers become subtly less useful. A model change, prompt modification, retrieval change, or shift in user behaviour might cause quality to deteriorate by a fraction of a percentage point each day.

Grafana argues that monitoring error-budget burn can make this type of drift visible. A single poor interaction may not matter against a 30-day objective, but a persistent decline can steadily consume the available budget. That provides a different signal from traditional infrastructure monitoring: the concern is not necessarily whether one execution failed, but whether the aggregate behaviour of the system is moving outside an agreed reliability envelope.

The hardest part may not be creating the SLO, but deciding what constitutes acceptable behaviour. Unlike availability targets, where organisations have decades of operational experience to draw upon, there is considerably less consensus around whether an agent should achieve 85%, 95% or 99% fulfilment or groundedness.

Grafana's approach is to establish a baseline through evaluations and then use historical results to help recommend an appropriate target. The target can subsequently be tightened as the agent matures. The concept also reflects a broader change in what observability needs to cover. Grafana's own Agent Observability work grew from the problem of monitoring its Grafana Assistant as prompt, model, and tool changes made traditional monitoring insufficient. In community discussions, Grafana engineers have distinguished between offline evaluations, which validate changes against known scenarios, and online evaluations, which assess behaviour against real production interactions.

Traditional observability generally asks whether the system is available and performing within technical limits. AI systems introduce another layer: whether the system's decisions and outputs remain within acceptable behavioural boundaries. That creates a feedback loop between evaluation, observability, and engineering change that more closely resembles continuous quality measurement than conventional application monitoring.

There is also an important limitation. An SLO is only as useful as the measurement underneath it. If an LLM judge consistently misclassifies responses, the resulting error budget may provide a false sense of precision. Similarly, a poorly designed evaluation can reward an agent for producing outputs that technically satisfy a criterion while failing to satisfy the user's actual intent.

This means organisations still need representative evaluation datasets, clear definitions of acceptable behaviour, appropriate deterministic checks where possible, human review for ambiguous cases, and ongoing validation of the evaluators themselves. The SLO provides the governance mechanism, but it does not make the underlying quality measurement inherently correct.

SLOs have traditionally provided a common language for engineering teams to balance reliability and change: define what matters, measure it, establish an acceptable threshold, and use the remaining error budget to guide decisions.

Applying the same thinking to AI agents extends that model from system reliability to behavioural reliability. An agent can be technically available while being operationally unreliable because its answers are increasingly inaccurate, ungrounded, expensive, or unsafe. Treating those behaviours as measurable service objectives gives engineering teams a mechanism for detecting that degradation and deciding when experimentation should give way to remediation.

The significance is therefore not simply that Grafana has added another AI metric. It is that a mature SRE principle is being adapted to an environment where the system can remain "up" while becoming progressively less trustworthy. For organisations moving AI agents into production, that distinction may become one of the more important parts of AI observability.

Grafana's SLO approach is part of a broader industry effort to make agent behaviour measurable, although other organisations are approaching the problem from different directions. Anthropic, for example, has developed more formal evaluation practices for agents, using defined tasks, repeated trials and multiple graders to measure whether an agent consistently achieves its intended outcome. Its distinction between pass@k, which measures whether an agent succeeds at least once across multiple attempts, and pass^k, which measures whether it succeeds consistently across all attempts, is particularly relevant to production agents where reliability matters more than finding an answer eventually.

OpenTelemetry is approaching the problem at a different layer, working on standardised semantic conventions for agent telemetry so that traces, metrics and logs can provide a consistent basis for evaluating agent behaviour across frameworks and vendors. Together, these approaches illustrate an emerging pattern: evaluations determine whether an agent behaved correctly, observability provides the evidence, and SLOs provide the operational threshold for deciding whether that behaviour is acceptable.