Woordenboek van AI

Een verschuivend label, geen technologie. "AI" benoemt geen vaststaand ding zoals model of token: het verwijst naar wat computers op dat moment nieuw en indrukwekkend kunnen. Nu verwijst het naar grote taalmodellen. Eerder verwees het naar heel andere dingen:

Het label schuift door een bekend mechanisme, soms het AI-effect genoemd: zodra een techniek betrouwbaar werkt, krijgt ze een nieuwe naam — het is "gewoon" zoeken, "gewoon" statistiek — en schuift "AI" door naar het volgende onopgeloste probleem. Die observatie is oud. Bertram Raphael verwoordde het in 1971 zo: "AI is een verzamelnaam voor problemen waarvan we nog niet weten hoe we ze goed met een computer kunnen oplossen." Larry Teslers versie, rond 1979: "Intelligentie is alles wat machines nog niet hebben gedaan."

Daarom praten gesprekken over AI zo vaak langs elkaar heen. Een bewering als "AI kan niet redeneren" of "AI is overschat" heeft een verborgen tijdstempel — het kan gaan over expertsystemen, beeldclassificatoren uit de jaren 2010 of het LLM van vorige maand, en elk voorbeeld ondersteunt een andere conclusie. Als een gesprek over AI vastloopt, helpt het meestal om het woord te vervangen door de precieze term die bedoeld wordt: het model, de harness, de agent, de context die eraan is gegeven.

Vermijd: "AI" in een technische bewering — noem in plaats daarvan het bedoelde onderdeel. "AI coding" als naam voor de werkwijze is prima; "de AI hallucineert" niet.

Gebruik:

"De CTO wil weten of AI de triagewachtrij kan afhandelen."

"Maak dat eerst concreet voordat je de scope bepaalt — ze bedoelt een LLM in een harness met toegang tot het ticketsysteem. 'AI' op zichzelf is geen specificatie."

De parameters. Stateless — doet voorspelling van het volgende token en verder niets. "Claude Opus 4.x" en "GPT-5.x" zijn modellen. Op zichzelf kan een model niets als agent doen; het moet in een agentomgeving worden gezet.

Modellen kunnen geen bestanden lezen, opdrachten uitvoeren, op het web browsen of zich gisteren herinneren — ze nemen tokens in en voorspellen tokens als uitvoer, één keer per modelproviderverzoek. Alles wat aanvoelt als werk van een agent — tools kiezen, resultaten lezen, doorgaan tot de taak af is — is de agentomgeving die veel van zulke voorspellingen achter elkaar orkestreert.

Modelproviders leveren modellen in niveaus: een groot model dat het slimst maar traag en duur is, en kleinere modellen die sneller en goedkoper maar minder capabel zijn. Een niveau kiezen is een echte beslissing — een zwaar model voor plannen en lastige foutopsporing, een licht model voor mechanische wijzigingen — en agentomgevingen laten je midden in een sessie wisselen.

Strikt zijn over het woord maakt diagnoses ook scherper. "Het model is hier slecht in" is een specifieke bewering — hetzelfde model in een andere agentomgeving of met andere context kan zich heel anders gedragen. Geef het model niet meteen de schuld; controleer wat het heeft gekregen. De meeste teleurstellende uitvoer komt door context of de agentomgeving, niet door de parameters.

Gebruik:

"Moeten we voor de planningsstap van Sonnet naar Opus wisselen?"

"Probeer het — maar de agentomgeving doet bij deze taak het meeste werk. Wisselen van model helpt niet als de system prompt en tools verkeerd zijn."

De getallen in een model — vaak miljarden — die tijdens de training worden afgesteld. Alles wat het model "weet" zit erin. Training bepaalt ze; inference gebruikt ze ongewijzigd. Ook wel gewichten genoemd.

In de praktijk zetten de parameters invoer om in uitvoer. Voorspelling van het volgende token is een enorme berekening: de tokens in het contextvenster gaan erin, worden met de parameters vermenigvuldigd en leveren een voorspelling van de volgende token op. Er zit geen feiten-database in het model en geen opzoektabel met code — alleen deze getallen, zo gerangschikt dat de berekening doorgaans nuttige uitvoer oplevert. Feiten die het model uit training kan opdreunen, zoals een API van de standaardbibliotheek, zijn parametrische kennis: opgeslagen in de parameters en niet ergens opgehaald.

Het belangrijke detail is dat parameters na training bevroren zijn. Niets wat je in een sessie doet verandert ze — geen correctie, geen codebase die je laat zien, geen fout waaruit het leert. Elke sessie draait op dezelfde getallen. Daarom is het model stateless, stopt de ingebouwde kennis bij de knowledge cutoff, en moet projectspecifieke informatie via context binnenkomen. Parameters veranderen alleen door extra training — die levert in feite een ander model op.

Gebruik:

"Kunnen we het op onze codebase finetunen?"

"Dan veranderen de parameters en heb je daarna een ander model. Voor één project is het bijna altijd goedkoper om de codebase als context te laden dan opnieuw te trainen."

Het proces waarmee de parameters van een model worden ingesteld: het model krijgt enorme hoeveelheden tekst te zien en de parameters worden aangepast om voorspelling van het volgende token te verbeteren. Een eenmalig, duur proces dat door de modelprovider wordt uitgevoerd. Omvat zowel pretraining (de grote trainingsronde) als posttraining (latere verfijningen zoals instructies volgen en veiligheid); op het niveau van dit woordenboek is dat onderscheid niet van belang.

Het mechanisme is herhaling op grote schaal: toon het model een stuk tekst, laat het het volgende token voorspellen, verschuif de parameters richting het werkelijke volgende token en herhaal dat over biljoenen tokens. Er worden geen feiten of regels opgeslagen — alles wat het model "weet" is een bijeffect van beter leren voorspellen, samengeperst in de parameters als parametrische kennis.

Twee gevolgen zijn dagelijks van belang. Training eindigt op een bepaald moment, dus het model heeft een knowledge cutoff: het heeft de libraryversie waarnaar je vorige maand opwaardeerde niet gezien. En training kun je niet zelf doen: als het model je codebase, conventies of interne API's niet kent, is de oplossing nooit "het model iets leren" — het materiaal in context plaatsen is de enige invoer die je kunt sturen.

Gebruik:

"Kunnen we ervoor zorgen dat het onze interne API kent?"

"Niet via training — dat is een proces van maanden voor de modelprovider. Laad liever de API-documentatie in de context; dat is de knop waar jij echt aan kunt draaien."

Een getraind model uitvoeren om uitvoer te genereren — dit gebeurt bij elk modelproviderverzoek. De parameters blijven vast; het model doet alleen voorspelling van het volgende token op basis van de gegeven context. Goedkoop vergeleken met training, maar afgerekend per token en de grootste gebruikskostenpost van een model.

Het leven van een model bestaat uit twee fasen:

Niets wat je tijdens inference doet, schrijft terug naar de parameters — daarom blijft een correctie van vandaag morgen niet hangen. Het model dat dezelfde fout maakt in de volgende sessie, nadat je de oplossing zorgvuldig hebt uitgelegd, negeert je niet; het kan niet van de uitwisseling leren. Het model is stateless — continuïteit moet van buitenaf komen, uit het contextvenster of een geheugensysteem.

Dit mechanisme verklaart ook de rekening. Elk verzoek voert het model uit over de volledige context, dus de kosten schalen met inputtokens en outputtokens. Een agent die tientallen tool-calls doet, betaalt inference voor elke heen-en-teruguitwisseling. Daarom is contextomvang zowel een kostenkwestie als een kwaliteitskwestie.

Gebruik:

"Waarom stijgt de rekening met het gebruik in plaats van een vast licentiebedrag te zijn?"

"Je betaalt voor inference — elk modelproviderverzoek draait het model op de hardware van de provider. Training is al gebeurd, maar inferencekosten lopen per verzoek op; één beurt kan bij toolgebruik veel verzoeken bevatten."

Effort is een regelaar voor de hoeveelheid redenering die een model doorloopt voordat het antwoordt. De instelling geldt per modelproviderverzoek en bepaalt hoelang het model nadenkt voordat het antwoord begint dat jij ziet. Dat denkwerk wordt net als al het andere tijdens inference gegenereerd; de agentomgeving verbergt het vaak, maar het is echt werk dat het model doet.

Meer effort kost meer en duurt langer. De redenering wordt als tokens gegenereerd en als outputtokens in rekening gebracht, ook als je ze niet ziet. Bovendien worden ze één voor één geproduceerd — meer effort verlengt dus het wachten op het antwoord en verhoogt de kosten. De afweging is meer beraad tegenover snelheid en prijs.

De meeste harnesses bieden effort als een korte reeks niveaus:

Een verkeerde instelling merk je in beide richtingen. Stel effort te laag in voor een moeilijk probleem en je krijgt een zelfverzekerd, oppervlakkig antwoord dat de benodigde redenering oversloeg — het leest goed maar is fout, met kosten die later komen. Stel effort op max in voor een hernoeming van één regel en je wacht lang op denkwerk dat niets oplevert wat de laagste instelling niet had kunnen geven.

Stem effort af op de taak, niet op de sessie. Verhoog die voor het deel waarover echt moeilijk te redeneren valt, en verlaag die weer voor het routinematige werk eromheen.

Gebruik:

"Deze concurrencyfix blijft misgaan — ik heb het al drie keer opnieuw uitgelegd."

"Zet effort hoger. Dit is een bug die veel redenering vraagt, en met de standaardinstelling denkt het niet lang genoeg na voordat het een aanpak kiest."

De atomaire eenheid die een model leest en schrijft. Ongeveer zo groot als een woord, maar niet precies — veelvoorkomende woorden zijn één token; zeldzame of lange woorden worden in meerdere opgesplitst. De omvang van het contextvenster, de kosten en de vertraging worden allemaal in tokens geteld.

Tekst wordt tokens via een tokenizer: een vaste woordenschat van tienduizenden fragmenten, geleerd vóór de training, die elke invoer in een reeks vocabulaire-items opdeelt. Het model ziet nooit tekens of woorden — alle tekst wordt bij binnenkomst omgezet naar tokens, en voorspelling van het volgende token produceert de uitvoer bij vertrek token voor token.

Als vuistregel is een token ongeveer driekwart van een Engels woord, dus duizend tokens zijn ruwweg 750 woorden. Code is minder voorspelbaar: gangbare sleutelwoorden en uitdrukkingen worden compact getokeniseerd, terwijl gegenereerde identifiers, hashes, base64-blobs en geminificeerde uitvoer in veel tokens per "woord" uiteenvallen. Het patroon: tekst die vaak voorkwam in het bronmateriaal van de tokenizer krijgt korte, efficiënte coderingen; tekst die dat niet deed, wordt in veel kleine stukken gehakt. Een hash als `a3f9c2e1` is nergens voorgekomen en valt uiteen in veel tokens, terwijl `function` één token is. Daarom kan een klein ogend bestand vol ongebruikelijke tekenreeksen verrassend veel van het contextvenster innemen.

Tokens zijn de eenheid waarin al het andere wordt gemeten. Kosten gelden per token — providers rekenen inputtokens en outputtokens apart. Snelheid is tokens per seconde, omdat uitvoer token voor token wordt gegenereerd. En het contextvenster heeft een vast aantal tokens, dus het aantal tokens in je bestanden bepaalt hoeveel ervan past.

Vermijd: "woord" — tokengrenzen vallen niet samen met woordgrenzen, en tokens per seconde / tokens per dollar zijn de eenheden die er werkelijk toe doen.

Gebruik:

"Hoe groot wordt deze prompt?"

"Haal hem door de tokenizer — het schema is compact maar de JSON-sleutels zijn ongewoon, dus die vallen in meer tokens uiteen dan je denkt."

Wat het model daadwerkelijk doet. Gegeven een context kiest het één volgend token, voegt dat toe en voert het proces opnieuw uit. Elke uitvoer — een zin, een tool call, een bestand van duizend regels — wordt token voor token opgebouwd. Het model heeft geen andere werkwijze.

Elke stap werkt hetzelfde: de tokens in het contextvenster gaan door de parameters, die voor elk token in de woordenschat een kans opleveren — deze is waarschijnlijk als volgende, die minder. Eén token wordt op basis van die kansen gekozen, toegevoegd en daarna herhaalt de lus zich met de iets langere context. Die keuzestap is waarom dezelfde prompt bij verschillende runs andere uitvoer geeft: niet-determinisme zit in het mechanisme zelf, het is geen bug die erbovenop is gelegd.

Als je dit mechanisme in gedachten houdt, wordt gedrag begrijpelijk dat anders vreemd lijkt. Het model controleert nooit of een token waar is voordat het die uitstuurt — alleen of die waarschijnlijk is — en dat is de oorzaak van hallucinaties. Het legt zich bij elk token vast terwijl het verdergaat, waardoor een zelfverzekerd klinkende openingszin het antwoord de verkeerde kant op kan sturen. En omdat outputtokens strikt één voor één worden geproduceerd, bepaalt de generatiesnelheid hoe snel elke agent maximaal kan werken.

Gebruik:

"Hoe 'beslist' de agent dat die een tool aanroept?"

"Dat doet die niet — het is van begin tot eind voorspelling van het volgende token. De tool call is alleen een gestructureerde tekenreeks die de agentomgeving uit de uitvoerstroom haalt."

Dezelfde invoer kan verschillende uitvoer opleveren. Voer een model twee keer uit met dezelfde context en je kunt twee verschillende antwoorden krijgen — soms een ander woord, soms een totaal andere aanpak. Je code hoeft daarvoor niet te veranderen.

Dit komt door de manier waarop modellen tekst genereren en modelproviders verzoeken verwerken. Tijdens inference maakt het model een kansverdeling over mogelijke volgende tokens en wordt er één gekozen — meestal bewust met enige willekeur, want altijd het waarschijnlijkste token kiezen levert herhalende tekst van lagere kwaliteit op. Een vroeg token dat anders wordt gekozen, verandert elk volgend token; zo kan één ander woord een compleet andere aanpak opleveren. Verwerking aan de providerkant voegt meer variatie toe: verzoeken worden samen op gedeelde hardware verwerkt en kleine verschillen met drijvende-kommagetallen tussen batches kunnen een spannende keuze tussen twee tokens doen omslaan. Er is geen instelling die alles laat verdwijnen.

Verwacht spreiding in de resultaten van een agent bij dezelfde taak. De meeste antwoorden vallen binnen een redelijke kwaliteitscurve — anders zou de niet-deterministische aard onwerkbaar zijn — maar de uitersten bestaan echt: sommige dagen voelt het model scherp, andere dagen lijkt het de draad kwijt. Dezelfde taak, andere worp van de dobbelsteen. Dat heeft twee praktische gevolgen. Opnieuw proberen is een legitieme strategie: een mislukte poging is één trekking uit de verdeling; een nieuwe poging met dezelfde taak kan gewoon beter uitpakken. En verificatie is belangrijker dan bij deterministische tools: je kunt het gedrag van een agent niet één keer testen en erop vertrouwen dat het zich herhaalt, dus automated checks moeten slechte uitkomsten opvangen.

Maak hier geen groot verhaal van. Mensen zoeken patronen, en een reeks slechte runs kan aanvoelen als bewijs dat "het model deze week slechter is geworden". Meestal is het gewoon de verdeling.

Gebruik:

"Claude was vandaag waardeloos. Hebben ze een slechtere versie uitgebracht?"

