Het artikel pleit voor de overgang naar agentische monitoring, waarbij AI-agents worden ingezet om software-systemen te bewaken. De auteur stelt dat moderne systemen te complex zijn geworden voor menselijke operators alleen en dat traditionele observability-tools vaak te duur zijn of leiden tot alert fatigue.
Kernpunten uit het artikel:
- De rol van agents: Agents kunnen fungeren als 'superfans' die obsessief één component monitoren. Ze kunnen logs scannen en queries uitvoeren met een precisie en snelheid die mensen overtreffen.
- Monitoring van wijzigingspunten: De auteur focust op change points (zoals releases en configuratie-updates), waar de meeste uitval plaatsvindt. Agents lossen hier het dilemma tussen precisie (traag) en latentie (snel) op.
- Structurele voordelen:
- 24/7 beschikbaarheid: Agents raken niet vermoeid en volgen alle signalen, niet alleen die boven een menselijke drempel uitkomen.
- Parallelle analyse: Ze kunnen meerdere onderzoekspaden tegelijk bewandelen bij incidenten (fan out).
- Snelheid: Agents lezen code en verwerken data sneller dan mensen.
- Toekomstperspectief: De auteur voorziet een verschuiving naar zelfhelende systemen die niet alleen problemen detecteren, maar ook autonoom optimalisaties voorstellen of rollbacks uitvoeren.
De conclusie is dat de kosten van LLM-tokens inmiddels zo laag zijn dat agentische monitoring voor elk techbedrijf toegankelijk is en binnenkort de industriestandaard zal worden.
Agentische Monitoring
Een nieuw niveau van operationele uitmuntendheid is mogelijk. Ons team maakt intensief gebruik van Claude Tag, wat ons heeft geholpen elk onderdeel van het systeem te monitoren. We hebben bijvoorbeeld Slack-kanalen aangemaakt waarin we Claude de taak gaven om obsessief gefocust te zijn op de gezondheid van één enkel component. We noemen deze Claudes "superfans". We hebben een scion-daemon superfan, een scion-cache superfan, een Antique merge queue superfan, enzovoort. Ze hebben toegang tot onze telemetrie en logs, en gedragen zich als een ervaren engineer die niets beters te doen heeft dan grafieken te verversen en te zoeken naar alles wat vreemd is. We hebben ook traditionele alerts voor al onze systemen, maar onze superfans kunnen subtiele en nieuwe problemen detecteren die deze alerts in vergelijking eendimensionaal doen lijken.
Dit is overduidelijk de weg voorwaarts voor software-system operations. Ik denk de afgelopen weken na over monitoring met agents, en deze paragraaf heeft die gedachten gekristalliseerd.
Moderne softwaresystemen zijn, net als de LLM's die ze schrijven, steeds meer "gegroeid" dan "ontworpen". Ja, menselijke engineers geven vaak nog het high-level ontwerp en de vorm aan het systeem, en ja, softwaresystemen zijn (voorlopig) veel interpreteerbaarder dan LLM's – aangezien je gewoon kunt gaan zitten en de code kunt lezen, als je daartoe geneigd bent. Echter, nu het volume aan geschreven en uitgebrachte code exponentieel toeneemt, neemt de hoeveelheid daadwerkelijke kennis van de code die een menselijke operator van een systeem heeft, af.
Systeemmonitoring was nooit eenvoudig. Er is een hele industrie van observability SaaS-bedrijven – Sentry, Datadog, Splunk, Honeycomb, om er een paar te noemen. Observability is duur.[^1] Om het goed te doen is een gespecialiseerde menselijke vaardigheidset vereist en leunt het op ervaring met het beheren van echte systemen op schaal. Men kan deze vaardigheden eigenlijk alleen ontwikkelen door in de industrie te werken. Dit is een domein waar het jaren duurt om junior engineers in op te leiden.
Zoals met vrijwel alles in de software-industrie in 2026, staat systeemmonitoring aan de vooravond van een grote sprong voorwaarts dankzij agents. Ik ben verrast dat ik niet meer mensen hierover heb horen schrijven, zeker in het huidige klimaat van "agent-gekte". Het ligt recht voor ons neus en het werkt. Er zijn een heleboel startups die proberen de "AI SRE" (Site Reliability Engineer) te realiseren, maar er is weinig geschreven door mensen uit de praktijk.
Maar je hebt niet echt een volledige "AI SRE" nodig om de operationele uitmuntendheid te verbeteren, noch heb je een uitgebreid SaaS-product nodig om dit te doen. Met de huidige klasse modellen, zoals Opus 5.5 / Astra, is het met een beetje zorgvuldigheid volledig mogelijk om een goed agent-gestuurd monitoringsysteem te maken dat "gewoon werkt".
Casestudy: Monitoring van wijzigingspunten
Ik zal deze discussie baseren op een probleem dat me na aan het hart ligt: productiemonitoring van wijzigingspunten (change points), zoals binaire releases en configuratie-updates. Het idee is dat je gespecialiseerde, intensieve monitoring wilt uitvoeren rond kritieke wijzigingspunten in een systeem; deze punten hebben een grotere kans om een regressie te triggeren, en door deze gebeurtenissen nauwgezet te monitoren, kun je de impact beperken. Om de clichématige zin uit het Google SRE-boek aan te halen: "~70% van de uitval is te wijten aan wijzigingen in een live systeem".
Dit is een complex probleem. Ik werk hier sinds 2023 in verschillende vormen aan, en het was moeilijk om tractie te krijgen. Uit gesprekken met mensen in de sector heb ik geleerd dat er manieren zijn om wijzigingspuntsmonitoring "goed" te doen, maar deze methoden leunen nog grotendeels op mensen om het juiste te doen (bijv. metrics/alerts zorgvuldig taggen, precieze signalen definiëren, etc.) en vereisen een aanzienlijke organisatorische investering.
Specifiek is het moeilijk om wijzigingspuntsmonitoring als onderdeel van platform engineering succesvol te implementeren ("takeoff") omdat:
- De focus op gemotiveerde gebruikers: Je eerste instinct is wellicht om je te richten op hooggemotiveerde gebruikers die al een goede ops-houding hebben. Echter, de uitrol van deze teams is meestal al veilig, waardoor je de algemene veiligheidsstandaard niet veel verhoogt. Wat je hier verkoopt is het verminderen van toil (repetitief handwerk), wat "nice to have" is, maar op zichzelf geen primaire verbetering van de veiligheid vormt. Precisie is makkelijker te bereiken voor zeer gemotiveerde teams, maar dit betekent dat het wijzigingspuntsysteem "concureert" op recall en latentie met traditionele alerts.
- De focus op de brede populatie: Je kunt alternatief mikken op de brede populatie van services. Met andere woorden: je gaat zeer breed en kiest voor "alle services" op een geselecteerde subset van universele gezondheidsmetrics. In de praktijk zijn de meeste van deze algemene gezondheidsmetrics onherroepelijk ruisgevoelig. Deze ruis resulteert in een slechte precisie en alert fatigue (alert-moeheid).
Vóór LLM's was er een duidelijke afweging tussen precisie en latentie. Op dit spectrum bevinden zich:
- Gestructureerde logs: (precies, traag)
- Metrics: (grof, snel)
- Alerts: (nog grover, recall is vrij slecht en precisie is vrij slecht, maar "het is tenminste iets")
Verrassend genoeg lossen agents dit probleem grotendeels simpelweg op. Agents kunnen probleemloos talloze queries uitvoeren, kunnen on-the-fly queries per wijziging schrijven en zullen logs ad nauseam scannen. Als resultaat kun je zowel een goede precisie als recall krijgen tegen lage kosten. In de basisversie van deze opstelling heb je alleen de mogelijkheid nodig om je codebase (bijv. om na te denken over configuratieverbruik) en je observability-stack (bijv. om de live productiestatus te bekijken en te monitoren) te verbinden met de agent.
Ik heb een prototype hiervan gebouwd: een agent die een monitoringsplan voorstelt op basis van de servicecode, een raamwerk (scaffold) dat dit plan uitvoert, en een agent die getriggerde monitors onderzoekt, met een escalatiepad naar mensen. Zelfs in dit vroege prototype was ik in staat om regressies te detecteren in systemen waar ik nul kennis van had, met een precisie en latentie die een jaar geleden onmogelijk zouden zijn geweest.
Tijdens het itereren heb ik ontdekt dat een pure agent-loop niet de optimale vorm is voor agentische monitors. In plaats daarvan produceert een harnas (harness) dat de agent in staat stelt een specificatie te schrijven over hoe er gemonitord moet worden, samen met een deterministisch systeem voor het uitvoeren van die specificaties, significant schonere signalen met een dramatisch lager tokenverbruik. Voor zover er "geheim ingrediënten" zijn in dit patroon, zitten die in de heuristieken voor ruisonderdrukking, de prompts die de agent aanzetten tot het schrijven van goede specificaties, en een gelabelde evaluatieset die groot genoeg is om verdere tweaks te valideren.[^2]
Waarom agents structureel geschikt zijn voor monitoring
Voordat dit patroon breed geaccepteerd wordt, moeten er twee mentale verschuivingen plaatsvinden:
- Agents kunnen monitoring daadwerkelijk veel beter uitvoeren dan mensen.
- Monitoring agents hebben ondersteunende structuren (scaffolding) nodig, op dezelfde manier waarop de rest van de softwareontwikkelingscyclus zich moest aanpassen voor coding agents. Er is nog geen "Claude Code-moment" geweest voor monitoring.
Zodra je deze verschuivingen maakt, hebben monitoring agents verschillende "oneerlijke voordelen" ten opzichte van menselijke operators:
- Vermogen om alles 24/7 te volgen. Als tokens goedkoop zijn, kan elke regressie in een metric die belangrijk is en elke verdachte logregel worden onderzocht – niet alleen de gebeurtenissen die voorheen boven de "menselijke aandachtsgrens" zouden uitkomen. Agents hoeven niet "de zon te volgen" (shift-work over tijdzones).
- Vermogen om uit te waaieren (fan out) en meerdere paden te onderzoeken om een productieprobleem op te lossen. Agents kunnen onderzoeken paralleliseren wanneer er meerdere dingen tegelijk misgaan, en snel coördineren. Dit is al mijn standaardmethode voor incident triage: ik start een reeks agents om verschillende potentiële threads of theorieën over de oorzaak van een incident te onderzoeken. Momenteel is dit mensgestuurd, maar er is geen reden waarom dit in de toekomst niet agent-gestuurd zou kunnen zijn. Je kunt elastisch een vloot incident-responders opschalen.
- We zien al dat dit cruciaal wordt voor beveiligingsincidenten. Teams/vloten/zwermen agents worden gebruikt voor offensieve cyberaanvallen, en verdedigers beginnen soortgelijke defensieve capaciteiten op te bouwen (bijv. OpenAI's Daybreak Blue, Anthropic's Project Glasswing, Google's Fairwind).
- Vermogen om sneller op een probleem te reageren dan een mens. Agents kunnen code sneller lezen dan mensen. Agents kunnen ook metrics en log-signalen significant sneller queryen en verwerken. Deze snelheid vertaalt zich niet altijd in een snellere detectietijd; een mens met een diepgaand begrip van een systeem kan nog steeds sneller het juiste signaal vinden en de bronoorzaken intuïtief aanwijzen. Maar voor zover stilzwijgende kennis kan worden vastgelegd en beschikbaar wordt gesteld aan een agent, zal de agent de mens uiteindelijk op snelheid verslaan.
- Bij uitbreiding zal voor systemen waar de menselijke operator niet diepgaand ervaren is, de "tijd tot begrip" korter zijn voor een agent.
Een nieuw niveau van operationele uitmuntendheid
"Een nieuw niveau van operationele uitmuntendheid is mogelijk."
- Word zorgvuldiger: Je zou geen fulltime software engineer betalen om alle Git-commits van een service door te lopen, zaken te kiezen om te monitoren en speciale kortstondige fast-trigger alerts te maken voor precies die wijzigingen. Echter, voor een paar cent per miljoen tokens is dit nu mogelijk, en zal het een industriestandaard worden.
- Continu prestaties verbeteren: Agents kunnen prestaties monitoren, kijken naar heap dumps, stack traces en CPU-profielen, en optimalisaties voorstellen op basis van de patronen die ze vinden. Plaats de voorgestelde verbeteringen indien nodig achter A/B-tests en monitor deze zoals elke andere wijziging in de service.
- In één geval zag ik dat een paar sessies van Astra/Opus-onderzoek 50% besparing op de heap en 30% latentiereductie ontdekten in een veelgebruikte hot-path bibliotheek waar mensen al aanzienlijke moeite in hadden gestoken om te optimaliseren. Zodra je een voldoende krachtige LLM een VM en benchmarks geeft om uit te voeren, is het "hill-climbing" vermogen van LLM's van de huidige generatie opmerkelijk.
- Actie ondernemen: Tot nu toe heb ik vooral gesproken over "read-only" monitoringsystemen. Agents hoeven uiteraard niet "read-only" te zijn. Met het juiste harnas en de juiste waarborgen is er zeker een toekomst waarin agents front-line acties kunnen ondernemen om incidenten te verhelpen. Dit kan variëren van goed afgebakende operationele taken zoals het aanpassen van de grootte van instances of het roteren van compute pools, tot deterministische acties zoals het terugdraaien (rollback) van een configuratiewijziging of binary, tot open-ended taken zoals het vinden van de bronoorzaak van bugs, het voorstellen van fixes en het on-the-fly opnieuw implementeren. Natuurlijk is er risico naarmate je meer controle overdraagt aan de agent, maar gezien hoe sterk de agent-capaciteiten in de afgelopen 12 maanden zijn uitgebreid, zal de hoeveelheid werk in het schrijfproces die verantwoordelijk aan agents kan worden overgedragen, ongetwijfeld toenemen. De belofte van echt zelfhelende systemen is opwindend.
Kosten en de positieve spiraal
Kosten zijn geen beperking meer. Luna/Haiku-klasse modellen[^3] zijn inmiddels competente "grafiek-stariers". Een middelgroot techbedrijf zou waarschijnlijk zijn volledige vloot kunnen monitoren voor ongeveer $100 per dag. Vloten op startup-schaal zouden een fractie daarvan kosten. Vergeleken met menselijke arbeid, of zelfs de kosten van de infrastructuur die observability draait, is dit triviaal.
Door dit goed aan te pakken, creëert agentische monitoring een positieve feedbackloop: coding agents stellen je in staat om meer te releasen, monitoring agents stellen je in staat om meer systemen te ondersteunen, wat op zijn beurt menselijke tijd vrijmaakt om meer zaken te dirigeren voor release. Mensen besteden steeds meer tijd aan het "bouwen van de fabriek" of het "verzorgen van de tuin".
Agentische monitoring is het waard om in te investeren. Binnenkort zal het roekeloos zijn om geen agents je systemen te laten monitoren. Totdat de rest van de industrie bijhoudt, biedt een vroege start een oneerlijk voordeel.
***
[^1]: Een set optimalisaties die mijn team onlangs heeft voltooid, bespaarde ons enkele miljoenen dollars aan jaarlijkse observability-kosten, en... dat was slechts een fractie van wat alleen mijn team uitgeeft aan observability. [^2]: Er kan veel meer worden geschreven over het ontwerp van agentische monitoringsharnassen. Dit is een van de duidelijkste "we staan nog maar aan het begin"-gevoelens die ik in lange tijd heb gehad. Algemene harnassen, zoals Anthropic's "Claude Tag", doen blijkbaar al een goed werk bij agentische monitoring, volgens de oorspronkelijke post. Echter, gebaseerd op wat ik heb gezien, levert zelfs een klein beetje specifiek harness-engineering voor monitoring al veel winst op. [^3]: Hier bedoel ik GPT-6-Luna en Claude Haiku 5.5.
Agentische Monitoring
Een nieuw niveau van operationele uitmuntendheid is mogelijk. Ons team maakt intensief gebruik van Claude Tag, wat ons heeft geholpen elk onderdeel van het systeem te monitoren. We hebben bijvoorbeeld Slack-kanalen aangemaakt waarin we Claude de taak gaven om obsessief gefocust te zijn op de gezondheid van één enkel component. We noemen deze Claudes "superfans". We hebben een scion-daemon superfan, een scion-cache superfan, een Antique merge queue superfan, enzovoort. Ze hebben toegang tot onze telemetrie en logs, en gedragen zich als een ervaren engineer die niets beters te doen heeft dan grafieken te verversen en te zoeken naar alles wat vreemd is. We hebben ook traditionele alerts voor al onze systemen, maar onze superfans kunnen subtiele en nieuwe problemen detecteren die deze alerts in vergelijking eendimensionaal doen lijken.
Dit is overduidelijk de weg voorwaarts voor software-system operations. Ik denk de afgelopen weken na over monitoring met agents, en deze paragraaf heeft die gedachten gekristalliseerd.
Moderne softwaresystemen zijn, net als de LLM's die ze schrijven, steeds meer "gegroeid" dan "ontworpen". Ja, menselijke engineers geven vaak nog het high-level ontwerp en de vorm aan het systeem, en ja, softwaresystemen zijn (voorlopig) veel interpreteerbaarder dan LLM's – aangezien je gewoon kunt gaan zitten en de code kunt lezen, als je daartoe geneigd bent. Echter, nu het volume aan geschreven en uitgebrachte code exponentieel toeneemt, neemt de hoeveelheid daadwerkelijke kennis van de code die een menselijke operator van een systeem heeft, af.
Systeemmonitoring was nooit eenvoudig. Er is een hele industrie van observability SaaS-bedrijven – Sentry, Datadog, Splunk, Honeycomb, om er een paar te noemen. Observability is duur.[^1] Om het goed te doen is een gespecialiseerde menselijke vaardigheidset vereist en leunt het op ervaring met het beheren van echte systemen op schaal. Men kan deze vaardigheden eigenlijk alleen ontwikkelen door in de industrie te werken. Dit is een domein waar het jaren duurt om junior engineers in op te leiden.
Zoals met vrijwel alles in de software-industrie in 2026, staat systeemmonitoring aan de vooravond van een grote sprong voorwaarts dankzij agents. Ik ben verrast dat ik niet meer mensen hierover heb horen schrijven, zeker in het huidige klimaat van "agent-gekte". Het ligt recht voor ons neus en het werkt. Er zijn een heleboel startups die proberen de "AI SRE" (Site Reliability Engineer) te realiseren, maar er is weinig geschreven door mensen uit de praktijk.
Maar je hebt niet echt een volledige "AI SRE" nodig om de operationele uitmuntendheid te verbeteren, noch heb je een uitgebreid SaaS-product nodig om dit te doen. Met de huidige klasse modellen, zoals Opus 5.5 / Astra, is het met een beetje zorgvuldigheid volledig mogelijk om een goed agent-gestuurd monitoringsysteem te maken dat "gewoon werkt".
Casestudy: Monitoring van wijzigingspunten
Ik zal deze discussie baseren op een probleem dat me na aan het hart ligt: productiemonitoring van wijzigingspunten (change points), zoals binaire releases en configuratie-updates. Het idee is dat je gespecialiseerde, intensieve monitoring wilt uitvoeren rond kritieke wijzigingspunten in een systeem; deze punten hebben een grotere kans om een regressie te triggeren, en door deze gebeurtenissen nauwgezet te monitoren, kun je de impact beperken. Om de clichématige zin uit het Google SRE-boek aan te halen: "~70% van de uitval is te wijten aan wijzigingen in een live systeem".
Dit is een complex probleem. Ik werk hier sinds 2023 in verschillende vormen aan, en het was moeilijk om tractie te krijgen. Uit gesprekken met mensen in de sector heb ik geleerd dat er manieren zijn om wijzigingspuntsmonitoring "goed" te doen, maar deze methoden leunen nog grotendeels op mensen om het juiste te doen (bijv. metrics/alerts zorgvuldig taggen, precieze signalen definiëren, etc.) en vereisen een aanzienlijke organisatorische investering.
Specifiek is het moeilijk om wijzigingspuntsmonitoring als onderdeel van platform engineering succesvol te implementeren ("takeoff") omdat:
- De focus op gemotiveerde gebruikers: Je eerste instinct is wellicht om je te richten op hooggemotiveerde gebruikers die al een goede ops-houding hebben. Echter, de uitrol van deze teams is meestal al veilig, waardoor je de algemene veiligheidsstandaard niet veel verhoogt. Wat je hier verkoopt is het verminderen van toil (repetitief handwerk), wat "nice to have" is, maar op zichzelf geen primaire verbetering van de veiligheid vormt. Precisie is makkelijker te bereiken voor zeer gemotiveerde teams, maar dit betekent dat het wijzigingspuntsysteem "concureert" op recall en latentie met traditionele alerts.
- De focus op de brede populatie: Je kunt alternatief mikken op de brede populatie van services. Met andere woorden: je gaat zeer breed en kiest voor "alle services" op een geselecteerde subset van universele gezondheidsmetrics. In de praktijk zijn de meeste van deze algemene gezondheidsmetrics onherroepelijk ruisgevoelig. Deze ruis resulteert in een slechte precisie en alert fatigue (alert-moeheid).
Vóór LLM's was er een duidelijke afweging tussen precisie en latentie. Op dit spectrum bevinden zich:
- Gestructureerde logs: (precies, traag)
- Metrics: (grof, snel)
- Alerts: (nog grover, recall is vrij slecht en precisie is vrij slecht, maar "het is tenminste iets")
Verrassend genoeg lossen agents dit probleem grotendeels simpelweg op. Agents kunnen probleemloos talloze queries uitvoeren, kunnen on-the-fly queries per wijziging schrijven en zullen logs ad nauseam scannen. Als resultaat kun je zowel een goede precisie als recall krijgen tegen lage kosten. In de basisversie van deze opstelling heb je alleen de mogelijkheid nodig om je codebase (bijv. om na te denken over configuratieverbruik) en je observability-stack (bijv. om de live productiestatus te bekijken en te monitoren) te verbinden met de agent.
Ik heb een prototype hiervan gebouwd: een agent die een monitoringsplan voorstelt op basis van de servicecode, een raamwerk (scaffold) dat dit plan uitvoert, en een agent die getriggerde monitors onderzoekt, met een escalatiepad naar mensen. Zelfs in dit vroege prototype was ik in staat om regressies te detecteren in systemen waar ik nul kennis van had, met een precisie en latentie die een jaar geleden onmogelijk zouden zijn geweest.
Tijdens het itereren heb ik ontdekt dat een pure agent-loop niet de optimale vorm is voor agentische monitors. In plaats daarvan produceert een harnas (harness) dat de agent in staat stelt een specificatie te schrijven over hoe er gemonitord moet worden, samen met een deterministisch systeem voor het uitvoeren van die specificaties, significant schonere signalen met een dramatisch lager tokenverbruik. Voor zover er "geheim ingrediënten" zijn in dit patroon, zitten die in de heuristieken voor ruisonderdrukking, de prompts die de agent aanzetten tot het schrijven van goede specificaties, en een gelabelde evaluatieset die groot genoeg is om verdere tweaks te valideren.[^2]
Waarom agents structureel geschikt zijn voor monitoring
Voordat dit patroon breed geaccepteerd wordt, moeten er twee mentale verschuivingen plaatsvinden:
- Agents kunnen monitoring daadwerkelijk veel beter uitvoeren dan mensen.
- Monitoring agents hebben ondersteunende structuren (scaffolding) nodig, op dezelfde manier waarop de rest van de softwareontwikkelingscyclus zich moest aanpassen voor coding agents. Er is nog geen "Claude Code-moment" geweest voor monitoring.
Zodra je deze verschuivingen maakt, hebben monitoring agents verschillende "oneerlijke voordelen" ten opzichte van menselijke operators:
- Vermogen om alles 24/7 te volgen. Als tokens goedkoop zijn, kan elke regressie in een metric die belangrijk is en elke verdachte logregel worden onderzocht – niet alleen de gebeurtenissen die voorheen boven de "menselijke aandachtsgrens" zouden uitkomen. Agents hoeven niet "de zon te volgen" (shift-work over tijdzones).
- Vermogen om uit te waaieren (fan out) en meerdere paden te onderzoeken om een productieprobleem op te lossen. Agents kunnen onderzoeken paralleliseren wanneer er meerdere dingen tegelijk misgaan, en snel coördineren. Dit is al mijn standaardmethode voor incident triage: ik start een reeks agents om verschillende potentiële threads of theorieën over de oorzaak van een incident te onderzoeken. Momenteel is dit mensgestuurd, maar er is geen reden waarom dit in de toekomst niet agent-gestuurd zou kunnen zijn. Je kunt elastisch een vloot incident-responders opschalen.
- We zien al dat dit cruciaal wordt voor beveiligingsincidenten. Teams/vloten/zwermen agents worden gebruikt voor offensieve cyberaanvallen, en verdedigers beginnen soortgelijke defensieve capaciteiten op te bouwen (bijv. OpenAI's Daybreak Blue, Anthropic's Project Glasswing, Google's Fairwind).
- Vermogen om sneller op een probleem te reageren dan een mens. Agents kunnen code sneller lezen dan mensen. Agents kunnen ook metrics en log-signalen significant sneller queryen en verwerken. Deze snelheid vertaalt zich niet altijd in een snellere detectietijd; een mens met een diepgaand begrip van een systeem kan nog steeds sneller het juiste signaal vinden en de bronoorzaken intuïtief aanwijzen. Maar voor zover stilzwijgende kennis kan worden vastgelegd en beschikbaar wordt gesteld aan een agent, zal de agent de mens uiteindelijk op snelheid verslaan.
- Bij uitbreiding zal voor systemen waar de menselijke operator niet diepgaand ervaren is, de "tijd tot begrip" korter zijn voor een agent.
Een nieuw niveau van operationele uitmuntendheid
"Een nieuw niveau van operationele uitmuntendheid is mogelijk."
- Word zorgvuldiger: Je zou geen fulltime software engineer betalen om alle Git-commits van een service door te lopen, zaken te kiezen om te monitoren en speciale kortstondige fast-trigger alerts te maken voor precies die wijzigingen. Echter, voor een paar cent per miljoen tokens is dit nu mogelijk, en zal het een industriestandaard worden.
- Continu prestaties verbeteren: Agents kunnen prestaties monitoren, kijken naar heap dumps, stack traces en CPU-profielen, en optimalisaties voorstellen op basis van de patronen die ze vinden. Plaats de voorgestelde verbeteringen indien nodig achter A/B-tests en monitor deze zoals elke andere wijziging in de service.
- In één geval zag ik dat een paar sessies van Astra/Opus-onderzoek 50% besparing op de heap en 30% latentiereductie ontdekten in een veelgebruikte hot-path bibliotheek waar mensen al aanzienlijke moeite in hadden gestoken om te optimaliseren. Zodra je een voldoende krachtige LLM een VM en benchmarks geeft om uit te voeren, is het "hill-climbing" vermogen van LLM's van de huidige generatie opmerkelijk.
- Actie ondernemen: Tot nu toe heb ik vooral gesproken over "read-only" monitoringsystemen. Agents hoeven uiteraard niet "read-only" te zijn. Met het juiste harnas en de juiste waarborgen is er zeker een toekomst waarin agents front-line acties kunnen ondernemen om incidenten te verhelpen. Dit kan variëren van goed afgebakende operationele taken zoals het aanpassen van de grootte van instances of het roteren van compute pools, tot deterministische acties zoals het terugdraaien (rollback) van een configuratiewijziging of binary, tot open-ended taken zoals het vinden van de bronoorzaak van bugs, het voorstellen van fixes en het on-the-fly opnieuw implementeren. Natuurlijk is er risico naarmate je meer controle overdraagt aan de agent, maar gezien hoe sterk de agent-capaciteiten in de afgelopen 12 maanden zijn uitgebreid, zal de hoeveelheid werk in het schrijfproces die verantwoordelijk aan agents kan worden overgedragen, ongetwijfeld toenemen. De belofte van echt zelfhelende systemen is opwindend.
Kosten en de positieve spiraal
Kosten zijn geen beperking meer. Luna/Haiku-klasse modellen[^3] zijn inmiddels competente "grafiek-stariers". Een middelgroot techbedrijf zou waarschijnlijk zijn volledige vloot kunnen monitoren voor ongeveer $100 per dag. Vloten op startup-schaal zouden een fractie daarvan kosten. Vergeleken met menselijke arbeid, of zelfs de kosten van de infrastructuur die observability draait, is dit triviaal.
Door dit goed aan te pakken, creëert agentische monitoring een positieve feedbackloop: coding agents stellen je in staat om meer te releasen, monitoring agents stellen je in staat om meer systemen te ondersteunen, wat op zijn beurt menselijke tijd vrijmaakt om meer zaken te dirigeren voor release. Mensen besteden steeds meer tijd aan het "bouwen van de fabriek" of het "verzorgen van de tuin".
Agentische monitoring is het waard om in te investeren. Binnenkort zal het roekeloos zijn om geen agents je systemen te laten monitoren. Totdat de rest van de industrie bijhoudt, biedt een vroege start een oneerlijk voordeel.
***
[^1]: Een set optimalisaties die mijn team onlangs heeft voltooid, bespaarde ons enkele miljoenen dollars aan jaarlijkse observability-kosten, en... dat was slechts een fractie van wat alleen mijn team uitgeeft aan observability. [^2]: Er kan veel meer worden geschreven over het ontwerp van agentische monitoringsharnassen. Dit is een van de duidelijkste "we staan nog maar aan het begin"-gevoelens die ik in lange tijd heb gehad. Algemene harnassen, zoals Anthropic's "Claude Tag", doen blijkbaar al een goed werk bij agentische monitoring, volgens de oorspronkelijke post. Echter, gebaseerd op wat ik heb gezien, levert zelfs een klein beetje specifiek harness-engineering voor monitoring al veel winst op. [^3]: Hier bedoel ik GPT-6-Luna en Claude Haiku 5.5.
Groetjes,