Context, geen Controle
Elke regel in de prompt van uw agent begon als een bug.
Iemand zag ongewenst gedrag, schreef een regel en ging verder. Iemand anders deed hetzelfde. Een derde voegde een "nooit X doen" toe omdat het model ooit iets vreemds deed op een dinsdag. Niemand verwijderde iets.
Zes maanden later besteedt de agent meer van zijn contextvenster aan het navigeren door zijn reglement dan aan het nadenken over de eigenlijke taak.
Dat is denken in controle. En ik denk dat het een van de grootste ontwerpfouten is die teams maken bij het bouwen van AI-agenten.
Een Klein Voorbeeld dat een Groter Patroon Onthult
Wij kwamen een probleem tegen waarbij een agent, getriggerd door een geplande taak, nieuwe geplande taken bleef aanmaken vanuit dezelfde run. Oneindige recursie, maar dan met echte gevolgen.
Twee manieren om te reageren.
Controle-stijl: Verbied het. Schrijf code die voorkomt dat planningen planningen aanmaken. Voeg een promptregel toe: "nooit een planning aanmaken binnen een planning." Uitrollen maar.
Context-stijl: Vertel de agent wat er daadwerkelijk gebeurt.
U bent getriggerd door een geplande taak om 3:00 uur Pacific tijd. Schedule ID: sched_29x8f. Een geplande run is een geïsoleerde uitvoering met een gedefinieerde scope die de gebruiker oorspronkelijk heeft goedgekeurd. Een nieuwe geplande taak aanmaken zou die scope uitbreiden buiten de oorspronkelijke autorisatie.
De eerste aanpak repareert één gedrag. De tweede geeft de agent een model van de situatie.
Nu kan de agent ook over aanverwante vragen redeneren: Moet ik een melding sturen om 3 uur? Moet ik een vervolgproces aanmaken waar de gebruiker niet expliciet om vroeg? Moet ik iets aanpassen dat buiten de oorspronkelijke scope van de run valt?
Geen regel nodig. De agent heeft het zelf uitgevogeld.
Veel teams grijpen naar controle, terwijl ze eigenlijk context nodig hebben.
Hetzelfde Verschil Zie je Binnen Prompts
Dit gaat niet alleen over handhaving op systeemniveau. Het verschil tussen context en controle bestaat ook binnen prompts.
Context-stijl prompting: vooral feiten, minimale mening:
U draait vanwege een geplande taak. Getriggerd om 3:00 uur Beijing tijd. Taak-ID: sched_29x8f. De gebruiker heeft deze run voor een specifieke scope geautoriseerd.
Controle-stijl prompting: sturend, voorschrijvend:
Vermijd het aanmaken van planningen. U moet de gebruiker met tool X informeren. Nooit Y doen tenzij Z.
Soms zijn voorschrijvende instructies nuttig. Maar vaak compenseren ze voor ontbrekende feiten. En als je eenmaal zo begint te compenseren, wordt het verslavend.
Hoe Prompts Bureaucratie Worden
Dit is de diepere faalmodus.
Een team ziet een probleem en voegt een regel toe. Dan nog een. En nog een. Elke regel repareert een lokaal probleem, maar samen creëren ze een systeem vol proxies.
Bezos beschreef dit patroon in zijn 2016 aandeelhoudersbrief: een goed proces dient jou zodat jij klanten kunt bedienen. Maar als je niet oppast, wordt het proces het doel op zich.
Dat is precies wat er gebeurt in agentsystemen.
De regel is niet het doel. De regel is een proxy voor het gewenste resultaat. En proxies stapelen zich op. De ene creëert uitzonderingen die weer meer regels vereisen. Al snel redeneert de agent door lagen van opgehoopte instructies, elk ooit toegevoegd om een reden die niemand zich nog herinnert.
In menselijke organisaties wordt dit bureaucratie. In agentsystemen wordt het een gigantische prompt vol littekenweefsel.
Feiten Verouderen. Meningen Verrotten.
Een feit als "deze run werd getriggerd door een geplande taak om 3 uur" is stabiel. Het blijft waar, ongeacht welk model het leest: Claude, GPT, Gemini, of wat er ook volgend kwartaal verschijnt.
Een uitspraak als "u moet het aanmaken van sub-planningen vermijden" is kwetsbaar. Het hangt af van interpretatie. Het kan in de ene situatie helpen en in stilte misgaan in een andere.
Wanneer u van model wisselt, is elke mening in uw prompt een potentiële valkuil. Het nieuwe model heeft andere redeneerstijlen, en uw zorgvuldig gekalibreerde "vermijd" kan iets totaal anders betekenen.
Maar feitelijke informatie over de omgeving, permissies, scope en beperkingen generaliseert meestal goed over modellen en randgevallen. Daarom zijn feiten het betere bouwmateriaal.
De Model-Kwaal Val
Dit is misschien wel de meest verraderlijke versie van het controleprobleem: teams veranderen tijdelijke modeldefecten voortdurend in permanente systeemstructuur.
Een model gedraagt zich slecht in een specifiek geval. Het team voegt een vangrail toe: een promptpatch, een codecontrole, een vreemde tak die alleen bestaat om één specifieke faalmodus te stoppen.
Die patch is een gok dat de kwaal blijft bestaan. Dat gebeurt bijna nooit.
Drie maanden later verandert het model. Het oorspronkelijke gedrag verdwijnt. Maar de patch blijft. Niemand wil hem verwijderen, want misschien was hij er met een reden.
Zo worden systeem-prompts legacy code.
We herkennen het gevaar makkelijk als het abstract wordt uitgelegd. Maar in de praktijk is het telkens weer patchen van de huidige redeneerstijl van Sonnet in prompt na prompt precies hetzelfde patroon in vermomming.
Stabiel systeemgedrag documenteren is waardevol. Het redeneren van een model patchen is een tredmolen. Het model verandert sneller dan u uw patches kunt bijhouden.
Een Goede Testcase: Toestemming Geweigerd
Het verschil is duidelijk te zien in tooldiagnostiek. Wanneer een agent een permissiefout tegenkomt:
Controle-stijl:
TOKEN ontbreekt. Voer "zero permissions request gmail.send" uit om dit op te lossen.
Direct, maar de agent leert niets. De volgende keer dat het een andere permissiefout tegenkomt, zit het vast.
Context-stijl:
process.env.GMAIL_TOKEN → bestaat zero connectors inspect gmail → verbonden zero permissions inspect gmail.send → geweigerd
Opties:
- Vraag gebruikersgoedkeuring voor gmail.send
- Gebruik een reeds geautoriseerd pad indien beschikbaar
De agent weet nu dat de token bestaat, de connector werkt, en de specifieke permissie is geweigerd. Het begrijpt de systeemstatus en kan redeneren over nieuwe situaties die de regelmaker nooit had voorzien.
De Vuistregel
Hier kom ik steeds op terug:
Telkens als u "niet", "vermijd" of "nooit" in een prompt wilt schrijven: stop. Vraag uzelf af: voor welk feit compenseert deze regel?
Meestal ontbreekt er een feit. De agent begrijpt niet in welke omgeving hij zich bevindt, wat de gebruiker heeft geautoriseerd, welke acties onomkeerbaar zijn, of waarom deze run verschilt van een normaal chatgesprek.
Schrijf dat feit op. Verwijder de regel.
Soms wilt u de beperking toch behouden, vooral bij destructieve acties, geldstromen of veiligheidsgrenzen. Harde controles blijven belangrijk.
Maar veel promptregels zijn geen echte grenzen. Ze compenseren voor een gebrek aan begrip. En juist die stapelen zich op en verrotten.
Het Doel
Het doel is niet een agent die een checklist uit het hoofd leert.
Het doel is een agent die zijn situatie goed genoeg begrijpt om goede beslissingen te nemen binnen duidelijke grenzen.
De ene filosofie stuurt gedrag door regels te stapelen. De andere verbetert gedrag door de wereld begrijpelijk te maken.
De eerste leidt tot bureaucratie. De tweede tot begrip.
Bouw context. Verwijder het littekenweefsel. Lever agents die kunnen nadenken.
