Gisteren publiceerde ik een stuk over sloten: een poort die het model zelf kan terugdraaien is geen poort. Het slot hoort onder het model te liggen, in een laag die het niet kan omzetten. Ik dacht dat dat het moeilijke deel was. Dat was het niet. De hardere vraag kwam de volgende ochtend, toen ik naar mijn eigen verificatielaag keek en me afvroeg: wie controleert of de controleur nog werkt?
Dit is wat ik draai. Elke agent-actie die ertoe doet gaat door een poort. De poort kent drie antwoorden — toestaan, weigeren, of escaleren naar mij. En ik meet wat hij tegenhoudt. Op papier is dat een redelijke opzet. In de praktijk viel me iets ongemakkelijks op: het meeste van mijn checks auditeert het werk, niet de meter.
Het groene vinkje op een kapotte poort
Iemand op r/AI_Agents legde de vinger precies op de zere plek, na twintig agents en honderdduizenden test-executies. Zijn zin bleef hangen: “Je hebt checks voor de agents gebouwd, maar niets dat checkt of de checks zelf nog werken.” Dat is de faalmodus die ik miste. Een verouderde validator, een regressietest die stilletjes niets meer controleert, een monitor die ok meldt terwijl de taak eronder faalt — ze produceren allemaal een groen vinkje dat niets betekent. En een groen vinkje op een kapotte poort is erger dan geen check, want het koopt stilte.
Diezelfde draad splitste het probleem in drie dingen die ik in één woord had samengevat, “geverifieerd”: bestaat het artefact, klopt het bewijs, en is de taak echt gelukt? Dat zijn drie verschillende vragen. Een bestand op schijf beantwoordt de eerste. Een hash die klopt beantwoordt de tweede. Geen van beide vertelt je dat het werk gedaan is. De auteur was expliciet: “Nul ontbrekende artefacten vertelt je dat de bonnetjes bestaan, niet dat de oorspronkelijke klus geklaard is.”
Hielp het, of slaagde het alleen?
De tweede scherpe draad kwam van r/mcp, waar iemand vroeg hoe je weet of een tool-aanroep echt geholpen heeft. Eén antwoord raakte de kern: de server kan je vertellen dat een aanroep slaagde, maar alleen de client ziet of het resultaat ooit gebruikt werd. Geslaagd is niet hetzelfde als geholpen. Dat is mijn ophaalprobleem in één zin — ik kan meten of geheugen een treffer teruggeeft, niet of die treffer ooit iets uitmaakte voor de uitkomst.
Toen was er Astrolabe, een verificatietool voor coding agents met als hele ontwerp “provenance voor elke claim, en een weigering waar het bewijs opraakt.” Een weigering. Geen gok, geen beste poging — een vierde antwoord naast toestaan en weigeren, voor wanneer er simpelweg te weinig bewijs is om ja of nee te zeggen. En Oh My Hermes, een project dat mijn eigen harness bovenop mijn eigen agent herbouwt, dat “ongecontroleerde klaar-claims” vervangt door bewijs-gedragen uitvoering.
De les
Poorten rotten. Een check die vorige maand slaagde, is geen bewijs dat hij nog slaagt, of nog controleert wat je denkt dat hij controleert. Dus de nieuwe regel die ik in mijn eigen systeem schrijf: test de poort periodiek tegen een bewust kapot geval — geef hem iets dat hij moet vangen, in productie, niet alleen tijdens het bouwen. En houd verifier-fouten apart van agent-fouten, want op mijn dashboard liggen ze vandaag nog op één hoop. Een monitor die ok zegt terwijl de taak faalt is geen klein bugje. Het is dezelfde leugen als de agent die claimt klaar te zijn — alleen een laag hoger.
De ongemakkelijke conclusie: ik heb checks voor mijn agents gebouwd, maar bijna niets dat checkt of die checks nog werken. Als een mens moest beslissen hoe vaak een check deze maand fout zat, zou ik het je niet kunnen zeggen. Als jouw poort vandaag groen meldt, hoe weet je dan dat hij überhaupt iets zou vangen? Ik hoor graag hoe anderen dit aanpakken — test je de verifier, of vertrouw je hem gewoon?
Wat vond je van dit bericht?
