Agentic Monitoring
C · Weak signal Personal essay by engineer Ben Congdon arguing for agent-based monitoring from an unmeasured prototype and one anecdote; a reasonable design note, little evidence of its own.
Summary based on the full text·Original: about 10 minutes to read
In short
A blog post (19 October 2026) by Ben Congdon, prompted by an Anthropic post describing Claude instances that each watch one system component. He argues agents suit production monitoring, particularly around change points such as releases and config pushes, because they can write per-change queries and read logs at a scale people cannot. From his own prototype he finds that an agent writing a monitoring spec, run by a deterministic system, beats a pure agent loop on signal quality and token use.
Key numbers
- 50% / 30%heap savings and latency reduction found in a hot-path library by a few agent investigation sessions (one anecdote)
- ~$100/dayauthor's estimate for monitoring a moderately large tech company's fleet with small models
- ~70%share of outages due to changes in a live system, quoted from the Google SRE book
As reported by the source.
English·Web page·opens benjamincongdon.me
What it reports
- Change-point monitoring has been hard to adopt: well-run teams gain little, while blanket monitoring of noisy health metrics produces alert fatigue.
- His prototype: an agent proposes a monitoring plan from the service code, a scaffold executes it, and another agent investigates triggered monitors, escalating to humans.
- A spec-plus-deterministic-runner harness produced cleaner signals with much lower token use than an agent loop; the value is in noise-reduction heuristics, spec-writing prompts and a labelled eval set.
- In one case, a few agent sessions found 50% heap savings and 30% latency reduction in a library people had already optimised.
- Cost estimate: small models could monitor a moderately large company's fleet for about $100 a day.
- Write actions (rollbacks, resizing, fixes) are framed as a future step, with risk rising with autonomy.
How they got it
Opinion and experience from building a prototype; no metrics, eval results or comparisons are published.
Limits
- No data on precision, recall or latency for the prototype; claims of detecting regressions are qualitative.
- The cost figure is an estimate without a stated basis.
- Several claims (that agents "can do a much better job" than humans, that not using them will be "reckless") are assertions.
- The triggering source is a vendor blog paragraph about its own internal practice.
Why it matters for companies
The design point is the useful part: let a model write the monitoring spec for a change, then run that spec deterministically, instead of leaving an agent polling dashboards. That keeps cost and noise down and makes behaviour auditable. Firms with heavy observability bills or thin on-call coverage could pilot it on releases and config pushes, measuring precision and recall against existing alerts before trusting it, and keep remediation actions behind human approval.
Summary based on the full text. Read the original for the full argument and data.Read the original on benjamincongdon.me
- Tags
- Monitoring, Harness design