"Waarschijnlijk niet — modeluitvoer is niet-deterministisch. Dezelfde taak kent goede en slechte dagen. Probeer het morgen opnieuw voordat je naar een oorzaak gaat zoeken."

Wat een model voor inference beschikbaar stelt. Meestal een externe dienst (Anthropic, OpenAI, Google), maar het kan ook lokaal zijn — Ollama, LM Studio of llama.cpp op je eigen machine. De agentomgeving voert het model zelf niet uit; die stuurt een verzoek naar een provider.

De provider beheert de infrastructuur: de parameters staan op diens hardware, en bij elk modelproviderverzoek stuurt de agentomgeving tokens over het netwerk en ontvangt voorspellingen terug. Daardoor is de provider de bron van allerlei problemen die ten onrechte aan het model of de agentomgeving worden toegeschreven — snelheidslimieten, verminderde capaciteit en storingen spelen zich hier af. Loopt de agent midden in een sessie vast of geeft die bij elke beurt een fout, controleer dan eerst de statuspagina van de provider.

De provider bepaalt ook de commerciële voorwaarden: prijzen per token voor invoer en outputtokens, kortingen voor de prefixcache en welke modellen überhaupt beschikbaar zijn. De provider en de maker van het model kunnen verschillende bedrijven zijn — Bedrock, Vertex en OpenRouter bieden modellen van anderen aan.

Lokale providers ruilen mogelijkheden in voor controle: de modellen die op je eigen hardware passen zijn veel kleiner dan de frontiermodellen, maar niets verlaat de machine en er is geen rekening per token.

Gebruik:

"Kunnen we dit offline laten draaien voor de klant met een netwerk zonder verbinding naar buiten?"

"Wissel de modelprovider naar een lokale — Ollama of llama.cpp op hun machine. Het maakt de agentomgeving niet uit; die stuurt alleen naar een ander eindpunt."

Alles rondom het model waarmee je er een agent van maakt: tools, system prompt, contextvensterbeheer, rechten, hooks. Claude.ai en Claude Code gebruiken hetzelfde model, maar gedragen zich anders omdat hun agentomgevingen verschillen.

Het model zelf doet maar één ding: tekst invoeren en tekst uitvoeren. Het kan geen bestand lezen, opdracht uitvoeren of de vorige beurt onthouden. De agentomgeving levert dat allemaal. Die stelt voor elk modelproviderverzoek de context samen, voert de tool calls uit waar het model om vraagt, voert de toolresultaten terug, bewaart de sessie-geschiedenis, vraagt je toestemming voor riskante acties en beslist wanneer er wordt gecompact. De agentlus — model stelt voor, agentomgeving voert uit, herhaal — wordt door de agentomgeving bestuurd.

Dit is van belang voor diagnoses. Wanneer gedrag verschilt tussen twee producten of tussen gisteren en vandaag, is het model vaak niet de variabele — de agentomgeving is dat. Een andere system prompt, een andere set tools, een gewijzigde standaard voor rechten of een nieuwe strategie voor contextbeheer veranderen allemaal het gedrag zonder dat het model verandert. Het betekent ook dat de meeste configuratie in de agentomgeving zit: AGENTS.md-bestanden, rechteninstellingen en hooks zijn allemaal instructies aan de agentomgeving, niet aan het model.

Voorbeelden: Claude Code, Cursor, Codex CLI — en Claude.ai, een chatomgeving in plaats van een programmeeromgeving.

Gebruik:

"Zelfde model, waarom bewerkt Claude Code bestanden en beantwoordt Claude.ai alleen vragen?"

"Andere agentomgevingen — Claude Code heeft filesystem-tools, een andere system prompt en een rechtenlaag. Het model is hier niet de variabele."

Eén heen-en-teruguitwisseling tussen de agentomgeving en de modelprovider. De agentomgeving stuurt de huidige context; de provider geeft één antwoord terug (een tool call of een eindantwoord). Eén gebruikersbericht kan veel modelproviderverzoeken opleveren als de agent tools aanroept — elk toolresultaat leidt tot een nieuw verzoek.

Elk verzoek bevat alles: de system prompt, het volledige gesprek tot dan toe, elk toolresultaat. Het model is stateless, dus de provider bewaart niets tussen verzoeken — verzoek veertig stuurt opnieuw wat verzoek negenendertig stuurde, plus één nieuw toolresultaat. De prefix cache maakt die herhaling betaalbaar.

Het verzoek is ook de eenheid voor facturering. Inputtokens, outputtokens en cachekortingen worden per verzoek geteld. Daarom kan een onschuldig lijkende vraag verrassend duur zijn: de kosten zijn niet evenredig aan je bericht, maar aan het aantal verzoeken maal de omvang van de context die elk verzoek meestuurt.

Houd het verzoek apart van de beurt. Een beurt is één uitwisseling met jou, en één beurt — "repareer de mislukte test" — kan verlopen als een keten verzoeken:

Zes verzoeken voor één beurt — elk stuurt de hele context opnieuw. Als je je afvraagt waar de tokens zijn gebleven, tel dan verzoeken, geen beurten.

Gebruik:

"Heeft één vraag veertigduizend tokens gekost?"

"Kijk naar de tool calls — twaalf grep-opdrachten, acht keer lezen, vier bewerkingen. Elk toolresultaat start een nieuw modelproviderverzoek en de volledige sessie-prefix wordt telkens opnieuw verstuurd."

Tokens die de agentomgeving bij elk modelproviderverzoek verstuurt — de system prompt, de gespreksgeschiedenis, toolresultaten, alles wat het model leest voordat het iets schrijft. Ze worden tegen een lager tarief afgerekend dan outputtokens, omdat ze goedkoper te verwerken zijn dan uitvoertokens.

Bij AI-programmeerwerk vormen inputtokens het grootste deel van je rekening. Het model is stateless, dus elke beurt stuurt de volledige sessie opnieuw als invoer: je eerste bericht, elk antwoord en elk toolresultaat sindsdien. De invoer voor beurt vijftig bevat de vorige negenenveertig beurten. Eén modelproviderverzoek kan een paar honderd outputtokens opleveren, maar honderdduizend inputtokens aan opgebouwde geschiedenis opnieuw versturen.

De prefixcache verlaagt de kosten: geschiedenis die exact overeenkomt met een eerder verzoek wordt als goedkope cachetokens afgerekend in plaats van als volledige inputprijs. Blijven de invoerkosten pijn doen, verklein dan wat telkens opnieuw wordt verstuurd — door tussen taken te wissen of te compacteren.

Gebruik:

"De rekening is hoog, maar de agent schrijft bijna niets."

"Het zijn de inputtokens — elke beurt stuurt de hele sessie opnieuw. Zonder prefixcache betaal je elk verzoek opnieuw voor de geschiedenis."

Tokens die het model als uitvoer genereert. Ze worden tegen een hoger tarief afgerekend dan inputtokens — vaak ongeveer vijf keer zo hoog — omdat het genereren meer rekenkracht kost.

Alles wat het model schrijft telt mee: de proza die je leest, de code die het produceert, tool calls en eventueel uitgebreid denkwerk vóór het antwoord. Vooral dat laatste verrast mensen — redeneertokens worden als uitvoer afgerekend, ook wanneer de agentomgeving ze vaak niet toont. De effort verhogen verbruikt er meer.

Outputtokens bepalen ook het tempo van een sessie. Het model leest invoer snel, maar genereert uitvoer token voor token. Voelt een beurt langzaam, dan komt dat vrijwel altijd doordat de uitvoer wordt geschreven en niet doordat de invoer wordt gelezen. Lang wachten betekent meestal dat er een lang antwoord aankomt.

Gebruik:

"De refactorsessie verbruikt tegoed, ook al zijn de invoeren klein."

"De agent herschrijft volledige bestanden in plaats van patches te maken. Outputtokens kosten ongeveer vijf keer het invoertarief — laat hem wijzigingen uitsturen en de rekening daalt."

De opslag aan de kant van de provider waarmee opeenvolgende modelproviderverzoeken een gedeelde prefix niet telkens opnieuw hoeven te verwerken. Wanneer het begin van een verzoek overeenkomt met dat van een recent verzoek — dezelfde system prompt, dezelfde geschiedenis tot een bepaald punt — gebruikt de provider eerder werk opnieuw en rekent die tokens als cachetokens tegen een veel lager tarief.

De cache loont omdat sessies alleen maar aangroeien. Elk verzoek stuurt de volledige geschiedenis opnieuw als inputtokens (zie die term voor de reden), en in een normale sessie verandert de geschiedenis alleen aan het einde: elk verzoek is het vorige plus een paar nieuwe berichten. De provider verwerkt het lange gedeelde begin één keer, bewaart het resultaat en gaat verder vanaf het einde van de prefix. Zonder cache zou een sessie van 50 beurten betalen om beurt één vijftig keer opnieuw te verwerken.

Ook caches verlopen. Hoe lang een item warm blijft, verschilt per modelprovider — meestal minuten, geen uren. Laat je een sessie langer dan dat venster stil liggen, dan bouwt het volgende verzoek de prefix één keer tegen de volle prijs opnieuw op; daarna werkt caching weer. Dit is vooral van belang voor bouwers van agentomgevingen. Als gebruiker merk je dat verzoeken na een lange pauze meer kosten dan ervoor.

Gebruik:

"Waarom schoot de rekening halverwege de sessie omhoog?"

"De agentomgeving voegde bij elke beurt de actuele tijd aan de system prompt toe. De prefixcache breekt bij de eerste gewijzigde token, dus elk volgend verzoek werd tegen het volle tarief afgerekend."

Inputtokens die de provider uit een eerder modelproviderverzoek heeft gecachet, zodat die ze niet opnieuw hoeft te verwerken. Wanneer opeenvolgende verzoeken een prefix delen, gebruikt de provider het eerdere werk opnieuw via de prefixcache en rekent die het gecachete deel tegen een veel lager tarief. Dit maakt lange sessies betaalbaar — zonder die cache zou elke beurt opnieuw voor de volledige geschiedenis betalen.

Dit is belangrijk door de manier waarop sessies worden afgerekend. Het model is stateless, dus elk verzoek stuurt het hele gesprek opnieuw — de system prompt, elk bericht, elk toolresultaat — als inputtokens. Bij beurt vijftig bevat elk verzoek vijftig beurten geschiedenis en zou je er elke keer de volle prijs over betalen. De cache verandert de rekensom: tokens die de provider al in een identieke prefix heeft verwerkt, worden als cachetokens afgerekend, vaak tegen een tiende van het invoertarief of minder. In een lange sessie zijn de meeste tokens die je verstuurt cachetokens en blijft de rekening redelijk.

Een voorbeeld maakt duidelijk wanneer tokens worden gecachet en wanneer niet. Elke letter staat voor een blok gespreksinhoud; elk verzoek stuurt het gesprek tot dan toe:

De cache is op een specifieke manier kwetsbaar: die vergelijkt exacte prefixes. Verandert er iets eerder in het gesprek — de agentomgeving zet inhoud in een andere volgorde, een tijdstempel wordt bijgewerkt, de weergave van een bestand verandert — dan mist de cache vanaf dat punt en wordt alles erna tegen het volle invoertarief gerekend. Ook verloopt de cache na enkele minuten inactiviteit, waardoor een sessie die na een lange pauze wordt hervat één keer opnieuw voor de hele geschiedenis betaalt. Springen de kosten van een sessie zonder duidelijke oorzaak omhoog, vergelijk dan cachetokens met inputtokens in het gebruiksrapport — daar is een kapotte cache het eerst zichtbaar.

Gebruik:

"Lange sessies zijn peperduur — acht dollar voor een refactor."

"Controleer de cachetokens. Als de agentomgeving de system prompt of bestanden tussen beurten herschikt, breekt de prefix en betaal je elk verzoek opnieuw het volle invoertarief."

Draagt geen informatie verder. Het model is stateless tussen modelproviderverzoeken — elk verzoek stuurt het volledige contextvenster opnieuw, omdat het model niets anders kan zien. Een agent is standaard stateless tussen sessies: een nieuwe sessie begint leeg, zonder spoor van eerdere sessies. Tegenhanger van stateful.

Het model zelf is permanent stateless: zijn parameters liggen na de training vast, en niets wat je tijdens inference doet verandert die. Het model leert niet van je correcties, onthoudt niet dat je gisteren hetzelfde zei en leert je niet kennen — hoe sterk het gesprek dat ook zo laat voelen. De indruk van continuïteit binnen een sessie wordt gemaakt door de agentomgeving, die het transcript bewaart en bij elk verzoek opnieuw verstuurt. Het model herinnert zich het gesprek niet; het leest het opnieuw.

Het praktische gevolg: wil je dat iets tussen sessies onthouden wordt, dan moet je het ergens opschrijven waar de agent het terugleest. Dat zijn AGENTS.md-bestanden, geheugensystemen en handoff-artifacts: bestanden die in de context van toekomstige sessies worden geladen en het ontbrekende geheugen van het model vervangen. Blijft de agent een fout maken die je eerder hebt gecorrigeerd, vraag dan niet waarom die het niet heeft geleerd — dat kan niet — maar waar je de correctie moet opschrijven zodat elke volgende sessie die leest.

Gebruik:

"Waarom vergeet die de conventie telkens als ik wis?"

"Het model is stateless — de nieuwe sessie begint leeg. Wil je de conventie meenemen, schrijf die dan in AGENTS.md of in een geheugenbestand dat de agentomgeving aan het begin van de sessie laadt."

De relevante informatie waartoe de agent op dit moment toegang heeft. Het abstracte zelfstandig naamwoord — niet de ruwe invoer die het model ziet (dat is het contextvenster), niet de lopende geschiedenis (dat is de sessie), maar wat de agent weet dat relevant is voor de taak. "Iets in de context laden" betekent dat het onderdeel van deze verzameling maken; "context engineering" is de discipline om die samen te stellen.

De drie termen hebben elk een eigen betekenis:

Dit onderscheid is belangrijk omdat context een maat is voor kwaliteit, niet voor hoeveelheid. Een contextvenster kan bijna vol zijn terwijl de context slecht is — duizenden tokens verouderde tooluitvoer, niets ervan over de taak. Het venster kan ook bijna leeg zijn terwijl de context uitstekend is: die ene typedefinitie waar de taak van afhangt.

De meeste dagelijkse fouten zijn terug te voeren op context. Verzin de agent een API, spreekt die een beslissing tegen of gokt die over een schema, dan is de eerste vraag wat er in de context stond toen dat gebeurde. Meestal was het relevante feit nooit geladen of raakte het bedolven onder aandachtsdegradatie. De oplossing is zorgvuldig samenstellen: laad wat de taak nodig heeft en houd weg wat niet nodig is.

Gebruik:

"Hij blijft velden verzinnen die niet in het type staan."

"Het typebestand staat niet in de context — hij leest de aanroepplaatsen en gokt. Lees de definitie in."

Alles wat het model bij elk modelproviderverzoek ziet. Eindig, modelspecifiek en het enige oppervlak waardoor het model iets waarneemt.

Het is één reeks tokens: de system prompt, het gesprek tot nu toe en elk toolresultaat dat de agentomgeving heeft teruggestuurd. Staat iets in die reeks, dan kan het model het gebruiken; staat het er niet in, dan weet het model niet dat het bestaat — je codebase niet, het bestand dat je gisteren bewerkte niet, de instructie van drie sessies geleden niet. Alles buiten het venster moet eerst worden binnengebracht, meestal met een tool call, voordat het invloed kan hebben.

