Wie bewaakt de bewaker? Meta-monitoring voor AI-agents

Half augustus deed een routinerun van een van mijn agents iets wat geen enkel dashboard die maand had gedaan: hij bracht slecht nieuws. De cron-guardian, het vangnet dat falende scheduled jobs in mijn stack hoort uit te schakelen, bleek zelf al ruim twee weken kapot. 258 opeenvolgende errors, keurig gelogd, door niemand gelezen. Er kwam geen alert, want alarmeren was de taak van precies het onderdeel dat kapot was.

Eerder schreef ik hoe mijn AI-agent successen verzon. Dit is de volgende laag van hetzelfde probleem: ook de controle op die claims kan geruisloos uitvallen. Dezelfde week bleek er namelijk nóg een meting al een maand te liegen, met een keurig excuus erbij.

Vijf weken in stilte

De reconstructie achteraf was ontnuchterend. Op 11 juli ging de laatste backup-commit naar mijn vault-repo. Op 29 juli deed de cron-guardian zijn laatste geslaagde check en begon hij zelf te falen. Daarna stapelden de errors zich op. Dag na dag. Tot een andere agent er op 14 augustus toevallig op stuitte tijdens een verbruiksrapportage. Opgeteld: 34 dagen zonder backup, waarvan de laatste ruim twee weken ook zonder werkend vangnet.

Het ongemakkelijke is niet dat er iets kapot ging. Dingen gaan kapot. Het ongemakkelijke is dat de ontdekking van toeval afhing, terwijl het bewijs er al die tijd lag.

258

Opeenvolgende errors van de cron-guardian zelf

Dagen dat de backup-check op UNKNOWN stond

Dagen zonder backup-commit die daaronder verborgen zat

FIGUUR 01 Alles hieronder speelde zich af terwijl het dashboard rustig bleef.

UNKNOWN is geen datapunt, het is een aanname

De tweede vondst zat dieper verstopt. In mijn infra-overzicht stond de backup-versheid al 33 dagen op UNKNOWN, met als keurige reden: "geen GitHub-toegang". Dat klonk als een technische beperking, dus niemand keek er nog naar. Een UNKNOWN went verrassend snel.

Toen ik het naliep, bleek het token dat die check nodig had er al die tijd gewoon te zijn. De check was simpelweg nooit met dat token getest. Eén HTTP-request later had ik een status 200 en zicht op het echte probleem: 34 dagen zonder backup-commit.

Sindsdien lees ik elke UNKNOWN in een dashboard anders. Het is zelden een missend datapunt. Het is meestal een aanname die niemand ooit getest heeft, met een geloofwaardig excuus eroverheen.

HTTP-request met een token dat er al lag

200

De status die het meetgat sloot

33 dgn

Blindheid die die ene request had kunnen voorkomen

FIGUUR 02 De verhouding tussen probleem en oplossing is hier het verhaal.

Wie bewaakt de bewaker: meta-monitoring in de praktijk

De Romeinen hadden er al een uitdrukking voor: quis custodiet ipsos custodes. In SRE-taal heet het antwoord heartbeat monitoring, ook wel een dead man's switch. Je vangnet moet zelf een hartslag afgeven. Blijft die uit, dan hoort ergens anders een alarm af te gaan. Voor cron job monitoring is dit het standaardpatroon, en Googles SRE-boek zegt in essentie hetzelfde over elke monitoringlaag: als niemand merkt dat de monitoring uitvalt, heb je geen monitoring maar decoratie.

Mijn eigen invulling is bewust klein gehouden. Elke guardian, elke health-check en elke scheduled AI-agent beantwoordt voortaan één extra vraag: wanneer draaide jij zelf voor het laatst? Die timestamps komen samen in één tabel, en één wekelijkse run kijkt alleen dáárnaar. Geen vierde laag daarboven. Op dat punt neemt een mens het over, en dat hoort zo.

Eerlijkheidshalve: die wekelijkse run is twee dagen oud en heeft zichzelf nog niet bewezen. Zijn stilte zou nu binnen een week moeten opvallen in plaats van binnen een maand. De eerste weken gaan uitwijzen of dat klopt.

Wat dit betekent voor je marketplace-operatie

Vertaal dit naar e-commerce en het wordt direct concreet. Je hebt een monitor op je orderflow, een alert op feed-errors, misschien een tool die de Buy Box bewaakt. Maar wanneer heb je voor het laatst gecheckt of die bewakers zelf nog draaien? Een feed-monitor die in juli is gecrasht, produceert in augustus precies hetzelfde als een gezonde monitor zonder problemen: stilte.

Bij mijn eigen orderbewaking op Channable staat er daarom een tweede check naast die alleen bevestigt dat de eerste nog leeft. En elke UNKNOWN of "kon niet meten" in een wekelijks rapport behandel ik als actiepunt, niet als voetnoot.

De nuance: niet elke monitor verdient een monitor

Je kunt hier ook in doorslaan. Monitor de monitors, geef die monitor weer een monitor, en je bouwt een toren die niemand meer onderhoudt en die zelf de storing wordt. De grens die voor mij werkt: twee geautomatiseerde lagen, en daarboven een mens met een vaste wekelijkse blik op één overzicht. Meer lagen voegen vooral gevoel van veiligheid toe, geen veiligheid. En ja, ook mijn nieuwe meta-check kan stuk gaan. Het verschil is dat zijn stilte nu een zichtbare afwijking is in een overzicht waar ik wekelijks naar kijk, geen stilte tussen andere stiltes.

Een groen dashboard is een claim, geen feit. Behandel het zo.