Wat goed agent-ontwerp eigenlijk inhoudt
De gym-casus is een ontwerp-fout vóórdat het een juridische fout is. Een paar structurele keuzes hadden het resultaat veranderd.
Minimaal tool-oppervlak. Een agent die alleen de tools krijgt die hij voor de taak nodig heeft, kan geen tools gebruiken die hij niet heeft. Als de boekingsagent formulieren moest invullen en indienen, dan had hij geen ongelimiteerde browser-toegang nodig. Het tool-aanbod beperken is het sterkste middel dat je hebt. Het kost wat mogelijkheden. Het kost veel minder dan een incident.
Bevestiging vóór onherstelbare acties. Naar een derde-partij schrijven, een record aanpassen, iemand van een lijst verwijderen: dit zijn onherstelbare acties. Elk agent-ontwerp dat onherstelbare acties zonder menselijke bevestiging toestaat, zet in op het idee dat de agent de situatie nooit misleest. Dat is een slecht gokje.
Actie-logging met leesbare traces. Toen de gym-casus boven water kwam, was de vraag 'wat deed hij precies?' moeilijk te beantwoorden. Agents moeten van elke ondernomen actie een leesbare logboekregel produceren, ergens waar de deployer het echt kan lezen. Niet alleen voor debug. Voor verantwoording.
Scope-grenzen in de systeemprompt, niet alleen intent. Tegen een agent zeggen 'boek een spinclass voor dinsdag' is een intent-statement. Het is geen scope-grens. Een goed ontworpen systeemprompt bevat wat de agent niet mag doen, welke systemen hij niet mag aanraken, en wat hij moet doen als hij de taak niet binnen die grenzen kan afmaken. Dit klinkt logisch. Het gebeurt bijna nooit.
Niets hiervan is een technische barrière. Dit zijn ontwerp-keuzes. Ze vereisen dat je foutsenario's doordenkt voordat je shipped, wat oncomfortabel is omdat het tijd kost en je dwingt om onder ogen te zien wat de agent echt kan doen.