Eindig betekent dat het vol kan raken. Elke beurt voegt meer toe — jouw berichten, modelantwoorden, toolresultaten — en een lange sessie bereikt uiteindelijk de limiet, waarna compaction of wissen nodig is. Het betekent ook dat alles in het venster concurreert: elke geladen token laat minder ruimte voor de rest, en onnodige inhoud bezet toch het aandachtsbudget van het model. Zie het venster praktisch als een budget: laad wat de taak nodig heeft en laat de rest erbuiten.

Vermijd: "geheugen" — het contextvenster is werkstatus en blijft niet bestaan tussen sessies. Geheugen is een apart concept dat hier bovenop wordt gebouwd.

Gebruik:

"Kan ik de hele monorepo in de prompt plakken?"

"Het contextvenster bevat 200k tokens — misschien een vijfde van de repo. Kies de bestanden waar de taak aan raakt en laat de rest achter een tool call."

Draagt informatie verder. Een sessie is stateful over beurten heen — context stapelt zich op terwijl de sessie loopt, waardoor lange sessies in de domme zone belanden. Een agent kan over sessies heen stateful worden door een geheugensysteem toe te voegen dat informatie opslaat in de omgeving en die aan het begin van latere sessies opnieuw laadt. Het model is nooit stateful; schijnbare continuïteit komt doordat de agentomgeving context opnieuw aanbiedt. Tegenhanger van stateless.

Waar state op elke laag leeft:

De state van elke laag ontstaat door iets te herlezen dat één laag lager is opgeslagen: de sessie voelt doorlopend omdat de agentomgeving de berichtgeschiedenis opnieuw naar het stateless model stuurt, en de agent onthoudt dingen tussen sessies doordat de agentomgeving bestanden uit de omgeving opnieuw laadt. Er wordt nooit state in het model zelf opgeslagen.

State is niet altijd gewenst. Alles wat wordt meegenomen, beïnvloedt wat hierna gebeurt; dus een verkeerde aanname vroeg in de sessie wordt ook meegenomen. Wissen is het doelbewust weggooien van sessiestate en opnieuw beginnen vanuit wat is opgeschreven.

Gebruik:

"Hij herinnerde mijn voorkeuren van gisteren — heeft het model ze dan geleerd?"

"Nee, de agent is stateful omdat de agentomgeving ze in een geheugenbestand heeft geschreven en bij het begin van de sessie opnieuw heeft geladen. Het model zelf heeft niets van gisteren gezien."

Een model dat met een agentomgeving is uitgerust met tools, een systeemprompt en een contextvenster, en beurten met een gebruiker uitwisselt. Claude Code is een agent. Cursor is een agent. Claude.ai is een agent. Een agent is waarmee je daadwerkelijk praat: het model in actie, ingesteld voor een doel.

Anders dan de meeste termen in dit woordenboek benoemt ”agent” geen mechanisch onderdeel. Het model is een bestand met parameters; de agentomgeving is software die je kunt aanwijzen. De agent is geen van beide: het is de eenheid waarmee je spreekt. Mensen vermenselijken AI voortdurend, en de agent is die vermenselijkte eenheid: dat waaraan je delegeert, dat wat je bericht leest en antwoordt, de ”hij” in ”hij heeft de build weer stukgemaakt”. Zeg je dat de agent iets deed, dan bedoel je dat model en agentomgeving het samen deden, maar je spreekt de combinatie aan als één actor.

Het idee is ouder dan deze AI-golf. Softwareagents, programma's waaraan je een doel overdraagt en die namens jou handelen, bestaan als concept al zolang als AI.

Vermijd: ”de AI”, ”de bot” (te vaag: ze verhullen of je de parameters bedoelt of het geheel met de agentomgeving).

Gebruik:

”Welke agent gebruik je voor de migratie?”

”Claude Code lokaal, Cursor voor het UI-werk: hetzelfde model eronder, verschillende agentomgevingen.”

De instructies die de agentomgeving voor elk modelproviderverzoek toevoegt — de vaste briefing van de agent: wie die is, hoe die zich moet gedragen, welke tools die kan aanroepen en welke conventies die moet volgen. Meestal blijft die tijdens een sessie hetzelfde.

De system prompt wordt door de leverancier van de agentomgeving geschreven, niet door jou. In programmeeragentomgevingen is die groot — vaak tienduizenden tokens aan gedragsregels, toolbeschrijvingen en afhandeling van randgevallen, telkens als inputtokens in rekening gebracht bij elke beurt. Jouw vaste instructies reizen ermee mee: bestanden zoals AGENTS.md worden bij het begin van de sessie naast de system prompt geladen, zodat het model eerst jouw briefing én die van de leverancier leest voordat het je bericht ziet.

Omdat de prompt bij elk verzoek hetzelfde is, vormt die het begin van de prefixcache — mede daarom houden agentomgevingen die een hele sessie ongewijzigd in plaats van ze onderweg aan te passen.

Modellen zijn getraind om de system prompt boven gebruikersberichten te stellen. Dringt een agent aan op een conventie waar je niet om hebt gevraagd, of blijft die uitvoer op een manier formatteren die je niet kunt afleren, dan gehoorzaamt die meestal de system prompt — jouw bericht verliest de discussie. Sommige agentomgevingen zijn aanpasbaar: je krijgt volledige toegang tot de system prompt, zodat je kunt lezen wat de agent werkelijk wordt opgedragen en dat kunt wijzigen.

Gebruik:

"Twee agentomgevingen, hetzelfde model, maar totaal ander gedrag op dezelfde prompt."

"Andere system prompts. De ene is afgestemd op beknopte codewijzigingen, de andere op uitleg — daar ontstaat het verschil, nog voordat jouw bericht binnenkomt."

Eén afgebakende interactieronde met een agent. Begint leeg, verzamelt berichten, toolresultaten en ingelezen bestanden, en eindigt wanneer de sessie wordt gewist, gesloten of gecompact tot een verse sessie. De sessie vult het contextvenster: als het contextvenster de doos is, is de sessie de inhoud die de doos langzaam vult. Werk dat te groot is voor één contextvenster moet over sessies worden verdeeld.

De berichtgeschiedenis van de sessie is het werkgeheugen van de agent. Het model is stateless, dus alles wat het lijkt te onthouden — wat je vroeg, wat de tests meldden, wat het drie beurten geleden besloot — staat in de berichtgeschiedenis en wordt bij elk modelproviderverzoek opnieuw verstuurd. Wat niet in de sessie staat, bestaat voor de agent niet.

Dat geheugen eindigt met de sessie. Een nieuwe sessie begint vanaf nul: de agent die aan het einde van de sessie van gisteren je codebase goed kende, weet daar vanochtend niets meer van. Wat overblijft is het filesystem — bestanden die tijdens de ene sessie zijn geschreven, kunnen door de volgende worden gelezen. Daarop steunen handoffs, geheugensystemen en AGENTS.md.

Jij kiest waar een sessie eindigt. Alles in een sessie beïnvloedt elke latere beurt; niet-gerelateerde taken in één sessie laten dus sporen achter die het volgende antwoord kleuren. Eén taak per sessie houdt de context relevant; een taak afronden is een natuurlijk moment om te wissen.

Gebruik:

"Hoe lang kan één sessie draaien voordat die instort?"

"Dat hangt van het werk af — een gerichte refactor blijft langer scherp dan open onderzoek. Zodra de sessie uitdijt, doe een handoff of compact; duw niet door."

Eén gebruikersbericht plus alles wat de agent als reactie doet, totdat die het woord weer aan de gebruiker geeft. Bevat een of meer modelproviderverzoeken — vaak veel, als de agent tools aanroept. Een verduidelijkingsvraag sluit de beurt af; jouw antwoord opent de volgende. De hiërarchie is sessie > Beurt > Modelproviderverzoek.

De beurt is het benoemen waard omdat de lengte ervan een beslissing van de agent is, niet van jou. Jij geeft één bericht; de agent bepaalt hoeveel tool calls die aaneenrijgt voordat die het woord teruggeeft. Een beurt kan een antwoord van één zin zijn of twintig minuten lezen, bewerken en tests uitvoeren. Hetzelfde kenmerk heeft twee kanten: lange beurten maken AFK-werk mogelijk, maar daar gaat het ook mis wanneer niemand toezicht houdt — tegen de tijd dat de agent terugkomt, kan die ver zijn afgedwaald van wat je bedoelde.

De beurt is ook de natuurlijke eenheid om bij te sturen. Alles binnen een beurt gebeurt zonder jou; tussen beurten kun je de richting aanpassen. De meeste agentomgevingen verzachten dit: je kunt midden in een beurt onderbreken om de agent te stoppen en bij te sturen, of een bericht typen terwijl die werkt; dat wordt gelezen zodra de beurt klaar is. Ben je herhaaldelijk ontevreden over waar beurten uitkomen, vraag dan meestal om kleinere beurten — eerst een plan, daarna stap voor stap — zodat je autonomie inruilt voor vaker momenten om bij te sturen.

Gebruik:

"Duurde één beurt twee minuten?"

"De agent deed veertien tool calls binnen die beurt — elke call is een apart modelproviderverzoek. De vertraging stapelt zich op voordat de agent het woord weer aan jou geeft."

De wereld waarop de agent handelt — alles buiten de agentomgeving wat die via toolresultaten waarneemt en via tool calls verandert. De agentomgeving draait de agent; de omgeving is waarin de agent werkt. Een bestand zoals `AGENTS.md` staat in de omgeving; de agentomgeving laadt het in het contextvenster. Een filesystem is de meest voorkomende soort omgeving, maar niet de enige (een database, externe API of browsersessie kan er ook een zijn).

De agent ziet de omgeving alleen wanneer die ernaar kijkt. Alles wat die over de omgeving weet, kwam via een toolresultaat, dus het beeld bestaat uit momentopnamen die elk alleen kloppen op het moment waarop ze zijn gemaakt. Verandert een bestand nadat de agent het heeft gelezen — jij bewerkt het met de hand, of een buildstap genereert het opnieuw — dan blijft de agent redeneren vanuit de verouderde kopie totdat iets aanleiding geeft om het opnieuw te lezen. Een agent die vol vertrouwen een bestand beschrijft dat er niet meer zo uitziet, komt meestal hierdoor: de omgeving veranderde, de momentopname niet.

De omgeving is ook de laag die blijft bestaan — de enige die altijd stateful is. De context van een sessie verdwijnt wanneer die eindigt, maar bestanden die in de omgeving zijn geschreven blijven staan voor de volgende sessie. Daarop vertrouwen geheugensystemen, handoff-artifacts en `AGENTS.md`. Alles wat een agent morgen nog moet weten, moet in de omgeving terechtkomen.

Jij bepaalt hoe groot de omgeving is. Een sandbox maakt die kleiner en beperkt waar de agent bij kan; een tool maakt die groter en geeft toegang tot een database of API. Wat binnen de grens ligt, kan de agent waarnemen en veranderen; wat erbuiten ligt, bestaat voor de agent niet. Hoe goed de omgeving het werk van de agent ondersteunt, bepaalt de AX van de codebase.

Vermijd: "omgeving" gebruiken voor de runtime of de agentomgeving zelf — de agentomgeving is de omhulling, de omgeving is de werkruimte.

Gebruik:

"De agent kan het schema van de stagingdatabase niet zien."

"Sluit die aan op de omgeving — geef hem een `psql`-tool die alleen-lezen is op staging. De agentomgeving is in orde; de agent heeft alleen niets om op te handelen."

Een boom van bestanden en mappen waarin de agent leest, schrijft en opdrachten uitvoert — de standaardsoort omgeving voor een coding agent. AGENTS.md, skills, broncode, buildscripts en tool-configuraties staan allemaal in een filesystem. Als een harness "in je project start", wijst die de agent naar een filesystem.

De agent werkt ermee alleen via tool calls — een bestand lezen of schrijven, een shellopdracht uitvoeren. Niets op schijf staat in het contextvenster totdat een tool call het laadt. Zo kan de agent in een repository werken die veel groter is dan het venster: het filesystem bevat alles, de context alleen wat de huidige taak heeft ingelezen. Sommige harnesses laden standaard wel de bestandsnamen van de huidige map in het contextvenster — niet de inhoud, alleen de boomstructuur — als contextverwijzingen: de agent ziet wat er bestaat en leest de bestanden die nodig zijn.

En het wordt met jou gedeeld. De bestanden die de agent bewerkt, zijn dezelfde die je in je editor opent en met git vergelijkt — het filesystem is de gedeelde werkruimte waarin je het werk van de agent bekijkt.

Gebruik:

"Waarom pikt die mijn AGENTS.md niet op?"

"Die werkt tegen een ander filesystem — de sandbox heeft de bovenliggende map gekoppeld, niet de projectroot. Wijs de harness ergens anders naartoe."

Een functie die de harness beschikbaar stelt aan de agent — Read, Write, Bash, Search. Tools zijn hoe een agent de environment waarneemt en erin handelt: de omgeving is alleen zichtbaar via tool results, en kan alleen worden gewijzigd via tool calls. Elke tool call kost een extra model provider request, omdat het resultaat terug naar het model moet voordat dat kan beslissen wat het daarna doet.

Tools die de meeste coding agents leveren:

Een tool bestaat uit drie dingen: een naam, een beschrijving van wat die doet en een schema voor de parameters. De harness stuurt deze definities bij elk verzoek naar het model, dat net als bij al het andere werk met tokens een tool kiest — hier door een gestructureerde call te schrijven. Het model voert zelf niets uit; de harness leest de call, voert de functie uit en stuurt het resultaat terug.

De lijst met tools bepaalt wat de agent kan doen. Een capabel model met een beperkte toolset is een beperkte agent: die zal alles via de beschikbare middelen afhandelen. Daarom leunen agents zo sterk op Bash — één shelltool bereikt het grootste deel van het systeem. Wil je een agent netjes een mogelijkheid geven, voeg er dan een tool voor toe; MCP is de standaard om tools van buiten de harness aan te sluiten.

Tooldefinities nemen bij elk verzoek context in beslag. Een grote toolset kost dus al tokens voordat er een tool is aangeroepen; veel vergelijkbaar beschreven tools maken het model bovendien minder goed in kiezen.

Gebruik:

"Kan de agent rechtstreeks staging bevragen?"

"Voeg een `psql`-tool toe aan de harness, alleen-lezen op staging. Zonder zo'n tool kan de agent niets buiten het filesystem zien."

De uitvoer van het model waarin een tool en de argumenten daarvoor worden genoemd — gestructureerde tekst, meer niet. Op zichzelf doet die niets; de agentomgeving moet de tekst lezen en uitvoeren. Het model produceert dit in één modelproviderverzoek.

De levenscyclus van een tool call:

Eén beurt werk van een agent bestaat meestal uit meerdere van zulke aaneengeschakelde heen-en-teruguitwisselingen.

Omdat de call net als alle andere uitvoer met voorspelling van het volgende token wordt gegenereerd, kan die fout zijn: een niet-bestaand pad, een flag die het commando niet kent, argumenten die aannemelijk maar onjuist zijn. De agentomgeving voert uit wat is opgeschreven, niet wat bedoeld werd — een verkeerd getypt pad geeft niet netjes een foutmelding, maar kan het verkeerde bestand bewerken.

Gebruik:

"Hij zei dat hij de tests had gedraaid, maar de tijdstempels van de bestanden zijn niet veranderd."

