Waarom dit, waarom nu
Twee jaar lang was de geafficheerde vaardigheid van het AI-tijdperk prompt engineering: verwoord het verzoek precies goed en het model levert. Voor agents wordt die vaardigheid stilletjes met pensioen gestuurd. Eén slimme prompt is niet genoeg voor een systeem dat vijftig stappen draait, tools aanroept, en onderweg informatie opstapelt. De vaardigheid die het verving is context engineering: beslissen wat het model bij elke stap ziet.
Hier is de verschuiving in één concreet voorbeeld. Een klant schrijft: "Kan ik mijn geld terug voor het jaarabonnement dat ik drie weken geleden kocht?" De oude manier is één prompt. Je plakt de vraag, plakt het retourbeleid, plakt misschien de accountgegevens, en hoopt dat het model in dat ene bericht heeft wat het nodig heeft. De context-geëngineerde manier is een systeem dat de juiste feiten voor precies dit geval samenstelt: het zoekt het echte account en de aankoopdatum van deze klant op, haalt het huidige retourbeleid erbij, laadt de specifieke regel voor jaarabonnementen, checkt of een drempel voor manager-goedkeuring geldt, en antwoordt pas dan, met opschaling naar een mens als de regels dat zeggen. Het verschil is geen slimmere zin. Het is een systeem dat de juiste informatie verzamelt, en alleen de juiste informatie, voordat het model spreekt.
Andrej Karpathy, die zoveel als wie dan ook deed om de term populair te maken, definieert context engineering als "de tere kunst en wetenschap van het contextvenster vullen met precies de juiste informatie voor de volgende stap." Shopify's Tobi Lütke duwde dezelfde herkadering, en Anthropic maakte het officieel met een gids getiteld "Effective context engineering for AI agents". Dit is deel drie van een vijfdelige handleiding. Deel één was de loop, deel twee de harness; context engineering is de kunst die in de eerste fase van de loop leeft, Verzamelen, en het is waar een groot deel van de betrouwbaarheid van een agent wordt gewonnen of verloren. Dit dossier gaat langzaam en gebruikt voorbeelden, want de ideeën zijn simpel zodra je ze ziet en makkelijk voorbij te lopen als je dat niet doet.
1. Waarom nu: prompt engineering gaat met pensioen
De geafficheerde vaardigheid van het vroege AI-tijdperk was formulering: zeg het op de juiste manier en het model presteert. Voor alles dat langer draait dan één uitwisseling heeft die vaardigheid haar grens bereikt. Een agent die vijftig stappen neemt, tools aanroept en informatie opstapelt, laat zich niet sturen door één perfecte zin. Het sturen gebeurt nu in de context.
Het helpt om precies te zijn over wat "context" hier betekent, want het woord wordt losjes gebruikt. Het contextvenster is het werkgeheugen van een model: het volledige blok tekst waar het naar kan kijken terwijl het zijn volgende antwoord produceert. Alles wat het model op dat moment weet, de instructies, de vraag, eventuele documenten, het gesprek tot nu toe, moet fysiek in dat venster passen. Het model kan je database, je wiki of het gesprek van vorige week niet zien, tenzij iets het relevante stuk eerst in het venster zet. Het redeneert alleen over wat het voor zich heeft, en niets anders.
Dat ene feit is de hele reden dat context engineering bestaat. Als het model alleen kan gebruiken wat in het venster staat, dan is de kwaliteit van zijn antwoord begrensd door de kwaliteit van wat jij daar zet. Prompt engineering was de kunst van één goed blok tekst met de hand in dat venster schrijven. Context engineering is de kunst van beslissen, automatisch en bij elke stap, welke stukken van een veel grotere wereld nú in het venster geladen worden en welke erbuiten blijven. De herkadering heeft echt gezag achter zich: Karpathy benoemde het, Tobi Lütke bepleitte het, en Anthropic schreef de gids. Dit dossier loopt door die kunst, met uitgewerkte voorbeelden, en landt op waarom, voor een bedrijf, context het deel van de AI-stack is dat inherent van jou is.
2. Prompt engineering versus context engineering
De helderste manier om de verschuiving te zien is de twee naast elkaar te zetten.
Prompt engineering behandelt één input als de eenheid van werk. Je stelt een rol, wat context, instructies, voorbeelden en een format samen tot één bericht. Als het antwoord tegenvalt, is de vaardigheid ontdekken welk ingrediënt je liet zitten en het herschrijven. Dat is genoeg voor een eenmalige vraag die je één keer stelt en één keer leest.
Context engineering behandelt het venster als de eenheid van werk, over vele stappen. De beschikbare informatie blijft groeien, een tool geeft een resultaat terug, de gebruiker zegt iets nieuws, een document wordt opgehaald, terwijl het venster een vaste grootte houdt. Dus iets moet, bij elke stap, beslissen wat erin gaat en wat eruit blijft. Dat iets is waar dit dossier over gaat. Om het concreet te maken, loop één stap van de retour-agent uit de inleiding door:
Die beslissing, herhaald bij elke stap, is het hele spel. Prompt engineering vraagt "hoe verwoord ik dit?" Context engineering vraagt "wat moet het model nú zien, en wat moet ik eruit houden?" De tweede vraag is degene die naar echt werk schaalt.
3. De curator: selecteren, comprimeren, weggooien
Het mentale model dat dit concreet maakt is een curator. Tussen alles wat de agent ter beschikking heeft, de vraag van de gebruiker, de system prompt, opgehaalde documenten, tool-outputs, geheugen, en elke eerdere beurt, en het eindige venster zit een curator die beslist wat het model deze stap werkelijk te zien krijgt.
De curator doet drie dingen: selecteren, comprimeren, weggooien. Elk is het waard om met een voorbeeld te zien.
Selecteren: kies wat erbij hoort
Selecteren is beslissen welke van de vele dingen die je het model deze stap zou kunnen tonen werkelijk hun plek verdienen. Voor de retour-agent betekent selecteren het account van deze klant en het retourbeleid ophalen, en niet de hele kennisbank. Selecteren is vaak het verschil tussen een systeem dat scherp aanvoelt en een dat vaag aanvoelt: een juridische agent die een contract beoordeelt hoort de drie clausules aangereikt te krijgen die relevant zijn voor de vraag, niet alle negentig pagina's, want negentig pagina's grotendeels irrelevante tekst is hoe je een zelfverzekerd antwoord over de verkeerde clausule krijgt.
Comprimeren: krimp wat omvangrijk maar nuttig is
Comprimeren is iets nemen dat je wél nodig hebt maar dat te groot is, en het reduceren tot het deel dat ertoe doet. Een support-agent heeft niet het volledige transcript van de veertig eerdere tickets van een klant nodig; hij heeft een samenvatting van drie regels nodig: "langdurige klant, had een facturatiegeschil in maart dat is opgelost, geeft de voorkeur aan e-mail." Die samenvatting is misschien tweehonderd tokens die twintigduizend vervangen. Goed gedaan houdt comprimeren het signaal en gooit het de bulk weg.
Weggooien: gooi weg wat verouderd is
Weggooien is verwijderen wat zijn plek niet langer verdient. Tien stappen in een taak is de rauwe output van een zoekactie die de agent bij stap twee draaide meestal enkel rommel, de nuttige conclusie is al geëxtraheerd, en het model heeft de veertig rauwe resultaten niet meer nodig. Ze laten staan helpt niet; het vult het venster en begraaft wat ertoe doet.
Het contra-intuïtieve deel, en het ding dat goed context-werk van slecht scheidt, is dat het vooral gaat over wat je weggooit. Meer erin proppen voelt veilig en is meestal fout. De echte vaardigheid van een curator is aftrekken: weten wat het model niet hoeft te zien, zodat wat het wél nodig heeft eruit springt.
4. Wat er werkelijk in het venster zit
Om dit alles tastbaar te maken, helpt het te kijken naar wat een contextvenster werkelijk bevat tijdens één stap van echt werk, en hoe groot elk stuk is. Groottes worden gemeten in tokens, ruwweg driekwart van een woord elk; een typisch modern venster houdt zo'n tweehonderdduizend tokens. Hier is een gezond budget voor de retour-agent die één vraag beantwoordt:
Klein, gefocust, en het model heeft alle ruimte die het nodig heeft om te denken. Hier is dezelfde taak gebouwd op de naïeve manier, door iemand die redeneert "meer context kan alleen maar helpen":
Het tweede venster bevat technisch het juiste antwoord, het retourbeleid staat er ergens in, maar het presteert slechter, en vaak veel slechter. Het beleid ligt begraven onder honderdnegentigduizend tokens ruis, het model heeft bijna geen ruimte meer om te redeneren, en het kost dertig keer zoveel per aanroep. Dit is de meest voorkomende fout in echte deployments, en het is waarom context engineering ertoe doet: de tweede bouwer deed meer werk en kreeg een slechter systeem. De volgende sectie legt precies uit waarom meer context schaadt.
5. Het venster is eindig, en meer is niet beter
Waarom presteert het opgeblazen venster slechter terwijl het letterlijk meer informatie bevat? Omdat een contextvenster een vast budget is, en drie krachten een vol venster tegen je keren.
Het budget is eindig. Elke token die je aan achtergrond besteedt is een token die het model niet aan redeneren kan besteden. Vul het venster met een handleiding en er is geen ruimte over om de eigenlijke vraag te doordenken.
Modellen raken lost in the middle. Dit is een echt, gemeten effect: een model let het meest op het begin en het einde van zijn context en het minst op het midden. Een cruciaal feit dat halverwege een lang document begraven ligt wordt vaak simpelweg gemist, op dezelfde manier als je het midden van een lange e-mail scant en alleen de kop en de afsluiting opvangt. Onderzoekers documenteerden dit en noemden het "lost in the middle". Het betekent dat wáár een feit in het venster staat ertoe doet, niet alleen of het aanwezig is. Het retourbeleid op regel vijftigduizend van een opgeblazen venster is technisch aanwezig en praktisch onzichtbaar.
Context verrot. Terwijl een agent draait, stapelen verouderde tool-outputs, verlaten pogingen en oude beurten zich op. Elk verdunt de aandacht van het model op wat nu werkelijk telt. Breder gezien kan de kwaliteit simpelweg zakken naarmate het venster langer wordt, zelfs voordat het vol is, en daarom slaat de term evenzeer op lengte als op veroudering. Een venster dat schoon begon degradeert over een lange taak, tenzij iets het actief snoeit, zoals een bureau bedolven onder elk document dat je deze week aanraakte nutteloos wordt ook al ligt het ene dat je nodig hebt er ergens op.
Samen betekenen deze dat een venster volgepropt met ruis slechter presteert dan een kort venster met precies de juiste feiten. Daarom is de contextvenster-meter, een meter die iets toont als vierenzestigduizend van tweehonderdduizend tokens gebruikt, een getal geworden dat praktijkmensen even scherp in de gaten houden als latency of kosten. Als hij naar vol kruipt, valt de kwaliteit, en de fix is bijna nooit een groter venster; het is betere curatie.
6. Corrigeren of terugspoelen: wat je weghaalt telt
Eén techniek maakt de discipline tastbaar: hoe je een verkeerde afslag behandelt. Als een agent een slecht pad inslaat, zijn er twee manieren om te herstellen, en ze laten het venster in heel verschillende staten achter.
Stel je een coding-agent voor die een bug moet fixen. Hij leest drie bestanden, schrijft een fix, draait de tests, en er falen er twee. Hij probeert een tweede fix, en er faalt er nog steeds één. Dan vindt hij de echte oorzaak en fixt hij het goed. Er zijn nu twee manieren om verder te gaan.
Corrigeren laat de hele historie in het venster: de drie bestandslezingen, de eerste kapotte fix, de falende tests, de tweede kapotte fix, de nog steeds falende test, en als laatste de werkende fix. Het werkt, en het venster draagt nu een lang verslag van de rommel, en elke latere stap moet redeneren rond twee doodlopende wegen die er niet meer toe doen. Erger nog, de mislukte pogingen staan in de context als voorbeelden van hoe de code eruitzag, en het model kan in de war raken over welke versie de huidige is.
Terugspoelen gooit de mislukte tak volledig weg. Zodra de echte fix gevonden is, houdt het systeem alleen het schone pad, de bestandslezingen en het werkende resultaat, en verwijdert het de twee doodlopende wegen uit het venster alsof ze nooit gebeurden. Het venster blijft lean, en het model redeneert over het antwoord in plaats van de omweg. Terugspoelen is meer werk om te bouwen, en het is bijna altijd de betere strategie. Het is het helderste voorbeeld van de regel dat wat je weghaalt even belangrijk is als wat je houdt. Een mens maakt aantekeningen en gooit het kladpapier weg; een goed gebouwde agent hoort hetzelfde te doen met zijn eigen context.
7. Geheugen: context die blijft
Alles tot nu toe gebeurt binnen één taak. Maar context heeft ook een tijdsdimensie, en haar naam is geheugen. Een ruw model begint elk gesprek vanaf nul: sluit het venster en het vergeet alles. Een nuttige agent niet, en geheugen is het mechanisme dat de relevante context over stappen en over sessies heen draagt, zodat de agent weet wat hij gisteren deed, wat jouw voorkeuren zijn, en wat hij al probeerde.
Het helpt geheugen in twee soorten te splitsen. Kortetermijngeheugen is wat de agent binnen één taak meedraagt, de werkaantekeningen die hij gaandeweg bijhoudt. Langetermijngeheugen is wat de taak overleeft en de volgende keer beschikbaar is: de voorkeuren van een klant, een besluit dat het team drie maanden geleden nam, het feit dat een bepaalde fix vorige keer niet werkte. Langetermijngeheugen leeft meestal in opslag buiten het model, een bestand, een database, een notitiesysteem, en de cruciale zet is dat alleen de relevante snede terug in het venster wordt getrokken wanneer het nodig is.
De valkuil is geheugen als stortplaats behandelen, de hele historie van een klant in de prompt kieperen. Dat is enkel het opgeblazen venster weer, met een andere pet op. Goed geheugen is zelf een curatieprobleem, onderworpen aan dezelfde selecteren-comprimeren-weggooien-discipline, nu over tijd: houd de duurzame feiten, vat de episodes samen, en trek alleen wat dit moment vraagt. Goed gedaan laat geheugen een agent voelen alsof hij competentie opbouwt. Slecht gedaan is het ruis met een langere reikwijdte.
8. Retrieval: de juiste context binnenhalen
Geheugen beantwoordt "wat weten we al over deze situatie?" Retrieval beantwoordt "wat weten we dat relevant is, uit alles wat de organisatie ooit heeft opgeschreven?" Het is het mechanisme dat de juiste documenten, records of feiten van buiten het model ophaalt en in het venster plaatst. Dit is het idee achter retrieval-augmented generation, meestal afgekort tot RAG, en het blijft het werkpaard van de meeste echte deployments, omdat het het model in jouw data grondt in plaats van in zijn training.
Hier is hoe het werkt, in gewone taal. Je documenten, producthandleidingen, beleid, oude tickets, worden in kleine stukken (chunks) gebroken en opgeslagen op een manier die het systeem laat zoeken op betekenis, niet alleen op trefwoord. Als een vraag binnenkomt, zoekt het systeem naar de chunks die het meest relevant zijn voor die specifieke vraag en zet er een handvol in het venster. Dus een vraag over terugbetalingen haalt de retour-chunks, en een vraag over installatie haalt de installatie-chunks, en het model beantwoordt elke vraag gegrond in het juiste bronmateriaal.
Context engineering herkadert retrieval echter, en de herkadering doet ertoe. Het doel is precieze retrieval in plaats van maximale: haal precies op wat de stap nodig heeft en niet meer. Vergelijk twee bouwsels van dezelfde support-agent:
Retrieval is een leverancier aan de curator, geen vervanging ervan. Ophalen is enkel de eerste zet; selecteren, comprimeren en plaatsen van wat is opgehaald is de rest. De kwaliteit van de antwoorden van een agent volgt, bijna één op één, de kwaliteit van wat zijn retrieval hem voorschotelt, en daarom stelt "gewoon RAG erbij" zo vaak teleur en werkt zorgvuldige retrieval zo vaak.
9. Skills: een agent een procedure leren, op afroep
Tot nu toe was de context feiten: accounts, beleid, documenten, herinneringen. Maar een model moet ook weten hoe het dingen doet, de procedures en conventies die specifiek zijn voor jouw bedrijf, en dat is wat een skill is.
Een skill is een op zichzelf staand pakket instructies voor één soort taak, dat de agent alleen laadt wanneer die taak zich voordoet. Zie het als een kort draaiboek dat de agent van een plank kan pakken. In zijn simpelste vorm is het een klein tekstbestand met drie delen: een naam, een regel over wanneer het te gebruiken, en de eigenlijke instructies. Hier is een realistisch voorbeeld:
Twee dingen hieraan zijn het waard om bij stil te staan, want ze zijn het hele punt.
De description is de truc. De agent draagt niet de volledige instructies van elke skill de hele tijd mee. Hij draagt alleen de regel-per-skill descriptions mee, een minieme kost, en leest de volledige body van een skill alleen wanneer de description matcht met wat er gebeurt. Dit heet progressive disclosure, of just-in-time laden: de retourinstructies komen het venster in op het moment dat een retourvraag verschijnt, en blijven er de rest van de tijd buiten. Het is de selecteren-en-weggooien-logica van de curator, toegepast op de eigen instructies van de agent.
Het lost het probleem van de gigantische system prompt op. Het verleidelijke alternatief is één enorme set instructies schrijven, elke regel voor elke situatie, en die het model bij elke aanroep geven. Dat faalt om precies de redenen uit sectie vijf: het vult het budget, begraaft de regel die ertoe doet onder vijftig die dat niet doen, en verdunt de aandacht van het model. Skills houden het werkvenster klein en laden de juiste procedure op het juiste moment. Een bedrijf kan vijftig skills hebben, één voor terugbetalingen, één voor onboarding, één voor het afhandelen van een security-melding, één voor de tone-of-voice van het merk, en de agent houdt er altijd maar twee of drie vast die relevant zijn voor de taak voor zich.
Skills kunnen meer bevatten dan een checklist: een uitgewerkt voorbeeld, een template om te volgen, zelfs een klein script dat de agent draait. Maar de essentie is simpel. Een skill is hoe je een agent één keer een specifieke manier van iets doen leert, in gewone taal, en die kennis alleen laat toepassen wanneer ze relevant is, zonder er de rest van de tijd voor te betalen.
10. Gedeelde context in een organisatie
Alles tot nu toe ging over één agent. De grotere prijs, en het moeilijkere probleem, is context op de schaal van een hele organisatie. Hoe ziet het eruit als een bedrijf dit goed voor elkaar heeft?
Begin met hoe het eruitziet als het misgaat, want dat is overal. Het salesteam heeft zijn eigen versie van de prijsregels in zijn eigen chatbot geplakt. Het supportteam heeft een andere versie in het hunne. Iemand in onboarding schreef een derde. Het retourbeleid veranderde in maart, en twee van de drie citeren nog het oude. Een klant stelt dezelfde vraag op twee plekken en krijgt twee verschillende antwoorden. Elk team doet context engineering, slecht en in isolatie, en de resultaten drijven uiteen.
Een bedrijf dat dit goed doet bouwt één gedeelde contextlaag waar elke agent, en vaak elke medewerker, uit put. Er zitten drie lagen onder:
- Duurzame feiten: de dingen die waar zijn tot iemand ze verandert, productspecs, beleid, tone-of-voice, het organigram. Eén keer geschreven, op één plek.
- Geheugen: wat er is gebeurd en besloten, klanthistories, oude projecten, de redenen achter oude keuzes, dat zich over tijd opstapelt.
- Live data: wat nú waar is, op afroep opgehaald uit de bronsystemen, het CRM, de ticket-wachtrij, voorraad, facturatie.
Bovenop die drie zit de curatie, dezelfde selecteren, comprimeren, weggooien, die beslist welke snede elke agent voor elke taak krijgt. De retour-skill, de prijsfeiten en de tone-of-voice leven in de gedeelde laag, en de sales-agent, de support-agent en de onboarding-agent lezen er allemaal uit. Verander het retourbeleid één keer, op één plek, en het antwoord van elke agent verandert mee, op hetzelfde moment. Die consistentie is de opbrengst.
Dit is de organisatie-versie van het eindige venster. Een bedrijf heeft een enorme hoeveelheid die het zijn AI zou kunnen vertellen, en, precies als bij één venster, maakt alles in elke agent kieperen ze slechter, niet beter. Het werk is beslissen wat elke agent zou moeten zien, het actueel houden, en het op één plek onderhouden. Het is oninteressant, het is vooral governance en loodgieterswerk, en het is waar de echte, duurzame waarde van enterprise-AI wordt beslist.
11. Context is nu het product
Zet deze samen en er ontstaat een strategisch punt. Als het model een handelswaar is en de harness de machine, is context de brandstof, en steeds meer is het het product. Twee bedrijven die hetzelfde model en een vergelijkbare harness gebruiken krijgen heel verschillende resultaten op grond van één ding: de kwaliteit van de context die elk kan samenstellen, zijn data, zijn geheugen, zijn retrieval, zijn skills, zijn curatie.
Dat is goed nieuws voor de meeste bedrijven, want context is het ene deel van de stack dat inherent van jou is. Jouw documenten, jouw records, jouw institutionele geheugen, de specifieke feiten van hoe jouw bedrijf werkt, niets ervan zit in het model, en niets ervan is beschikbaar voor een concurrent. Een rivaal kan morgen hetzelfde model kopen. Hij kan jouw twintig jaar klanthistorie niet kopen, jouw moeizaam verworven beleid niet, of de gedeelde contextlaag die je een jaar lang schoon kreeg. Het bedrijf dat de juiste snede van zijn eigen context op het juiste moment voor een model kan krijgen heeft een voordeel dat geen model-upgrade aan iedereen tegelijk uitdeelt. Context is waar een generiek model jouw model wordt.
12. Het eerlijke tegengeluid
Drie kanttekeningen houden dit eerlijk. Ten eerste: langere contextvensters zijn echt en ze helpen; het venster blijft groeien, en sommige problemen die in 2024 zorgvuldige curatie nodig hadden passen vandaag comfortabel. Een groter budget schaft het lost-in-the-middle-effect of de kosten van ruis echter niet af; het verhoogt het plafond zonder de discipline weg te nemen, en een groter venster achteloos gevuld presteert nog steeds slechter dan een klein venster goed gevuld.
Ten tweede: context engineering kan zelf over-geëngineerd worden: uitgebreide retrieval- en compressie-pijplijnen die meer kosten dan ze opleveren, en die bewegende delen toevoegen die breken. Soms is het juiste antwoord een groter venster en een simpelere pijplijn, en een deel van de vaardigheid is weten wanneer jouw curatie zijn plek verdient en wanneer het zijn eigen soort opgeblazenheid is geworden.
Ten derde: de grens beweegt. Naarmate modellen beter worden in het beheren van hun eigen context, zelf beslissend wat te houden en wat te vergeten, zal een deel van dit werk in het model schuiven, en zal de lijn tussen context engineering en de harness blijven verschuiven. Niets daarvan verandert echter de kernclaim. Voor elke agent die vandaag meerstaps-werk doet is de grootste hefboom op kwaliteit, zodra je een capabel model en een werkende harness hebt, de context die je in het venster zet. Krijg dat goed en middelmatige prompts werken nog. Krijg het fout en de beste prompt ter wereld redeneert over rommel.
13. Wat een bedrijf hiermee doet
Voor een leider herkadert context engineering waar de waarde van je data werkelijk zit. Het instinct is te denken dat het model op jouw data getraind moet worden, een dure en trage propositie. Meestal niet. Het heeft de juiste snede van jouw data nodig, in het venster geplaatst op het moment dat het werkt, wat goedkoper, sneller en beter beheersbaar is, en waar de meeste enterprise-AI-waarde werkelijk wordt gerealiseerd.
Concreet wijst dat naar een korte lijst investeringen, en geen ervan is een nieuw model. Krijg je data schoon en vindbaar, want retrieval kan alleen naar boven halen wat goed geordend is. Bouw de gedeelde contextlaag uit sectie tien, met eigenaren en actualiteitsdatums, zodat elke agent uit één actuele bron put. Schrijf je belangrijke procedures als skills, in gewone taal, zodat het hoe-dan van je bedrijf één keer wordt vastgelegd en op afroep geladen. En meet wat je agents werkelijk te zien krijgen, want een contextprobleem verbergt zich als een modelprobleem tot je in het venster kijkt.
Dit is de See, Understand, Adopt-methode toegepast op informatie. Zie dat het antwoord van het model alleen zo goed is als wat je ervoor zet. Begrijp de drie zetten van de curator, selecteren, comprimeren, weggooien, en waar jouw proces het venster overspoelt in plaats van cureert. Adopteer dan door te investeren in het oninteressante loodgieterswerk, schone data, goede retrieval, echt geheugen, geschreven skills, een gedeelde contextlaag, dat bepaalt wat het model ziet. Het is minder spannend dan een nieuw model, en het doet er meer toe.
14. Verificatie en bronnen
Dit dossier steunt op live webonderzoek en een persoonlijk archief van meer dan 15.000 bronnen. Dragende claims zijn waar mogelijk dubbel gecheckt. De uitgewerkte voorbeelden zijn illustratief, gebouwd om de mechaniek uit te leggen en niet om een specifiek genoemd bedrijf te beschrijven. De noten hieronder markeren vertrouwen en de belangrijkste kanttekeningen, in de geest van ons werk laten zien.
| Claim | Vertrouwen | Noot |
|---|---|---|
| Karpathy's definitie van context engineering | Hoog | Andrej Karpathy, 2025; breed woordelijk geciteerd. |
| Tobi Lütke maakte de herkadering populair; Anthropic publiceerde "Effective context engineering for AI agents" | Hoog | Publieke uitspraken; Anthropic engineering, september 2025. |
| Het curator-model: selecteren, comprimeren, weggooien; "meer over wat je weggooit" | Kadering | Context-engineering-praktijk (akshay_pachaar; Anthropic), 2025-26. |
| Eindig venster; "lost in the middle"; context rot | Hoog / Middel | "Lost in the middle" is een gevestigde onderzoeksbevinding (Liu et al.); "context rot" is praktijkterminologie. |
| Token-groottes en venster-budgetten in de voorbeelden | Illustratief | Ronde getallen gekozen om de mechaniek te leren; echte groottes verschillen per model en document. |
| Corrigeren versus terugspoelen als herstelstrategieën | Middel | Context-management-praktijk, 2026. |
| Retrieval (RAG) grondt modellen in jouw data; haal precies op, niet maximaal | Hoog | Gevestigde praktijk. |
| Skills als benoemde, beschreven, on-demand instructiebestanden; progressive disclosure | Middelhoog | Anthropic Agent Skills en vergelijkbare aanpakken, 2025-26. Het voorbeeldbestand is illustratief. |
| Gedeelde organisatie-contextlaag (duurzame feiten, geheugen, live data) met governance | Kadering | Synthese van enterprise-AI-praktijk; het scenario is illustratief. |
De ingekaderde figuur in dit dossier komt uit publiek geplaatst materiaal, gecrediteerd aan de oorspronkelijke bron in het onderschrift. Grafieken met "BFF" zijn van onszelf, getekend uit de eronder genoemde bronnen. Voorbeeldbestanden en budgetten zijn illustratief, geschreven om het idee te leren. De grafieklabels zijn in het Engels gehouden zodat termen één op één met de bronnen te vergelijken zijn.