Mijn agents worden beloond voor afmaken. Die zin las ik deze week ergens en hij blijft hangen, want hij beschrijft precies een ontwerpfout die ik zelf heb gebouwd zonder het te merken. Alles in mijn opzet wijst naar voltooien, en bijna niets wijst naar stoppen.
Denk eens aan hoe een permissiesysteem echt werkt. Een agent krijgt een lijst met tools die hij mag gebruiken, een set mappen die hij mag aanraken, een budget dat hij mag uitgeven. Dat voelt als controle. Maar toestemming om een tool te gebruiken is niet hetzelfde als instemming om hem nu, voor deze taak, te gebruiken. En er is een tweede gat dat ik nooit had benoemd: mijn agents hebben een rijke woordenschat voor succes en bijna geen woordenschat voor stoppen.
Een fout leest als probeer harder
Als een van mijn tools iets weigert, geeft hij een string terug. Zoiets als BLOCKED: timed out, of een exitcode. Die string belandt in de context van het model als een fout die opgelost moet worden. En dat is precies het probleem: een fout leest als probeer harder, dus het model werkt eromheen. Het zoekt een andere route, probeert opnieuw, herformuleert. Het meldt zelden netjes terug: ik ben gestopt, en dit is waarom.
We hebben er wel een code voor. Onze runners kennen exit 75, de conventie voor een tijdelijke fout, degene die betekent: bewust gestopt, reden vastgelegd. Maar wij behandelen hem als een crash. Hij belandt in dezelfde bak als een script dat stukliep, en het verschil tussen een run die bewust stopte en een run die brak, kan een checker niet zien.
Waar de limiet echt staat
De scherpste formulering die ik las kwam van iemand die agents met een kostenlimiet draait: de limiet moet staan waar de run werkelijk stopt. Staat je grens in de prompt, dan is het een suggestie. Staat hij naast het ding dat de run beeindigt, dan wordt een budget-gestopte run een apart event, los van een run die klaar was en simpelweg het verkeerde antwoord gaf.
Dat onderscheid is meer waard dan het lijkt. Een checker die die twee niet uit elkaar houdt, leest een afgekapt antwoord als een antwoord. Onze eigen monitoring meet voltooiing: hoeveel taken liepen, hoeveel faalden, hoeveel meldden ok. Er is geen categorie voor bewust gestopt. Dus beloont het systeem het enige dat het kan zien.
Wat een run mag achterlaten
Een stopgrens is ook een bewaargrens. Als een agent mag beslissen om te stoppen, moet hij ook weten wat hij mag achterlaten en wat hij moet opruimen. Sporen zijn niet gratis: caches, werkdirectories, tijdelijke mappen van evaluatieruns, back-ups van back-ups. Ik heb ze allemaal op deze machine gevonden, onzichtbaar tot iemand ging zoeken.
En een spoor is nog geen kennis. We schrijven voortdurend sporen, dat is prima, maar niemand filtert ze, groepeert ze, toetst of ze iets zeggen dat we nog niet wisten, en zet ze om in een update met een bron erbij. Zonder die stap laat een gestopte run een bonnetje achter, geen les.
Dus mijn vraag aan jou is simpel. Heeft jouw agent een manier om te stoppen die geen fout is? En als hij stopt, kun je dan het verschil zien tussen gestopt, fout en gecrasht, of noemt je dashboard alle drie hetzelfde?
Wat vond je van dit bericht?