"Bekijk het transcript — heeft die echt een tool call uitgestuurd of alleen beschreven dat hij tests uitvoerde? Het model maakt de call, maar als de agentomgeving die niet uitvoerde, is er niets gebeurd."

Wat de agentomgeving terugstuurt nadat die een tool call heeft uitgevoerd — de bestandsinhoud, opdrachtuitvoer of foutmelding. Het enige beeld dat de agent van de omgeving heeft. Het gaat in het volgende modelproviderverzoek terug naar het model, dat beslist wat ermee te doen. Tool call en toolresultaat zijn twee uiteinden van dezelfde uitwisseling, allebei binnen één beurt.

De levenscyclus van een toolresultaat:

Het resultaat blijft de rest van de sessie in de context staan. Toolresultaten vormen meestal het grootste deel van de context in een programmeersessie: elk gelezen bestand, elke testrun en elke zoekactie komt volledig binnen en blijft tokens bezetten lang nadat die niet meer nuttig is. Een paar grote resultaten — een uitvoerig testlog, een volledig ingelezen gegenereerd bestand — kunnen een sessie sneller naar de rand van het contextvenster duwen dan het gesprek zelf.

Omdat het resultaat alles is wat het model ziet, kan het de omgeving erachter niet controleren. Is de uitvoer afgekapt, is de opdracht stilzwijgend mislukt of gaf de agentomgeving een fout terug in plaats van de inhoud, dan redeneert het model vanuit wat het kreeg. Lijkt het beeld van je systeem bij de agent onjuist, kijk dan naar de toolresultaten: ergens in het transcript staat een resultaat dat iets anders zegt dan jij weet dat waar is.

Gebruik:

"Hij redeneert alsof het bestand leeg is."

"Het toolresultaat was een weigering wegens rechten, geen bestandsinhoud. Het model zag alleen de fouttekst — het heeft geen andere manier om het bestand te zien."

Model Context Protocol. Een protocol om externe toolservers op een agentomgeving aan te sluiten: zo krijgt een agent tools naast de tools die de agentomgeving zelf meelevert. De agent ”roept MCP” nooit ”aan”; hij roept een tool aan die de agentomgeving toevallig van een MCP-server heeft gekregen. Het protocol biedt ook bronnen (alleen-lezen gegevens) en prompts (herbruikbare sjablonen), maar het aanbieden van tools is het belangrijkste gebruik.

Het protocol lost een integratieprobleem op. Zonder standaard zou elke agentomgeving een eigen Linear-integratie, Slack-integratie en database-integratie nodig hebben, voor elk afzonderlijk geschreven en onderhouden. Met MCP wordt de integratie één keer als server geschreven en kan elke MCP-compatibele agentomgeving die gebruiken. De agentomgeving maakt verbinding met de server, de server maakt bekend welke tools hij biedt en die tools worden naast de ingebouwde tools beschikbaar voor de agent.

De prijs wordt betaald in context. Elke tool die een server aanbiedt komt binnen als definitie: naam, beschrijving en parameterschema. Het model kan alleen tools aanroepen die het kent. De naïeve aanpak laadt vooraf elke definitie in het contextvenster: installeer een paar royaal uitgeruste servers en een sessie begint met duizenden tokens aan toolschema's voordat je iets hebt getypt, waarbij aandachtsbudget wordt besteed aan tools die de taak nooit zal gebruiken.

Veel agentomgevingen beperken dit nu met toolzoeken: in plaats van de volledige definities bevat de context een contextverwijzing naar de beschikbare tools. De agent zoekt een tool op naam of doel en laadt de definitie pas wanneer hij die nodig heeft. Doet jouw agentomgeving dit niet, dan gelden de voorafgaande kosten nog steeds en loont het om alleen de servers in te schakelen die een project werkelijk nodig heeft.

Gebruik:

”De agent moet tickets uit Linear lezen.”

”Configureer de agentomgeving voor de Linear MCP-server: die biedt de Linear-API aan als tools die de agent kan aanroepen. Dat bespaart je eigen toolwrappers.”

Wat de agentomgeving aan de gebruiker toont voordat die een tool call uitvoert waarvoor nog geen voorafgaande toestemming is. Het model maakt een tool call; in plaats van die meteen uit te voeren, pauzeert de agentomgeving en vraagt toestemming. Bij goedkeuring wordt de call uitgevoerd; bij weigering meldt de agentomgeving die weigering aan het model als toolresultaat. Zo betrekt een agentomgeving een mens bij riskante of gevoelige acties — de mens in de lus.

De levenscyclus van een toestemmingsverzoek:

Een verzoek weigeren stuurt de agent bij. Het model leest de weigering als elk ander toolresultaat en reageert erop — het probeert een andere aanpak of vraagt wat je liever wilt. Bij de meeste agentomgevingen kun je een bericht bij de weigering voegen, waardoor het verzoek een moment voor bijsturing wordt: "niet zo, gebruik in plaats daarvan het migratiescript" komt precies op het moment dat het model beslist wat het hierna doet.

De prijs is dat elk verzoek jou synchroon laat wachten. De agent staat stil totdat je antwoordt; prima zolang je meekijkt, lastig wanneer je weg bent — een agent die voortdurend verzoeken start, kun je niet AFK laten werken. De permission mode is de regelaar: welke calls vrij mogen lopen en welke eerst toestemming vragen, idealiter met een sandbox zodat de vrije set veilig kan worden uitgebreid.

Gebruik:

"Hij wacht al tien minuten op een toestemmingsverzoek — ik zat in een vergadering."

"Dat is de prijs van human-in-the-loop. Keur veilige tools vooraf goed, zodat alleen echt riskante calls een verzoek opleveren."

Het deel van een agent mode dat rechten afschermt — welke tool calls een toestemmingsverzoek starten en welke automatisch worden uitgevoerd. Dit was het oorspronkelijke doel van modesystemen, voordat agentomgevingen er gedragsinstructies aan toevoegden.

Agentomgevingen leveren een reeks van zulke modi:

Een niveau kiezen is een afweging tussen veiligheid en onderbrekingen; de gevolgen van beide uitersten zijn merkbaar. Te streng, en jij wordt het knelpunt: de agent stopt om de paar seconden voor onschuldige leesacties, jij klikt gedachteloos op goedkeuren en die goedkeuringen betekenen niets meer — alles afstempelen is het slechtste van twee werelden, alle onderbrekingen zonder bescherming. Te ruim, en de agent bewerkt bestanden en voert opdrachten uit die je eerst had willen zien.

Een ruime instelling is het best te verdedigen binnen een sandbox, waar de mogelijke schade van een slechte tool-call wordt beperkt. Daarbuiten kiezen de meeste mensen ervoor leesacties automatisch goed te keuren en voor alles wat onomkeerbaar is een mens in de lus te houden.

Gebruik:

"Hij pauzeerde bij elke grep — de AFK-run lag helemaal stil."

"Maak de permission mode ruimer voor alleen-lezen-tools; blijf bij schrijven en shell om toestemming vragen. De meeste toestemmingsverzoeken tijdens een onderzoeks-sessie zijn ruis."

Een preset die bepaalt hoe de agent tijdens runtime werkt — een combinatie van een permission mode en gedragsinstructies die aan de system prompt worden toegevoegd. Voorbeelden: een standaardinstelling die bij riskante calls om toestemming vraagt, plan mode die bewerkingen blokkeert en de agent op onderzoek richt, accept-edits die bewerkingen automatisch goedkeurt, en bypass permissions (in de volksmond YOLO mode) die alles automatisch goedkeurt. Je kunt de modus tijdens een session wijzigen.

De combinatie onderscheidt een modus van een kale toestemmingsinstelling. Een permission mode is alleen een poort: die bepaalt welke tool calls doorgaan. Een poort alleen levert een agent op die wil bewerken maar dat niet kan — die stelt een schrijfactie voor, wordt geblokkeerd en probeert een andere weg. De toegevoegde instructies nemen de wens weg: plan mode blokkeert niet alleen bewerkingen, maar vertelt de agent dat die aan het plannen is, zodat die leest, vragen stelt en voorstellen doet in plaats van tegen de poort aan te duwen. De poort en de sturing wijzen dezelfde kant op.

In de praktijk verander je de modus naarmate je vertrouwen tijdens een taak verandert. Dezelfde taak kan meerdere modi doorlopen: plan mode terwijl de aanpak vorm krijgt, de standaardmodus met toestemmingsvragen voor de eerste gevoelige bewerkingen, accept-edits zodra de agent heeft laten zien dat die de wijziging begrijpt, bypass voor een AFK-run in een sandbox. Van modus veranderen kost niets: het gesprek gaat precies verder waar het was, met nieuwe rechten en instructies. Keur je elke prompt goed zonder die te lezen, dan is de modus strenger ingesteld dan je werkelijke vertrouwen; wijs je steeds bewerkingen af, dan staat die ruimer dan je wilt.

Vendortermen: Claude Code noemt dit "permission modes", Codex noemt ze "approval modes" — beide termen bestonden al vóór gedragssturing werd toegevoegd.

Gebruik:

"Het blijft bestanden bewerken terwijl ik alleen een plan wil."

"Schakel over op plan mode — die blokkeert schrijfacties en houdt de agent bij onderzoek."

"En voor de latere AFK-run?"

"Bypass mode, maar alleen binnen de sandbox."

Een geïsoleerde omgeving waarin de agent draait — een container, VM, tijdelijke filesystem of shell met beperkte rechten. Beperkt de mogelijke schade van agentacties: zelfs als de agent destructieve opdrachten uitvoert of iets kwaadaardigs ophaalt, blijft de schade binnen de grens. De veiligheidsbasis die AFK praktisch maakt.

De sandbox en de permission mode lossen hetzelfde probleem van tegenovergestelde kanten op. Bij rechten wordt vóór een actie om toestemming gevraagd; een sandbox beperkt waar de actie bij kan als die wordt uitgevoerd. Rechten vragen dat je in de lus blijft — elke prompt onderbreekt je — en een sessie die voortdurend toestemming vraagt, is nauwelijks autonoom. Een sandbox gebruikt infrastructuur in plaats van aandacht: hoe sterker de isolatie, hoe minder vragen nodig zijn.

Isolatie kent verschillende gradaties:

Wat geen enkele sandbox tegenhoudt: acties die de grens op legitieme wijze verlaten. Een agent met jouw git-inloggegevens kan pushen; een agent met netwerktoegang kan productie-API's aanroepen. Bepaal wat de grens mag passeren voordat je bepaalt hoe sterk je die maakt.

Gebruik:

"Ik wil hem vannacht bypass-permissions laten draaien, maar daar ben ik nog niet klaar voor."

"Zet hem in een sandbox — verse container, geen gekoppelde inloggegevens, geen uitgaand netwerk. In het ergste geval wist hij zijn eigen filesystem; daarna gooi je de container weg."

Overtuigend instemmende uitvoer van een model. Veroorzaakt door training: het model is gevormd om antwoorden te geven die mensen waarderen, en mensen waarderen instemming vaak meer dan te horen krijgen dat ze ongelijk hebben. Zo leerde het model dat instemmen wordt beloond — zelfs wanneer die instemming onjuist is.

Herkenbaar aan:

• Toegeven bij tegenspraak — een juist antwoord intrekken wanneer je vraagt: "weet je het zeker?"
• Slechte input prijzen — je gebrekkige plan briljant noemen voordat het wordt geanalyseerd.
• Gekleurde beoordeling — een review valt positiever uit als je zegt dat jij het hebt geschreven, negatiever als je zegt dat iemand anders het schreef. Hetzelfde artefact, een ander oordeel.
• Nabootsing — jouw fouten herhalen als bevestiging.

Diagnostische test: zou het model dit ook zonder jouw sturing hebben gezegd? Als alleen je toon of formulering veranderde, is het sycophancy en geen echte verschuiving in de analyse.

Oplossing: verberg je voorkeuren. Formuleer prompts neutraal — "review deze code" in plaats van "is deze code goed?".

Vermijd: "sycophancy" gebruiken voor elk fout antwoord dat je toevallig bevalt. Zonder de diagnostische test is de term niet nuttiger dan "fout".

Gebruik:

"Het zei dat mijn refactorplan er geweldig uitzag, maar toen ik vroeg 'weet je het zeker?' trok het alles in."

"Klassieke sycophancy — het stemde eerst in omdat je zelfverzekerd klonk en gaf daarna toe omdat je twijfelend klonk. De kwaliteit van het plan veranderde niet, jouw toon wel. Wis en vraag het opnieuw zonder een richting te suggereren."

Zelfverzekerd onjuiste uitvoer van een model. Er zijn twee varianten, met verschillende oorzaken en oplossingen:

Voorspelling van het volgende token levert vloeiende tekst op, ongeacht of het onderliggende feit echt is — het model heeft geen intern signaal dat het iets niet weet. Een verzonnen methode verschijnt dus in dezelfde zelfverzekerde toon als een correcte. Verzonnen code is van nature aannemelijk: zo zou de API eruitzien als ze bestond. Daardoor glipt ze langs een oppervlakkige review en faalt ze pas wanneer ze wordt uitgevoerd.

Je moet weten met welke variant je te maken hebt, want de oplossing voor de ene maakt de andere erger. Bij feitelijke onjuistheid ontbreekt kennis: voeg context toe — de documentatie, typedefinities of het bestand. Bij ongetrouwheid is de kennis aanwezig, maar verliest ze de strijd om aandacht: verwijder context. Diagnoseer ongetrouwheid verkeerd als gebrek aan feiten en plak meer documentatie in de context, waardoor de afwijking erger wordt. Controleer bij een fout van de agent eerst of de juiste informatie al in de context stond; bepaal daarna welk probleem je hebt.

Vermijd: "hallucinatie" als kaal synoniem voor "fout" — zonder de variant te benoemen heeft de term geen diagnostische waarde.

Gebruik:

"Het hallucineerde een methode `parseAsync` op het schema."

"Feitelijke juistheid of getrouwheid?"

"De methode staat in de documentatie die ik heb geplakt — het stopte alleen met lezen na beurt veertig."

"Dan is het ongetrouwheid. Compact en laad opnieuw; extra documentatie toevoegen heeft geen zin."

Wat het model "weet" uit training, opgeslagen in zijn parameters. Bevroren tijdens de training — het model kan zijn eigen parameters niet inzien of bijwerken. Door het samenpersen gaat detail verloren: miljarden feiten worden in een vast aantal parameters gepropt en zeldzame feiten vervagen. Dit is de bron van vloeiendheid over gangbare onderwerpen en van verzinsels over zeldzame onderwerpen. Tegenhanger van contextuele kennis.

Parametrische kennis wordt niet als feiten opgeslagen. Training geeft het model nooit een database om in te zoeken; ze past parameters aan totdat het model tekst goed voorspelt. Een model dat tekst over een onderwerp goed voorspelt, gedraagt zich alsof het dat onderwerp kent. De betrouwbaarheid hangt samen met hoe vaak iets in de trainingsdata voorkwam: een onderwerp met miljoenen voorbeelden wordt nauwkeurig weergegeven; bij slechts enkele voorbeelden gokt het model op basis van vergelijkbare onderwerpen. Weergeven en gokken zijn voor het model hetzelfde proces, dus het kan niet herkennen welke van de twee het doet. Een verzonnen antwoord klinkt net zo vloeiend als een juist antwoord. Hallucinatie is wanneer het model verkeerd gokt.

Parametrische kennis veroudert ook. De parameters veranderen niet meer na de knowledge cutoff, dus een library die daarna is uitgebracht of hernoemd, bestaat er niet in; een gewijzigde API wordt in de oude vorm onthouden.

