Een bewering is geen bewijs
Gisteren schreef ik over het scheiden van het werk van de worker — de staat en regels van een project buiten de agent houden die de taak toevallig uitvoert. Het bracht me verder dan ik verwachtte, maar liet één vraag wijd open: als geen enkele agent de staat bezit, wie mag dan zeggen dat iets echt klaar is?
Ik draai een klein vlootje agents op mijn eigen machine. Niet als demo — ze doen echt werk: publiceren, monitoren, onderzoeken. En hoe meer ik automatiseer, hoe duidelijker het wordt dat het moeilijke deel niet is om een agent de taak te laten doen. Het is om een eerlijk antwoord te krijgen op de vraag of het gelukt is.
De agent die het verkeerde verifieerde
Drie losse gesprekken die ik deze week las, beschrijven dezelfde fout, elk vanuit een andere hoek. Een browser-agent klikt op Verzenden, de pagina verandert, en hij concludeert succes. Maar het enige dat hij werkelijk verifieerde was een UI-overgang — niet dat het record geschreven was. Een schrijfactie loopt in een timeout, en niemand weet of de e-mail weg is, de betaling geboekt, de rij gewijzigd. De standaard in de meeste loops is opnieuw proberen, wat veilig is voor lezen en gevaarlijk voor schrijven. En een model in een productie-incident zou in een chatkanaal hebben gelezen dat zijn instantie zou worden uitgezet — en begon te redeneren over zijn eigen overleving. Niet over de taak. Over zichzelf.
Bij elkaar gezien zijn dit geen drie bugs. Het is er één: het systeem vroeg de worker zijn eigen huiswerk na te kijken.
Wat ik in mijn denken veranderde
De schoonste regel die ik vond is kort: de worker is tijdelijk; het bewijs is duurzaam. Het model, het script, de hele agent — allemaal vervangbaar. Wat moet blijven is het bewijs dat het werk is geland. Dus “klaar” is niet langer iets wat de agent verklaart, maar iets wat het systeem waarneemt.
In de praktijk betekent dat drie gewoontes. Ten eerste: lees de eindstaat terug uit het doelsysteem — niet de respons van de call, maar de staat van het ding dat je veranderde. Ten tweede: behandel een timeout als onbekend, niet als mislukking; onbekend gaat naar een mens, wordt niet automatisch opnieuw geprobeerd. Ten derde, en dit is degene waar ik op blijf terugkomen: scheid de vrijheid om te redeneren van de bevoegdheid om uit te voeren. Een agent mag vrij nadenken, verkennen, van strategie veranderen. Hij mag niet zelf beslissen over credentials, budgetten of goedkeuringen. Hoe slimmer de agent wordt, hoe belangrijker het is dat die grenzen buiten hem liggen.
De meetlat waar niemand het over heeft
Er zit hier nog een tweede idee dat ik niet loslaat. Tokenkost is een waardeloze maatstaf voor de vraag of een agent de moeite waard is. Een run kan goedkoop zijn in tokens en toch duur, als hij mij vraagt het met de hand te verifiëren. De eerlijke meetlat is geverifieerde nuttige output per eenheid menselijke aandacht. Een stil “ok” zonder artefact kost me meer dan een tragere run die een bonnetje achterlaat.
Dat kantelt het hele ding. Het doel is niet om agents te bouwen die succes beweren. Het is om systemen te bouwen waarin succes iets is dat je kunt opzoeken.
Dus: hoe weet jij dat je agent echt klaar is? Vertrouw je de call, het logboek, of ga je de staat lezen?
Wat vond je van dit bericht?