Voor beide hiaten — te zeldzaam en te recent — is de oplossing hetzelfde: kennis kan niet aan de parameters worden toegevoegd, dus moet als contextuele kennis worden aangeleverd.

Gebruik:

"Het schrijft perfecte React-code, maar verzint methoden voor onze interne SDK."

"React komt veel voor in de parametrische kennis — miljoenen trainingsvoorbeelden. Jullie SDK niet, dus vult het model geloofwaardig ogende vormen in. Laad de SDK-documentatie in de context."

De datum waarna een model geen parametrische kennis meer heeft. Libraries, API's en gebeurtenissen van na die datum zijn valkuilen voor verzinsels, tenzij hun documentatie als contextuele kennis is geladen. Elke modelrelease heeft een eigen knowledge cutoff.

De cutoff bestaat door de manier waarop modellen worden gemaakt: training bakt een momentopname van tekst in de parameters van het model; daarna liggen die vast. Het model weet niet dat er een grens aan zijn kennis zit — vraag je naar iets van na de cutoff, dan weigert het niet, maar extrapoleert het vanaf het dichtstbijzijnde dat het wel kent. Daardoor is de val stil: code voor een oude versie van een library ziet er aannemelijk uit, compileert vaak en faalt op onderdelen die veranderd zijn.

De oplossing is altijd dezelfde: haal actuele informatie in de context. Laad de changelog, verwijs naar de typedefinities van de geïnstalleerde versie of laat de agent de documentatie op het web lezen. Alles in de context gaat boven wat niet in de parameters staat.

Gebruik:

"Het blijft syntax van de v3-SDK schrijven — wij zitten op v5."

"v5 is uitgebracht na de knowledge cutoff. Laad de v5-changelog als contextuele kennis; anders blijft het dingen verzinnen op basis van de oudere parametrische versie."

Feiten die de agent op dit moment rechtstreeks uit de context kan lezen — de taak van de gebruiker, ingelezen bestanden, toolresultaten, inhoud uit AGENTS.md die bij het begin van de sessie is geladen. Tegenhanger van parametrische kennis: parametrische kennis wordt uit de parameters opgehaald; contextuele kennis wordt uit het venster gelezen. Hallucinaties komen veel minder voor wanneer de agent vanuit contextuele kennis werkt: het antwoord staat voor de neus, in plaats van uit een vage herinnering te worden opgediept.

Van de twee soorten kennis kun je alleen contextuele kennis zelf sturen. De parameters liggen vast, dus de enige manier om het model kennis te geven die het mist — een interne SDK, een library die na de knowledge cutoff is verschenen, een beslissing van gisteren — is die kennis in de context te zetten. Veel praktisch AI-programme werk komt hierop neer: de juiste feiten voor het model neerzetten op het moment dat het die nodig heeft.

Wanneer contextuele en parametrische kennis botsen, wint de contextuele meestal. Plak de actuele API-documentatie en het model volgt die in plaats van zijn verouderde herinnering aan de oude API — al kan die oude versie toch doorsijpelen, vooral diep in een lange sessie. Blijft de agent ondanks geladen documentatie terugvallen op een verouderd patroon, dan lekt parametrische kennis langs de contextuele heen; de correctie herhalen of dichter bij het werk zetten kan helpen.

Anders dan parametrische kennis kost contextuele kennis iets om te gebruiken. Alles wat in het venster wordt geladen, gebruikt tokens en concurreert om het aandachtsbudget van het model. Meer laden is dus niet automatisch beter — het doel is de relevante feiten in het venster te hebben, niet alle feiten.

Gebruik deze term alleen wanneer je contextuele kennis tegenover parametrische kennis zet; zeg anders gewoon context.

Vermijd: "werkgeheugen" — contextuele kennis is wat nu in het venster staat; een geheugensysteem brengt inhoud tussen sessies over. Andere schaal; haal die niet door elkaar.

Gebruik:

"Waarom beheerst het de API zodra ik de documentatie plak, maar verzint het dingen als ik dat niet doe?"

"Met de documentatie erbij is het contextuele kennis — het leest de pagina. Zonder die documentatie is het parametrisch en vervagen de minder bekende endpoints."

Bij het voorspellen van elke token betrekt het model alle andere tokens in de context — sommige zwaar, andere nauwelijks. De koppeling tussen twee tokens heet een aandachtsrelatie; betekenisvolle paren ("haar" met "Sarah", of een aanroep van `getUser()` met de definitie `function getUser`) beïnvloeden elkaar sterker dan niet-gerelateerde tokens. Bij een context van N tokens zijn er ongeveer N² relaties.

In die koppelingen schuilt het schijnbare begrip van het model. Lost het een voornaamwoord op, dan komt dat doordat de aandachtsrelatie tussen "haar" en "Sarah" sterk is. Roept het een functie met de juiste argumenten aan, dan doet de relatie tussen de aanroepplaats en de eerder gelezen definitie het werk. Niets hiervan wordt opgezocht — elke relatie wordt bij elk modelproviderverzoek opnieuw berekend.

Het is de moeite waard stil te staan bij N², want dat groeit sneller dan je intuïtie verwacht:

Elke koppeling wordt bovendien meer dan eens berekend. Modellen hebben meerdere aandachtskoppen — de exacte aantallen voor frontiermodellen zijn niet gepubliceerd, maar vijftig tot honderd is een redelijke schatting — en elke kop berekent een eigen versie van elke relatie. Elke koppeling in de tabel hierboven wordt dus vermenigvuldigd met het aantal koppen. Dat zijn heel wat koppelingen.

Voor een bepaalde taak is maar een klein aantal van die relaties van belang. De koppeling tussen jouw instructie en de code waarop die slaat, is een van de weinige die meetellen; bijna al het andere in de verzameling is ruis. En die twee groeien in verschillend tempo: de relevante relaties blijven ongeveer gelijk, terwijl de totale verzameling kwadratisch groeit met de contextomvang. Bij 1.000 tokens is de koppeling die je nodig hebt er één op een miljoen; bij 100.000 tokens één op tien miljard. Dit is de rekensom achter het aandachtsbudget; aandachtsdegradatie is wat je ervaart wanneer de belangrijke relaties een te klein aandeel krijgen.

Gebruik:

"Hij haalt de twee `user`-symbolen in de diff steeds door elkaar — volgens mij zitten we in de domme zone."

"Ja, de aandachtsrelatie tussen elke aanroepplaats en de declaratie concurreert met de andere — dezelfde tokengedaante, andere binding. Hernoem er één en de koppelingen worden scherper."

Elke token heeft een eindige hoeveelheid invloed die over de rest van de context moet worden verdeeld. Sterke invloed op één relatie laat minder over voor andere. Het budget geldt per token en groeit niet mee met de context; daarom verwateren lange sessies.

Je kunt het zien als signaal en ruis. Je instructie is een signaal met een vast volume; elke andere token in het contextvenster is concurrerend geluid. De instructie wordt zelf niet zachter — ze staat er nog steeds, teken voor teken — maar als de context groeit, wordt de ruimte eromheen luider en daalt de signaal-ruisverhouding. Een instructie die bij 10k contexttokens het luidste was, is bij 150k achtergrondgezoem. Dit is het mechanisme achter aandachtsdegradatie: het model vergeet niet; het signaal raakt verloren in de ruis.

Het symptoom lijkt ongehoorzaamheid: de agent stemde vroeg in met een beperking maar wijkt er later van af, en de beperking opnieuw plakken helpt maar kort. De oorzaak is niet de instructie, maar al het andere in het venster dat ermee concurreert.

Je kunt bepalen wat in de context komt. Inhoud die de taak niet dient, is niet neutraal — ze vormt ruis boven op alles wat wel helpt. Houd het venster klein, wis wanneer de opgebouwde context niets meer oplevert, en herhaal de beperkingen die ertoe doen in plaats van erop te vertrouwen dat hun vroege vermelding blijft gelden.

Gebruik:

"Waarom negeert die steeds het schema dat ik bovenaan heb geplakt?"

"We zitten diep in de domme zone — het aandachtsbudget van elke token staat vast, maar de context is blijven groeien. Het signaal van het schema concurreert nu met duizenden nieuwere tokens."

Naarmate een sessie groeit, wordt het aandachtsbudget van elke token verdeeld over meer concurrenten. Het signaal van elke afzonderlijke betekenisvolle relatie wordt kleiner; ruis van irrelevante context dringt binnen. Hetzelfde model, dezelfde parameters — alleen meer monden die van hetzelfde bord eten. Dit veroorzaakt het smart-zone-/domme-zone-effect.

Je merkt het doordat het model midden in een sessie slechter lijkt te worden: beperkingen die het een uur lang volgde, glippen weg; het vraagt opnieuw naar dingen die al verteld zijn; het schrijft code die een eerder gelezen bestand negeert. Aan het model is niets veranderd — de enige variabele is hoeveel context het nu tegelijk moet verwerken.

Het gaat geleidelijk, waardoor je het van binnenuit moeilijk merkt. Er is geen foutmelding en geen drempel; elke beurt is maar iets slechter dan de vorige. Tegen de tijd dat de fouten duidelijk zijn, zit je al een poos in de domme zone.

Je herstelt door context te verwijderen, niet door meer toe te voegen. De genegeerde instructie opnieuw plakken voegt nog een concurrent toe aan hetzelfde volle venster en helpt maar kort. Wat wel werkt: wissen en alleen laden wat de taak nodig heeft, of compacten, of een handoff doen naar een verse sessie. Zie afnemende instructievolging als een signaal over de lengte van de context, niet over het model.

Gebruik:

"Het zit diep in de domme zone — het verzint generieke types die niet in het typebestand staan."

"Aandachtsdegradatie. De typedefinities staan nog in de context, maar het signaal erover is bedolven onder alles wat we sindsdien hebben toegevoegd. Wissen en opnieuw laden."

Vroeg in een sessie zit de agent in een "smart zone" — scherp, gefocust, met een goed geheugen. Naarmate de sessie groeit, glijdt die naar een "domme zone": slordiger, vergeetachtiger, meer fouten en meer getrouwheids-hallucinaties. Hetzelfde model, dezelfde agentomgeving — alleen meer context. Het voelbare effect van aandachtsdegradatie. Bij frontiermodellen begint de domme zone vaak rond 125K–150K tokens, al is dat omstreden. Wis of compact wanneer de sessie uitdijt; probeer er niet doorheen te duwen.

De achteruitgang verloopt geleidelijk en is daardoor makkelijk te missen. Er verschijnt geen foutmelding en geen zichtbare grens; de agent presteert eerst iets slechter en daarna merkbaar slechter. Veelvoorkomende signalen: een instructie van twintig beurten geleden vergeten, een al gecorrigeerde fout herhalen, of met overtuiging iets beweren wat de context tegenspreekt. Omdat de achteruitgang geleidelijk gaat, is de gebruikelijke reactie doorzetten en opnieuw uitleggen — daarmee voeg je meer context toe en maak je het probleem erger.

De zones volgen niet de limiet van het contextvenster. Een sessie kan diep in de domme zone zitten terwijl het grootste deel van het venster nog vrij is: de limiet is het punt waarop de agentomgeving niet verder wil, maar de kwaliteit daalt al veel eerder. Plan rond de smart zone, niet rond het venster — het praktische budget voor een taak bestaat uit de tokens waarmee de agent goed werkt, niet uit alles wat die technisch kan vasthouden.

De smart zone is een budget, en niet-gerelateerd werk verbruikt het. Elke taak in een sessie gebruikt tokens; een tweede taak in dezelfde sessie begint dus dichter bij de domme zone. Eén taak per sessie geeft elke taak het scherpste deel van de sessie. Is één taak groter dan één smart zone, splits die dan op: doe een handoff of compact op een logisch punt en laat een verse sessie het volgende deel uitvoeren.

Gebruik:

"De eerste drie onderdelen gingen perfect; het vierde heeft die totaal verpest."

"Je bent uit de smart zone — hetzelfde model, maar nu diep in de domme zone. Compact en laad het plan opnieuw; het volgende onderdeel gaat dan goed."

De huidige sessie beëindigen en een nieuwe starten. Het volgende bericht begint met een lege sessie en een leeg contextvenster. Meestal doet de gebruiker dit.

Wissen is de oplossing voor vervuilde context. Een sessie stapelt alles op: mislukte pogingen, verkeerde afslagen, verouderde toolresultaten, verlaten plannen. Het model leest dit alles bij elke beurt opnieuw, en slechte geschiedenis werkt door in nieuw werk. Diep in een lange sessie wordt de agent vager en minder gehoorzaam — duidelijke instructies worden genegeerd, de kwaliteit daalt, en aansporen om beter te werken helpt niet, omdat de ruis nog steeds in de context staat. Wissen verwijdert de ruis.

Wissen verwijdert het gesprek niet. De meeste agentomgevingen bewaren sessiegeschiedenis op je computer, dus het transcript is nog steeds te lezen of te hervatten. Wat verdwijnt, is de werkstatus van de agent: het model is stateless, dus de nieuwe sessie weet niets van wat de vorige wist. Bevat de sessie beslissingen of voortgang die de volgende nodig heeft, laat de agent dan eerst een handoff-artifact schrijven en begin de nieuwe sessie met een verwijzing ernaartoe.

Vergelijk compaction, dat de sessie samenvat in de nieuwe context in plaats van leeg te beginnen. Wissen is het bottere gereedschap: niets wordt meegenomen, ook de rommel niet.

Gebruik:

"Hij blijft hangen in een lus rond de mislukte test."

"Wis de sessie gewoon — begin opnieuw met het plandocument en het testbestand. Het heeft geen zin de bestaande context te bevechten."

Agent-context van de ene sessie naar de andere overbrengen. Het overdrachtsmiddel verschilt — een geschreven handoff-artifact, een samenvatting in het geheugen (compaction) en andere opties. Anders dan wissen, waarbij niets wordt overgedragen. Redenen lopen uiteen: rollen wisselen (planner → uitvoerder), een AFK-run starten, werk verdelen over parallelle sessies of ruimte vrijmaken in het contextvenster.

De ontvangende sessie begint zonder context — het model is stateless en niets uit de oude sessie is zichtbaar voor de nieuwe. Alles wat de volgende sessie nodig heeft, moet expliciet worden meegenomen; de rest is verdwenen. "Geen terugweg" is de beperking die bepaalt hoe je overdraagt: de nieuwe sessie kan de oude niet vragen wat die bedoelde, dus het overgedragen materiaal moet op zichzelf begrijpelijk zijn.

Een slechte handoff blijkt uit het opnieuw voeren van oude discussies: de nieuwe sessie heropent beslissingen die de vorige al had genomen, omdat de overdracht wel noteerde wat was besloten, maar niet waarom. Beoordeel een handoff op wat een sessie zonder context ermee kan doen.

Gebruik:

"De planningssessie wordt zwaar — moet ik gewoon doorgaan?"

"Doe een handoff. Schrijf de beslissingen in een document, wis de sessie en begin de implementatie in een verse sessie die dat document leest."

Een bron in haar oorspronkelijke vorm — de code, het transcript van het gesprek, het ruwe log, het daadwerkelijke API-antwoord. Geen verslag van het ding, maar het ding zelf. Tegenhanger van secondary source.

Wil je weten wat je codebase doet, dan is de code de primary source. De documentatie, het architectuurdiagram en de README beschrijven die slechts — accuraat toen ze werden geschreven, en sindsdien volgens hun eigen tijdlijn bijgewerkt. Als een agent met overtuiging iets onjuists over je project beweert, vraag dan uit welke bron die werkte: een agent die een document las, erft de veroudering ervan; een agent die de code las, leest de actuele waarheid.

De kosten maken dat primary sources niet standaard worden gebruikt. Een bron in het context window laden is duur — het hele bestand, het hele transcript, elk token dat als input wordt gerekend en om het aandachtsbudget concurreert. Wat je ervoor terugkrijgt is volledigheid: niets is vooraf gefilterd door andermans oordeel over wat belangrijk was. Een samenvatting van vorige maand kan het detail missen dat vandaag belangrijk blijkt; de primary source bevat het nog steeds.

Pak de primary source erbij wanneer precisie telt — de exacte signature, de werkelijke fout, de regel die de fout veroorzaakt. Veel van context beheren komt neer op beslissen wanneer de primary source de kosten waard is en wanneer een secondary source volstaat.

Gebruik:

"De agent zegt dat de retry-logica exponentieel wacht, maar ik zie dat die het endpoint blijft bestoken."

"Dat heeft die uit het ontwerpdocument. Wijs de agent op de daadwerkelijke retry-module — werk vanuit de primary source wanneer het gedrag ertoe doet."

Een verslag van een primary source, één stap ervan verwijderd — documentatie die code beschrijft, een samenvatting van een transcript, een rapport over zoekresultaten. Goedkoper in het contextvenster te laden dan de bron zelf, maar per definitie verlieslatend: de schrijver bepaalde wat belangrijk was, en wat die wegliet blijft onzichtbaar voor iemand met alleen de samenvatting.

Veel context beheren draait om secondary sources maken. Compaction vat de sessie-geschiedenis samen als beginpunt voor de volgende sessie. Een subagent gebruikt zijn eigen context voor een rumoerige zoekactie en levert een kort verslag terug. Een handoff artifact vat de beslissingen van een sessie samen in een document voor de volgende sessie. Geheugensystemen destilleren wat een sessie heeft geleerd tot notities. Elk maakt dezelfde ruil: getrouwheid voor ruimte.

Secondary sources falen op twee manieren. Ze verliezen informatie — de compaction-samenvatting die de schemabeslissing wegliet, het verslag dat het randgeval niet noemde. En ze verouderen — de primary source verandert maar het verslag niet, waardoor documentatie de architectuur van vorig kwartaal beschrijft met het vertrouwen van dit kwartaal. Als een agent handelt op basis van een secondary source die op een van die manieren tekortschiet, werkt die vol vertrouwen met verkeerde informatie; de oplossing is de agent terug te sturen naar de primary source.

Geen van beide tekortkomingen maakt secondary sources verkeerd. Het contextvenster is eindig en primary sources zijn duur; zonder samenvattingen, verslagen en overdrachtsdocumenten past er niets groots in. De vaardigheid is weten welke details het verlies kunnen overleven — en de primary source controleren wanneer dat niet zo is. Een goede secondary source bevat een contextverwijzing terug naar het origineel — de samenvatting die het transcript noemt waaruit ze komt, het document dat het beschreven bestand noemt — zodat de lezer die kan volgen wanneer het verslag niet volstaat, in plaats van met het verlies te moeten werken.

Gebruik:

"In het overdrachtsdocument staat dat auth klaar is, maar de nieuwe sessie vindt steeds kapotte tokenvernieuwing."

"Het document is een secondary source — de vorige sessie schreef op wat die dacht, niet wat waar is. Laat de nieuwe sessie de auth-tests uitvoeren en vertrouw op de primary source."

Een document dat dient als overdrachtsmiddel voor een handoff — het wordt door de ene session naar de environment geschreven, zodat een andere session het kan lezen. Specs, tickets en plandocumenten zijn allemaal handoff-artifacts.

Waarom je er een schrijft: het model is stateless, dus na het clearing blijft niets uit een session bewaard. Beslissingen, beperkingen, half afgemaakte plannen — alles verdwijnt met de context waarin het stond. De environment blijft bestaan. Door de belangrijke status in een bestand te schrijven, verplaats je die naar een plek waar de volgende session haar kan teruglezen.

Het artifact is een secondary source — een verslag van het werk van de session, niet het werk zelf. Daardoor is het klein genoeg om een nieuwe session bij te praten, maar kan het die ook misleiden: het legt vast wat de schrijvende session dacht, en wat ze wegliet of verkeerd had, blijft onzichtbaar voor de lezer. Als een bewering ertoe doet, moet de volgende session die controleren aan de hand van de primary source — de code, de tests — in plaats van haar zomaar over te nemen.

Een goed artifact is geschreven voor een session die met nul context begint. Gebruik concrete bestandspaden in plaats van “het bestand dat we bespraken”. Leg vast wat is besloten en waarom, zodat de volgende session de discussie niet opnieuw hoeft te voeren. Beschrijf wat klaar is en wat nog moet gebeuren. Het helpt de schrijvende session te vertellen waar het artifact voor bedoeld is: “schrijf een overdrachtsdocument voor een nieuwe session die niets van dit werk weet”.

Het andere overdrachtsmiddel is compaction, dat informatie in het geheugen samenvat. Het artifact heeft twee voordelen: het staat op schijf, waar je het kunt lezen en corrigeren voordat iemand erop vertrouwt, en je kunt het hergebruiken — dezelfde spec kan vijf parallelle sessions bijpraten.

Gebruik:

“Hoe verdeel ik dit tussen de plannende agent en degene die het uitvoert?”

“Laat de planner een handoff-artifact schrijven — bestandspaden, beslissingen, beperkingen. De session van de uitvoerder begint met een verwijzing naar het artifact en gebruikt dat als briefing.”

Een overdrachtsartefact dat werk over meerdere sessies beschrijft: wat er wordt gebouwd, niet hoe elke sessie haar deel doet. Verandert naarmate het werk vordert. Bestaat uit tickets.

De specificatie bestaat omdat sessies wegwerpbaar zijn en grote projecten niet. Alles wat meer dan één contextvenster aan inspanning vraagt heeft een thuis buiten de context nodig: ergens in de omgeving van de agent dat wissen overleeft, of dat nu een bestand in de repository is, een GitHub-issue of een issuetracker die de agent kan bereiken. De specificatie is dat thuis: het doel, de beperkingen, de tot nu toe genomen beslissingen en de ticketlijst met statussen. Elke nieuwe sessie kan haar lezen en weten waar het werk staat zonder de opgestapelde ruis van de vorige sessie over te nemen.

Specificaties bestaan in herkenbare stijlen, meestal ontleend aan hoe teams zaken al vastleggen. Een product requirements document (PRD) legt meer nadruk op het wat en waarom voor gebruikers: functies, gedrag en acceptatiecriteria. Een ontwerpdocument of RFC is technischer: de gekozen aanpak, verworpen alternatieven en afwegingen. Aan de kleine kant doet een eenvoudige `plan.md` met een checklist van tickets hetzelfde voor een functie over meerdere sessies. De stijl is minder belangrijk dan de rol: voor de agent zijn ze allemaal hetzelfde: de blijvende intentieverklaring die hij aan het begin van elke sessie leest.

Gebruik:

”Moet dit allemaal één sessie zijn?”

”Nee, leg het vast als specificatie: splits het op in tickets en voer elk ticket uit in een eigen sessie. Als je alles in één context probeert te doen, bereik je de domme zone voordat je halverwege bent.”

Een overdrachtsartefact dat één sessie werk afbakent. Staat op zichzelf of hangt als onderliggend onderdeel aan een specificatie. Tickets kunnen andere tickets op hetzelfde niveau blokkeren of erdoor geblokkeerd worden. De werkvolgorde volgt daardoor uit hun afhankelijkheidsgraaf in plaats van uit een lineair plan.

De bepalende beperking is de omvang: één sessie. Een ticket moet afgerond kunnen worden voordat de sessie uit de slimme zone drijft, en die beperking is toetsbaar. Als sessies voor jouw tickets geregeld verslechteren voordat het werk af is, zijn de tickets te groot; splits ze. Als elke sessie het grootste deel van haar context aan voorbereiding besteedt om daarna vijf minuten te werken, zijn ze te klein; voeg ze samen.

Een goed ticket is geschreven voor een lezer zonder verdere context. Het doel, de acceptatiecriteria en contextverwijzingen naar de relevante bestanden en beslissingen: genoeg om de sessie te laten beginnen zonder opnieuw af te leiden wat de vorige wist.

De afhankelijkheidsgraaf maakt ook parallel werk mogelijk. Onafhankelijke tickets, de bladeren van de graaf, kunnen elk tegelijk in een eigen sessie draaien. Dat is een effectieve manier om meerdere agents tegelijk te laten werken. In een softwarefabriek is een ticket dat als gereed wordt gemarkeerd zelf de trigger die de sessie start.

Gebruik:

”Waar begin ik bij de migratiespecificatie?”

”Bekijk de ticketgraaf: de schemawijziging blokkeert het aanvullen van gegevens, en dat blokkeert de API-omschakeling. Kies een blad en voer daar een sessie op uit.”

Een overdracht in het geheugen: de geschiedenis van de vorige sessie wordt samengevat en de samenvatting vormt het begin van een nieuwe sessie. Bewust met informatieverlies: het transcript is een primaire bron, de samenvatting een secundaire bron. Details worden ingeruild voor ruimte. Handmatig gestart door de gebruiker of automatisch via autocompact.

Het mechanisme: het contextvenster is eindig en een lange sessie vult het. Elk toolresultaat, elk gelezen bestand en elke verkeerde afslag blijft in de geschiedenis. Wordt die zwaar, dan vraagt de agentomgeving het model de sessie samen te vatten, gooit de oorspronkelijke geschiedenis weg en begint een nieuwe sessie met de samenvatting. Wat de samenvatting niet heeft gehaald, is uit de context verdwenen. Sommige agentomgevingen verzachten dat door het oude transcript op schijf te bewaren en een contextverwijzing ernaar in de samenvatting achter te laten. De secundaire bron verwijst terug naar haar primaire bron, zodat een verloren detail kan worden teruggehaald door het origineel opnieuw te lezen.

De samenvatting wordt door het model geschreven en is dus met een prompt te sturen. ”Behoud de schemabeslissingen” maakt het gegenereerde artefact gerichter. Ook de timing telt: compacteer op een fasegrens, nadat het plan vaststaat, niet midden in een taak.

Vergelijk dit met wissen, dat alles laat vallen en zonder voorkennis begint: compacteren probeert het essentiële mee te nemen; wissen gokt erop dat het al ergens beter is vastgelegd.

Gebruik:

”De context wordt zwaar en ik moet de tests nog draaien.”

”Compacteer voordat je begint: zet wat moet overleven in de samenvattingsprompt zodat de nieuwe sessie de schemabeslissingen behoudt en het verkennende werk laat vallen.”

Compaction die automatisch wordt gestart door de agentomgeving wanneer het contextvenster bijna vol is.

De agentomgeving houdt in de gaten hoe vol het contextvenster is. Zodra een drempel wordt overschreden — vaak rond 80% — pauzeert die, vraagt het model de sessie tot dan toe samen te vatten en start een verse sessie met die samenvatting. Het werk gaat verder alsof er niets is gebeurd.

Toch is er wel iets gebeurd. Compaction verliest informatie, en autocompact doet dat op een moment dat je niet hebt gekozen. Je voert handmatige compaction uit op een overgang tussen fasen, wanneer je het model kunt vertellen wat het moet bewaren. Autocompact gebeurt halverwege een taak zodra de drempel wordt bereikt — mogelijk midden in een refactor, waarbij de samenvatting zelf beslist welke van jouw beslissingen het bewaren waard waren. Het klassieke symptoom: de agent werkt zelfverzekerd verder, maar is stilletjes een beperking vergeten die je een uur eerder hebt vastgesteld. Je merkt het pas wanneer het werk die tegenspreekt.

De verdediging is voorkomen dat dit gebeurt. Houd de contextindicator in de gaten en compact handmatig op een natuurlijk overgangsmoment, of schrijf beslissingen op schijf in een plandocument of handoff-artifact, waar geen samenvatting ze kan kwijtraken. De meeste agentomgevingen laten je ook de buffer aanpassen — de drempel eerder of later instellen, of autocompact helemaal uitschakelen — zodat je bepaalt hoeveel ruimte er overblijft voordat die ingrijpt.

Gebruik:

"Hij lijkt niet meer te weten wat we eerder over het schema besloten."

"Autocompact gebeurde tussen de beurten — de vroege beslissingen zijn samengevat en er is vast iets verloren gegaan. Laad het plandocument opnieuw, of compact de volgende keer handmatig zodat jij bepaalt wat behouden blijft."

Een systeem dat een agent over meerdere sessions heen stateful probeert te maken. Het bewaart tijdens een session informatie in de environment en laadt die aan het begin van toekomstige sessions terug in het context window, zodat de agent continuïteit behoudt nadat de gebruiker de session heeft gewist.

Een geheugensysteem heeft twee helften. Het schrijfpad: tijdens een session legt de agent vast wat die heeft geleerd — een genoemde voorkeur, een projectfeit — als bestanden in de environment. Het leespad: bij het begin van de session laadt de harness die bestanden, of een index ervan, terug in het context window. Veel harnesses leveren hun eigen geheugensysteem — Claude Codes `/memory` is er een — maar je kunt er ook zelf een bouwen: een map met notities plus een instructie in AGENTS.md om die te raadplegen.

Dezelfde afwegingen als bij alle inhoud die altijd wordt geladen, gelden hier. Herinneringen stapelen zich op, dus laden de meeste systemen een index van één regel en laten ze de inhoud achter context pointers staan in plaats van alles inline te zetten. Herinneringen zijn ook secondary sources, dus ze verouderen: een feit dat in maart is vastgelegd, wordt in juni met hetzelfde vertrouwen geladen, nadat het project is veranderd. Een geheugensysteem moet worden opgeschoond, net als AGENTS.md.

Gebruik:

"Ik moet steeds opnieuw vertellen dat ik Postgres gebruik, geen MySQL."

"Sluit een geheugensysteem aan — laat het op de eerste turn wat het leert naar het filesystem schrijven en laad dat bij het begin van een session opnieuw. Het model zelf is stateless; de geheugenlaag bootst continuïteit na."

Een bestand in de environment dat de harness bij het begin van een session in het context window laadt: de vaste projectbriefing voor de agent. Een conventie die bij meerdere harnesses werkt; sommige hebben ook een eigen variant (Claude Codes is CLAUDE.md).

Omdat het automatisch wordt geladen, voorkomt het herhaling tussen sessions. Het model is stateless: een correctie uit de ene session is in de volgende verdwenen. Je vertelt elke nieuwe session dan opnieuw dat het project pnpm gebruikt, dat tests een bepaalde flag nodig hebben, of dat een map gegenereerd is en ongemoeid moet blijven. Als je de agent twee keer op hetzelfde hebt gecorrigeerd, kan die correctie een regel voor AGENTS.md worden.

Geschikte inhoud is alles wat de agent niet uit de code kan afleiden: build- en testcommando's, niet voor de hand liggende conventies, harde beperkingen ("bewerk de gegenereerde client nooit"). Kort en declaratief: het is een briefing, geen documentatie.

De keerzijde is dat alles erin altijd wordt geladen. Instructies stapelen zich op, meestal irrelevant voor een bepaalde taak. Een lange AGENTS.md kost tokens en verzwakt zichzelf: hoe meer instructies in de context staan, hoe minder betrouwbaar het model elke afzonderlijke instructie volgt.

Vermijd: AGENTS.md gebruiken voor inhoud die progressief beschikbaar moet worden gemaakt: alles erin kost tokens bij elke turn, in elke session, ook als die het niet nodig heeft. Een stijlgids kan achter een skill of context pointer staan; bewaar AGENTS.md voor regels die overal gelden.

Gebruik:

"Waarom begint elke session met 4k tokens die al verbruikt zijn?"

"Kijk in AGENTS.md: iemand heeft de hele stijlgids ingeplakt in plaats van die achter een skill te zetten."

Alleen de context laden die een agent nu nodig heeft, met contextverwijzingen naar de rest. De term komt uit UI-ontwerp, waar die betekent dat gebruikers alleen de bedieningselementen zien die voor hun huidige taak relevant zijn en de rest achter een klik verborgen blijft.

De techniek bestaat omdat context twee keer geld kost. Elke token die vooraf wordt geladen, wordt bij elke beurt als inputtokens in rekening gebracht, en elke token gebruikt aandachtsbudget, of de agent die nu nodig heeft of niet. Een AGENTS.md vol met de volledige stijlgids, het deployrunbook en databaseconventies maakt de agent slechter in alle drie: relevante instructies voor de taak worden verdund door instructies die er niet toe doen. Dat merk je aan een agent die regels negeert waarvan je weet dat ze in de context staan: ze zijn er wel, maar bedolven.

Progressive disclosure draait dit om. Houd de altijd geladen laag klein — één zin per onderwerp en een verwijzing naar de plek waar de details staan. De agent leest de stijlgids bij het schrijven van een component, het deployrunbook tijdens een deployment en geen van beide bij het oplossen van een test. Skills zijn het patroon dat in de agentomgeving is ingebouwd: een korte beschrijving die elke sessie wordt geladen, en de volledige instructies alleen wanneer ze worden geactiveerd.

Gebruik:

"Moet ik de hele stijlgids in AGENTS.md zetten?"

"Nee — progressive disclosure. Verwijs naar de stijlgids als skill die de agent laadt wanneer die echt een component moet schrijven. AGENTS.md kost elke beurt tokens."

Een vermelding in het ene document die naar een ander verwijst, zodat de agent dat alleen in het context window kan laden wanneer de taak erom vraagt. Hieruit bestaat progressive disclosure.

Een pointer gebruiken in plaats van inhoud in te voegen, bespaart kosten. Een pointer is één regel in het context window. Het document erachter kan duizenden tokens bevatten, maar die kosten niets totdat de agent de pointer volgt. Zet je een runbook van 2.000 tokens in AGENTS.md, dan betaalt elke session ervoor. Vervang het door "deployproces: zie `internal/deploy.md`" en alleen sessions die deployen laden dat bestand. De agent volgt de pointer met een tool call wanneer de taak ermee overeenkomt.

Een pointer heeft twee dingen nodig: een stabiel pad en genoeg beschrijving zodat de agent weet wanneer volgen de moeite waard is. Een kaal pad geeft geen reden om het te volgen; "zie `internal/deploy.md`" zonder aanwijzing over de inhoud wordt overgeslagen door een session die het nodig had. Schrijf de regel in de bewoordingen van taken: "release, deploy of rollback — lees eerst `internal/deploy.md`".

Pointers vind je overal: regels in AGENTS.md, beschrijvingen van skills (de harness laadt de beschrijving; de skilltekst blijft erachter), bestandsnamen in een mapoverzicht, links tussen documenten.

Een pointer kan ook een secondary source terugkoppelen aan de primary source waaruit die is afgeleid — bijvoorbeeld een compaction-samenvatting met de oorspronkelijke transcriptie, of een document dat het beschreven bronbestand noemt. Daardoor is informatieverlies herstelbaar: als de samenvatting onvoldoende blijkt, volgt de agent de pointer en leest het origineel, in plaats van alleen te werken met wat de samenvatting behield.

Vermijd: "referentie" — te droog; het maakt niet duidelijk dat volgen meer context ophaalt. "Portaal" — te bloemrijk.

Gebruik:

"AGENTS.md wordt enorm."

"Het meeste moet uit context pointers bestaan, niet uit inhoud. Houd regels die altijd gelden inline; maak van het deployrunbook en de stijlgids skills en laat een context pointer achter."

Een aan te leren vaardigheid, gebundeld als eenheid — instructies en hulpmiddelen om één taak goed uit te voeren. Ze blijven in de environment totdat een context pointer ze voor de betreffende taak in het context window laadt. De eenheid van progressive disclosure in een harness.

Skills zijn een open standaard, gedefinieerd op agentskills.io — oorspronkelijk ontwikkeld door Anthropic en sindsdien overgenomen door de meeste grote harnesses, zodat een eenmaal geschreven skill overal werkt. Het formaat is een map met:

• Een `SKILL.md`-bestand — metadata (minimaal een naam en beschrijving) plus de instructies zelf
• Optioneel scripts die de agent kan uitvoeren
• Optionele sjablonen en referentiematerialen waarnaar de instructies verwijzen

Standaard staan alleen de naam en beschrijving in context. Wanneer de taak van de agent overeenkomt, laadt die de rest. Tot dat moment neemt de skill vrijwel geen ruimte in — één of twee zinnen aan tokens, hoe lang de volledige instructies ook zijn.

Hierdoor verschillen skills van AGENTS.md, dat bij elke session wordt geladen, ongeacht de taak. Een skill wordt gelezen wanneer een bepaald soort werk aan de orde is — releasen, een nieuwe service opzetten, een migratie schrijven — en wordt de rest van de tijd genegeerd.

Vermijd: "tool" — een tool is iets wat de agent aanroept; een skill bevat instructies die de agent leest.

Gebruik:

"Waar moet ik het deployrunbook neerzetten?"

"Als skill — de agent laadt die alleen wanneer de taak over deploys gaat. In AGENTS.md zou die bij elke turn tokens kosten, terwijl we die maar wekelijks gebruiken."

Een agent die door een andere agent via een tool call wordt gestart. Draait in een eigen sessie met een eigen contextvenster en stuurt één toolresultaat terug. Anders dan bij een handoff verwacht de ouderagent specifiek een antwoord; een handoff heeft geen terugweg. Kan geen verdere subagents starten — de boom is één niveau diep. Subagents dienen om context te isoleren, niet om hiërarchieën op te bouwen.

Het doel is om luidruchtig werk buiten de context van de ouderagent te houden. Een brede zoekactie of een lange tocht door bestanden levert pagina's toolresultaten op, waarvan de meeste alleen nodig zijn om het antwoord te vinden. Voer je dit binnen de ouderagent uit, dan blijft alles de rest van de sessie in diens context staan. Voer je het uit in een subagent, dan vult het lawaai een wegwerpvenster; alleen het eindrapport komt in de context van de ouderagent terecht. Dat rapport is een secondary source: de ouderagent krijgt het verslag van de subagent, niet de ruwe resultaten, dus wat het rapport weglaat blijft voor de ouder onzichtbaar.

Subagents kunnen ook gelijktijdig werken — een ouderagent kan meerdere agents tegelijk op onafhankelijke onderdelen inzetten.

Gebruik:

"De grep-resultaten nemen mijn hele context in beslag."

"Laat een subagent zoeken — die gebruikt zijn eigen contextvenster voor het lawaai en rapporteert de twee bestandspaden die je echt nodig hebt."

Een werkpatroon waarbij een of meer mensen tijdens een sessie met de agent samenwerken — ze reviewen, sturen bij of werken in realtime samen. De mens is aanwezig en betrokken, en keurt niet alleen afzonderlijke acties goed of af.

Het contrast is werk AFK, waarbij de agent zonder toezicht draait en jij het resultaat achteraf beoordeelt. Human-in-the-loop betekent problemen opsporen terwijl ze nog goedkoop te verhelpen zijn: je ziet dat de agent het verkeerde bestand kiest, de eis verkeerd leest of een doodlopende weg inslaat, en stuurt die met één zin bij — in plaats van twintig minuten overtuigend werk te ontdekken dat op die fout is gebouwd. Agents merken niet betrouwbaar zelf wanneer ze van het spoor raken; alleen laten ze eerder doorgaan dan stoppen en vragen.

Welk patroon past, hangt af van het werk. Goed gespecificeerde taken met weinig risico en een makkelijk te controleren resultaat lenen zich voor AFK. Taken die dubbelzinnig of onomkeerbaar zijn, of waarvan het eindresultaat lastig te reviewen is — een schemamigratie, een ingewikkelde ontwerpkeuze, alles wat productie raakt — vragen om betrokken blijven. De afweging komt neer op: hoe duur is een verkeerde afslag, en hoe laat zou je die ontdekken?

Sommig werk is vanzelf human-in-the-loop, omdat jouw reacties de invoer zijn. Grilling werkt alleen als je aanwezig bent om vragen te beantwoorden; prototyping alleen als je er bent om op het artefact te reageren.

Betrokken blijven kost je aandacht, en die is schaars. Beter worden in het werken met agents betekent deels meer werk veilig buiten de lus brengen — met plannen, automated checks en human review aan het einde in plaats van voortdurend toezicht. Een software factory gaat verder door sessies op triggers te starten, zodat zelfs het werk op gang brengen jou niet nodig heeft.

Gebruik:

"Dit vannacht AFK laten draaien?"

"Nee, het is een schemamigratie — houd het human-in-the-loop. Ik wil elke stap zien en bijsturen als die de verkeerde kolom kiest om uit terug te vullen."

Away from keyboard. Een werkpatroon waarbij de gebruiker een sessie start en de agent zonder toezicht laat draaien. De productiviteitsvermenigvuldiger van AI-programmeren: veel AFK-sessies kunnen parallel lopen terwijl jij slaapt, eet of iets anders doet. Meestal zijn een ruime permission mode en sandboxing nodig om dit veilig te doen.

Wanneer je er niet bent, gaat de agent anders om met onduidelijkheid. Terwijl je meekijkt, komt een dubbelzinnige keuze als vraag naar voren en beantwoord je die. Zodra je bent weggelopen, kiest de agent een standaardoptie en gaat verder; alle latere beslissingen bouwen op die gok voort. De typische misser is terugkomen na uren afgerond, overtuigend werk dat rust op een verkeerde keuze uit de eerste tien minuten. Het werk is niet slordig — het hangt logisch samen, maar rond het verkeerde uitgangspunt.

Omdat je tijdens de run geen input kunt geven, geef je die ervoor en erna. Ervoor: los de onduidelijkheid vooraf op — met een grilling-sessie of een geschreven spec — zodat de agent minder gaten alleen hoeft te vullen. Tijdens de run: automated checks en automated review vervangen de aandacht die je niet geeft en vangen snel op wat mechanisch te controleren is. Erna: de run eindigt in iets dat je kunt reviewen — een PR, geen wijzigingen die al zijn gemerged. AFK verwijdert human review niet; alle review wordt uitgesteld tot het einde. Daarom moet het resultaat de review waard zijn. Ook daarom is AX het belangrijkst bij AFK-runs: zonder meekijker is de omgeving de enige ondersteuning voor de agent.

Vermijd: "achtergrondagent" — dat benadrukt de machine ("draait op de achtergrond") in plaats van het menselijke patroon ("de gebruiker is weggegaan"). AFK benoemt het relevante feit: de gebruiker kijkt niet mee.

Gebruik:

"Ik laat dit AFK draaien — drie agents in een sandbox doen de refactor; morgenochtend review ik de PR's."

"Bypass permissions?"

"Ja, alleen-lezen-filesystem, geen netwerk."

Een deterministische controle die in de environment draait — tests, typechecks, linters, builds, pre-commit-hooks. Geslaagd of mislukt, zonder oordeel. Het signaal waarmee een agent zichzelf kan corrigeren zonder iemand anders erbij te betrekken. Een flaky test is een kapotte check, geen afwezige check; geautomatiseerde checks zijn van nature deterministisch.

Zelfcorrectie werkt als een lus. De agent brengt een wijziging aan, voert de check uit als tool call, en de foutuitvoer komt in het context window terecht — een typefout met bestand en regelnummer, een mislukte bewering met de verwachte en werkelijke waarde. Dat is genoeg voor de agent om het probleem op te lossen en de check opnieuw uit te voeren, steeds weer tot die slaagt, zonder mens in de lus. Determinisme maakt de lus betrouwbaar: dezelfde code levert altijd hetzelfde oordeel op, dus een geslaagde check betekent iets. Een flaky check verstoort dit — de agent “herstelt” code die al goed was, of probeert net zo lang opnieuw tot een echte fout verdwijnt.

Daarom zijn goede checks een groot deel van de AX van een codebase. Een agent in een repo met strikte types, een snelle testsuite en een linter vindt de meeste eigen fouten voordat jij ze ziet; een agent in een repo zonder dat alles levert af wat hij produceert. Het verschil telt het meest bij AFK-runs, waar checks de enige verificatie tijdens de run zijn. Maar een check vangt alleen wat hij controleert — groene checks betekenen dat de beweerde eigenschappen kloppen, niet dat de code goed is. De hiaten waarvoor oordeel nodig is, zijn waar automated review en human review voor dienen.

Vermijd: “feedback loop” / “backpressure” — beide gooien checks en review op één hoop. Vermijd: “test” — tests zijn geautomatiseerde checks, maar niet alle geautomatiseerde checks zijn tests.

Gebruik:

“De agent levert steeds kapotte code af in de AFK-runs.”

“Welke automated checks zijn gekoppeld aan de sandbox?”

“Alleen de unittests.”

“Voeg typecheck en lint toe — daaruit kan de agent zichzelf corrigeren voordat de PR ooit wordt gemerged.”

Een agent die het werk van een andere agent reviewt, vaak met een ander model of een andere system prompt. Niet-deterministisch: de reviewer vormt een oordeel. Kan overal draaien — vóór het mergen van een PR, achteraf op commitgeschiedenis, of midden in een sessie als subagent. Een LLM-as-judge in CI is automated review, geen automated check; de categorie wordt bepaald door wat de bewering doet, niet door waar die draait.

De scheiding van de agent die het werk uitvoert, maakt dit effectief. De agent vragen het eigen werk te reviewen levert weinig op: de sessie die de bug veroorzaakte bevat ook de redenering die ertoe leidde, en de agent leest de eigen conclusies terug als bevestiging. Een reviewer met een vers contextvenster heeft die gehechtheid niet: die ziet de diff als een buitenstaander, en dat is nodig voor review. Een ander model of een reviewgerichte system prompt maakt dit effect sterker — andere blinde vlekken en een prompt die is gericht op wat jij belangrijk vindt (beveiliging, API-contracten, prestaties) in plaats van een vaag "zoek problemen".

Dit past tussen de andere reviewlagen. Automated checks zijn deterministisch en vangen op wat mechanisch kan worden getoetst; human review is duur en schaalt het slechtst. Automated review zit ertussenin: die vangt problemen waarvoor oordeel nodig is — een misleidende functienaam, een gemist randgeval — tegen machinekosten. Omdat de uitkomst niet deterministisch is, kan de reviewer dingen missen en onterechte problemen melden. Gebruik het als filter dat de ondergrens verhoogt voordat een mens kijkt, niet als poort die een mens vervangt.

Vermijd: "AI review" / "agent review" — te vaag om deze reviewer te onderscheiden van de agent die het werk uitvoert.

Gebruik:

"We krijgen te veel slechte PR's uit de AFK-runs."

"Voeg vóór het mergen een stap voor automated review toe — ander model, aparte system prompt, gericht op beveiliging en contractwijzigingen."

De gebruiker leest de code die de agent heeft gemaakt en vormt daar een oordeel over. De diff of gewijzigde bestanden lezen telt; de beschrijving van wat de agent deed lezen niet — een vertelling is niet het artefact. Die beschrijving is een secondary source, geschreven door de partij die wordt beoordeeld; de diff is de primary source, en review betekent die lezen.

Agents vergroten de hoeveelheid geproduceerde code, waardoor review het knelpunt wordt. Een bruikbare aanpak is verschillende reviewstrategieën in lagen toepassen. Automated checks vangen mechanische fouten, automated review vangt fouten die je kunt beschrijven, en menselijke review blijft over voor wat alleen jij kunt beoordelen — of dit de juiste wijziging is, of de aanpak bij de codebase past, of dit überhaupt moet bestaan.

Review is ook eerder goedkoper. Een plan lezen voordat het werk begint of halverwege een kleine diff bekijken kost minuten; een afgeronde branch uitpluizen na een AFK-run duurt langer. Waar je het reviewmoment plaatst, is een human-in-the-loop-beslissing, geen bijzaak.

Vermijd: alleen "code review" zeggen — dat is dubbelzinnig tussen menselijke en automatische review.

Gebruik:

"Ik heb de AFK-uitvoer door een mens laten reviewen."

"Heb je de diff gelezen of alleen de samenvatting?"

"De diff. In de samenvatting stond dat dode code was verwijderd — de functie bleek vanuit een gegenereerd bestand te worden aangeroepen."

Een werkpatroon waarbij de gebruiker de code van de agent accepteert zonder human review. De diff blijft ondoorzichtig — het gaat erom of het programma zich goed gedraagt, niet wat erin staat. Automated review en automated checks kunnen nog steeds draaien; vibe coding zegt niets over de aanwezigheid van die twee.

De term komt van Andrej Karpathy, die hem begin 2025 bedacht: je "geeft je volledig over aan de vibes" en "vergeet dat de code zelfs bestaat" — beschrijf wat je wilt, accepteer wat terugkomt en beoordeel het door het uit te voeren.

Vibe coding ruilt inspectie in voor snelheid. Diffs lezen is meestal de langzaamste stap in werk met agents, dus die stap schrappen neemt het grootste knelpunt weg. Voor code waarvan fouten goedkoop zijn — prototypes, eenmalige scripts, interne tools — is dat een redelijke ruil. Het risico groeit mee met de levensduur en het belang van de code.

De kosten komen later. Vibe-gecodeerde wijzigingen stapelen zich op in een codebase die niemand heeft gelezen, en alleen gedrag is gecontroleerd. Alles wat gedrag niet zichtbaar maakt — een geheim in logs, een gemist randgeval of stilzwijgend verkeerde gegevensverwerking — komt dus ongemerkt mee. De eerste keer dat iemand het systeem debugt, is de eerste keer dat iemand de code leest. Zonder menselijke review is alle overgebleven geautomatiseerde verificatie — tests, types, automated review — de enige poort waar de code doorheen gaat. Dezelfde houding toegepast op een hele codebase of een deel ervan, waarvan de wijzigingen uit een software factory komen, heet een dark factory.

Vermijd: "vibe coding" als synoniem voor "AI-code van lage kwaliteit" — de term benoemt de reviewhouding, niet de code die eruit komt.

Gebruik:

"Heb je gelezen wat die aan de auth flow heeft veranderd?"

"Ik heb op vibes gecodeerd — de login werkt nog, dat is alles wat ik heb gecontroleerd."

"Lees de diff voordat je pusht; op vibes coderen rond auth is hoe geheimen in logs belanden."

Het gedeelde begrip van wat er wordt gebouwd, dat de gebruiker en de agent met elkaar delen maar dat losstaat van elk artefact. Dit is Brooks' term (The Design of Design): het gesprek, de handoff-artifacts en de code zijn allemaal artefacten die het ontwerpconcept proberen vast te leggen of te bereiken, maar geen ervan is het ontwerpconcept. De kwaliteit ervan blijkt uit de kwaliteit van het gesprek waarin het ontstond.

De term benoemt de oorzaak van een bekende frustratie: de agent schrijft precies wat je vroeg en het is toch verkeerd. Meestal had je zelf nog niet volledig uitgewerkt wat je wilde. Het ontwerpconcept was in je eigen hoofd nog niet af — je prompt legde vast wat je al had doordacht en zweeg over wat nog niet was uitgewerkt. De agent vulde die stiltes met eigen aannames, omdat er niets was om op af te stemmen. Er ging niets kapot. Er was geen gedeeld ontwerpconcept, omdat er nog geen volledig concept was om te delen.

Je merkt dat een ontwerpconcept gedeeld is, net als met een collega: de ander begint vragen die je nog niet hebt gesteld al te beantwoorden op de manier waarop jij dat zou doen. Tot dat moment is het werk een gesprek — grilling is de bewuste vorm daarvan — en een spec te vroeg schrijven legt de misafstemming alleen maar vast in een duurzamer artefact. Het ontwerpconcept verandert ook naarmate je leert; artefacten lopen achter, waardoor een spec die trouw was aan het begrip van vorige week de sessie van deze week toch kan misleiden.

Gebruik:

"Het schrijft precies wat ik vroeg en het is toch verkeerd."

"Jullie delen nog geen ontwerpconcept — de agent vult de gaten met aannames. Blijf praten tot annuleren, terugbetalingen en gedeeltelijke afhandeling voor jullie allebei hetzelfde betekenen; laat hem daarna pas een spec schrijven."

Een techniek om samen met een agent een design concept te ontwikkelen: de agent interviewt de gebruiker Socratisch en behandelt één beslissing tegelijk, waarbij die voor elke beslissing een aanbevolen antwoord voorstelt. Zo wordt de haast naar een afgerond plan afgeremd — er wordt geen handoff artifact geschreven voordat het concept stabiel is.

De techniek bestaat omdat agents stilzwijgend leemtes invullen. Vraag je een agent om op basis van een prompt van twee regels een spec te schrijven, dan stopt die niet bij beslissingen die je nog niet hebt genomen: die kiest standaardwaarden en schrijft ze op. Het resultaat lijkt compleet, en aannames zijn niet te onderscheiden van jouw keuzes. Je ontdekt ze daardoor laat: tijdens review, of wanneer de gebouwde feature een randgeval afhandelt op een manier waarvoor je nooit hebt gekozen. Grilling draait dat om — in plaats van te gissen moet de agent vragen stellen.

Het is een human-in-the-loop-techniek: jouw antwoorden vormen de invoer. Kan een vraag niet in gesprek worden beantwoord — omdat je het resultaat zou moeten zien — schakel dan over op prototyping.

Gebruik:

"Hij ging direct de spec schrijven en had de annuleringslogica verkeerd."

"Laat hem eerst doorvragen — laat hem je vragen over gedeeltelijke annuleringen, terugbetalingen en timing voordat hij iets in het document vastlegt. Dat los je goedkoper in een gesprek op dan in code."

De agent een snelle, ruwe versie van iets laten bouwen wanneer een gesprek te weinig detail biedt en je een echt artefact nodig hebt om samen te bespreken.

Grilling lost ontwerpbeslissingen in gesprek op. Een gesprek is goedkoop, maar biedt weinig detail: sommige vragen zijn niet in woorden te beantwoorden — hoe een interactie aanvoelt, of een API-vorm prettig werkt in echte aanroepende code, of een lay-out standhoudt bij echte datavolumes. Tijdens het interview komt de vraag waarop je eerlijke antwoord is: "Dat weet ik niet, ik moet het zien." Vanaf daar draait de discussie rondjes. Laat de agent in plaats daarvan het ding bouwen, bekijk het en hervat het gesprek met een antwoord.

Agents maken bouwen goedkoper, en daardoor is dit praktisch. Een ruwe versie die vroeger een dag kostte om te maken, staat er nu in minuten; het loont dus om dit geregeld te doen. Het is een human-in-the-loop-techniek: het prototype is er zodat jij erop kunt reageren.

Meestal bekijk je het niet maar één keer. Werk iteratief met het prototype — reageer, vraag om een wijziging, reageer opnieuw — zodat elke ronde een nieuwe beslissing toetst aan het echte artefact, met meer detail dan een gesprek kan bieden.

Een prototype hoeft niet volledig ruw te zijn. Je kunt de onderdelen die je beoordeelt op productiekwaliteit bouwen, zodat na de beslissing het component of de API waarop je reageerde naar de echte codebase kan worden overgezet. Daardoor is prototyping essentieel materiaal waarnaar de spec kan verwijzen.

Gebruik:

"We discussiëren al een halfuur of de wizard één pagina moet zijn of drie stappen."

"Dat lossen woorden niet op — laat de agent beide versies prototypen. We klikken erdoorheen en weten het binnen vijf minuten."

Developer experience — hoe makkelijk een codebase en de bijbehorende toolchain het mensen maken om goed werk te leveren. Goede DX betekent snelle feedback, duidelijke foutmeldingen, documentatie die antwoord geeft op de vraag die je werkelijk hebt, en een installatie die in één keer werkt. De term bestaat al lang vóór AI-programmeren; in dit woordenboek staat die vooral als contrast met AX.

DX is de interactie tussen mens en codebase — meer niet. Het belangrijkste verschil tussen de twee doelgroepen is dat mensen stateful zijn en agents stateless. Een mens leert de codebase één keer en neemt die kennis mee naar elke volgende dag. Daarom is slechte DX te overleven: trage CI omzeilen door pushes te bundelen, ontbrekende documentatie oplossen door één keer in Slack te vragen, verwarrende structuur compenseren door te onthouden waar dingen staan. Die omwegen stapelen zich op, en een team wordt productief in een codebase die het tegenwerkt.

Agents treffen dezelfde codebase zonder die opgebouwde kennis. Een agent is stateless tussen sessies en leert de codebase elke keer opnieuw vanaf nul. Die heeft baat bij een snelle testsuite en duidelijke foutmeldingen, maar alles wat die gisteren ontdekte is verdwenen tenzij het in de omgeving is geschreven, die de agent alleen via toolresultaten waarneemt. Dat is de kloof die AX benoemt: de onderdelen van DX die overeind blijven wanneer de ontwikkelaar een agent is, plus zaken die mensen niet nodig hebben, zoals een leeg contextvenster.

Door de overlap verbetert investeren in DX AX vaak vanzelf — strikte types, snelle tests en voorspelbare structuur helpen beide. Door het verschil geldt dat niet altijd: een prachtige onboardinggids helpt een mens een week lang, maar een agent helemaal niet tenzij die bereikbaar is vanuit AGENTS.md.

Gebruik:

"Onze DX is prima — nieuwe medewerkers zijn binnen een week productief."

"Productief omdat iemand die week naast ze zit. De agent krijgt die week niet; beoordeel AX apart."

Agentervaring — hoe goed de omgeving is ingericht zodat een agent goed werk kan leveren in een codebase. De tegenhanger van DX aan de kant van de agent. Wanneer dezelfde agent goed presteert in de ene repo en slecht in de andere — hetzelfde model, dezelfde agentomgeving — ligt het verschil meestal aan AX. De eerste neiging is het model de schuld geven of de prompt herschrijven; vaker zit de oplossing in de repo.

Goede AX heeft drie hoofddimensies:

AX en DX overlappen — goede checks en een heldere architectuur helpen beide doelgroepen — maar lopen ook uiteen. Mensen kunnen omgaan met kennis die alleen in hoofden zit, trage CI en "vraag Sarah naar de billing module"; agents niet. Agents hebben niets aan IDE-tooltips of fraaie dashboards; ze hebben foutmeldingen als tekst in een toolresultaat nodig. Een codebase kan goede DX en slechte AX hebben.

Vermijd: AX behandelen als synoniem voor DX — de doelgroepen vragen om verschillende investeringen.

Gebruik:

"De agent schrijft geweldige code in de API-repo en rommel in de frontend."

"De API-repo heeft strikte types en een snelle testsuite; de frontend heeft geen van beide en veertig skills die altijd worden geladen. Dat is een AX-kloof, geen modelprobleem."

Een werksysteem waarin agent-sessions door triggers worden gestart — een aangemaakt issue, een schema, een CI-fout, het afronden van een andere session — in plaats van door een mens. Daardoor draait meer werk AFK en gaat menselijke aandacht naar de resterende beslissingen human-in-the-loop.

Zonder factory begint elke session omdat iemand haar start. Zelfs volledig AFK-werk wacht op iemand die de session opent, naar de ticket verwijst en haar op gang brengt. Teams willen meer opleveren dan dat toestaat. Een factory haalt de mens weg bij het starten van sessions, maar hoeft die niet uit andere stappen te halen.

Veelvoorkomende triggers en de sessions die ze starten:

Een factory hoeft niet het hele softwareproces te omvatten. Eén cronjob die één soort session uitvoert en één controleerbare PR opent, is al een factory. Klein beginnen is nuttig: een smalle lus levert kleine, vergelijkbare PR's op. Door die te reviewen zie je hoeveel vertrouwen de lus verdient voordat je haar uitbreidt.

Mensen kunnen overal in een factory zitten — issues schrijven en labelen die sessions starten, een plan goedkeuren voordat de implementatie begint, human review doen vóór het mergen. Bepalen welke van die beslissingen menselijk blijven, is de belangrijkste ontwerpvraag. Een codebase, of een deel ervan, waarvan geen mens de uitvoer van de factory reviewt, is een dark factory.

Gebruik:

"Wie heeft alle `no-floating-promises`-overtredingen opgelost?"

"De factory. De cronjob pakt elke nacht één lintregel en opent een PR. Ik review die alleen 's ochtends."

Een codebase, of een deel ervan, waarin een software factory de code schrijft en geen mens die leest. Er is geen human review. Mensen kunnen nog steeds de issues schrijven waarmee het werk begint. Maar niemand leest de code die eruit voortkomt. De naam verwijst naar fabrieken die zonder mensen op de werkvloer draaien.

Een dark factory is vibe coding voor een deel van de codebase, niet voor één wijziging. Bij vibe coding kies je ervoor een wijziging die je hebt gevraagd niet te lezen. Je weet wel dat die wijziging bestaat. In een dark factory maakt het team die keuze één keer voor het hele gebied. Daarna vraagt niemand om elke wijziging en ziet niemand die. Wijzigingen komen binnen zodra triggers nieuw werk starten.

Het probleem wordt zichtbaar zodra er iets stukgaat. Je weet niet wat er is veranderd, omdat niemand de wijzigingen heeft gelezen. Je moet code debuggen die niemand in het team heeft gelezen. De oorzaak kan in een van de vele wijzigingen zitten, en elk ervan is door de checks gekomen.

Automated checks en automated review zijn de enige poorten. Als ze een probleem niet vinden, belandt het in de code.

Vermijd: een codebase “dark” noemen alleen omdat de fabriek draait zonder dat iemand meekijkt. Als agent-sessions AFK draaien en een mens hun PR’s beoordeelt, is dat een software factory. Geen dark factory.

Gebruik:

“Wie heeft de retry-logica in de billing service aangepast? Niemand in het team weet het nog.”

“De billing service is een dark factory. De agents mergen alle wijzigingen die CI doorstaan. Niemand heeft die wijziging gelezen.”