Context Engineering

01

Waarom dit, waarom nu

Een klant schrijft: kan ik mijn geld terug voor het jaarabonnement dat ik drie weken geleden kocht? De oude aanpak is één prompt, waarin je de vraag en het retourbeleid en misschien de accountgegevens plakt, en hoopt dat het model in dat ene bericht heeft wat het nodig heeft.

De aanpak van dit dossier is anders. Een systeem zoekt het echte account en de aankoopdatum van deze klant op, haalt het actuele retourbeleid erbij, laadt de specifieke regel voor jaarabonnementen, kijkt of er een goedkeuringsgrens geldt, en antwoordt pas daarna, met doorverwijzing naar een mens als de regels dat voorschrijven. Het verschil is geen slimmere zin. Het is een systeem dat de juiste informatie verzamelt, en alleen de juiste, voordat het model spreekt.

Twee jaar lang was de geadverteerde vaardigheid van het AI-tijdperk prompt engineering: formuleer het verzoek precies goed en het model levert. Voor agents wordt die vaardigheid stilletjes met pensioen gestuurd, want één slimme prompt is niet genoeg voor een systeem dat vijftig stappen draait, gereedschap aanroept en onderweg informatie opstapelt. Wat ervoor in de plaats kwam is context engineering: bepalen wat het model bij elke stap ziet.

Andrej Karpathy, die er zoveel aan deed om de term te populariseren, omschrijft het als de subtiele kunst en wetenschap van het contextvenster vullen met precies de juiste informatie voor de volgende stap. Tobi Lütke van Shopify duwde dezelfde herkadering, en Anthropic schreef het officieel op in een handleiding getiteld "Effective context engineering for AI agents". Dit is deel drie van een handleiding in vijf delen. Deel één ging over de lus en deel twee over de harness; context engineering is het vak dat binnen de eerste fase van de lus leeft, Ophalen, en daar wordt een groot deel van de betrouwbaarheid van een agent gewonnen of verloren.

02

1. Waarom nu: prompt engineering gaat met pensioen

De geadverteerde vaardigheid van het vroege AI-tijdperk was formuleren: zeg het op de juiste manier en het model presteert. Voor alles wat langer draait dan één uitwisseling is die vaardigheid tegen haar grens gelopen, want een agent die vijftig stappen zet en gereedschap aanroept en informatie opstapelt, valt niet met één perfecte zin bij te sturen. Het sturen gebeurt nu in de context.

Het loont 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 maakt. Alles wat het model op dat moment weet, de instructies en de vraag en eventuele documenten en het gesprek tot dan toe, moet fysiek in dat venster passen. Het model kan je database of je wiki of het gesprek van vorige week niet zien, tenzij iets het relevante stuk eerst in het venster legt. Het redeneert over wat er voor hem ligt en over niets anders.

Dat ene feit is de hele reden dat context engineering bestaat. Kan het model alleen gebruiken wat in het venster staat, dan is de kwaliteit van zijn antwoord begrensd door de kwaliteit van wat je erin legt. Prompt engineering was het vak van één goed blok tekst met de hand in dat venster schrijven. Context engineering is het vak van automatisch en bij elke stap bepalen welke stukken van een veel grotere wereld nu geladen worden en welke buiten blijven.

03

2. Prompt engineering tegenover context engineering

De schoonste manier om de verschuiving te zien is de twee naast elkaar leggen.

Prompt engineering behandelt één invoer als de eenheid van werk. Je zet een rol, wat context, instructies, voorbeelden en een format samen in één bericht, en valt het antwoord tegen, dan is de vaardigheid het herkennen van welk ingrediënt je in de steek liet. 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 veel stappen heen. De beschikbare informatie blijft groeien, want een gereedschap geeft een resultaat terug en de gebruiker zegt iets nieuws en er wordt een document opgehaald, terwijl het venster een vaste maat houdt. Er moet dus bij elke stap iets besluiten wat erin gaat en wat erbuiten blijft.

Neem één stap van de retour-agent uit de opening, van binnenuit gezien. Voordat het model een woord schrijft, bepaalt het systeem wat deze stap nodig heeft: het accountgegeven van de klant, zodat het abonnement en de aankoopdatum bekend zijn, het retourbeleid met de regels, en de laatste paar berichten zodat het in het gesprek blijft. Het laat bewust weg: de handleiding van vierhonderd pagina's, de ongerelateerde supporthistorie van twee jaar geleden, en het interne prijzenoverzicht van het bedrijf. Niets daarvan helpt bij een retourvraag, en elk stuk ervan zou het venster vullen en de aandacht van het model van het punt aftrekken.

Die beslissing, herhaald bij elke stap, is het hele spel. Prompt engineering vraagt hoe je dit moet formuleren. Context engineering vraagt wat het model nu moet zien, en wat eruit moet blijven. De tweede vraag is degene die meeschaalt naar echt werk.

04

3. De curator: selecteren, samenvatten, weggooien

Het denkbeeld dat dit concreet maakt is een curator. Tussen alles wat de agent beschikbaar heeft, de vraag van de gebruiker en de systeeminstructie en opgehaalde documenten en gereedschapsuitvoer en geheugen en elke eerdere beurt, en het eindige venster, zit een curator die bepaalt wat het model deze stap werkelijk te zien krijgt.

De curator doet drie dingen: selecteren, samenvatten, weggooien. Elk is het zien waard met een voorbeeld.

Selecteren: kiezen wat erbij hoort

Selecteren is bepalen welke van de vele dingen die je het model deze stap zou kunnen tonen hun plek werkelijk verdienen. Voor de retour-agent betekent selecteren dat het account van deze klant en het retourbeleid worden opgehaald, en niet de hele kennisbank. Selecteren is vaak het verschil tussen een systeem dat scherp aanvoelt en een dat vaag blijft: een juridische agent die een contract beoordeelt hoort de drie clausules te krijgen die de vraag raken en niet alle negentig pagina's, want negentig pagina's grotendeels irrelevante tekst is hoe je een zelfverzekerd antwoord over de verkeerde clausule krijgt.

Samenvatten: krimpen wat omvangrijk maar nuttig is

Samenvatten is iets nemen dat je wél nodig hebt maar dat te groot is, en het terugbrengen tot het deel dat ertoe doet. Een supportagent heeft niet het volledige transcript van veertig eerdere tickets nodig; hij heeft een samenvatting van drie regels nodig, in de trant van: langdurige klant, had in maart een facturatiegeschil dat is opgelost, heeft voorkeur voor e-mail. Die samenvatting is misschien 200 tokens die er 20.000 vervangen. Goed gedaan houdt samenvatten het signaal en gooit het de omvang weg.

Weggooien: wegdoen wat verlopen is

Weggooien is verwijderen wat zijn plek niet langer verdient. Tien stappen ver in een taak is de ruwe uitvoer van een zoekopdracht uit stap twee meestal rommel, want de nuttige conclusie is er al uit gehaald en het model heeft de veertig ruwe resultaten niet meer nodig. Ze laten staan vult het venster en bedelft wat ertoe doet.

Het contra-intuïtieve deel, en wat goed contextwerk 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 níét hoeft te zien, zodat wat het wél moet zien opvalt.

05

4. Wat er werkelijk in het venster zit

Om dit tastbaar te maken helpt het te kijken wat een contextvenster tijdens één stap echt bevat, en hoe groot elk stuk is. De maat is tokens, ruwweg driekwart woord elk, en een gangbaar modern venster houdt er zo'n 200.000. De cijfers hieronder zijn ronde getallen om de mechaniek te leren en geen meting van een specifiek systeem.

Een gezond venster voor de retour-agent bij één vraag ziet er zo uit. De systeeminstructie plus de actieve vaardigheid met de retourregels kost ongeveer 2.000 tokens. Het accountgegeven met aankoopdatum ongeveer 1.000. Het retourbeleid, alleen het relevante deel, ongeveer 1.500. De laatste vier berichten van dit gesprek ongeveer 2.000. Samen zo'n 6.500 van de 200.000 gebruikt, en ruim 193.000 vrij voor het model om over te redeneren en te antwoorden.

Dezelfde taak, gebouwd op de naïeve manier door iemand die redeneert dat meer context alleen maar kan helpen, ziet er anders uit. De hele producthandleiding, voor de zekerheid erin gedumpt, kost ongeveer 160.000 tokens. De volledige tweejarige supporthistorie van deze klant ongeveer 28.000. Het prijzenoverzicht met alle abonnementen ongeveer 9.000. En het retourbeleid, begraven rond regel 50.000, ongeveer 1.500. Samen zo'n 198.500 gebruikt, en 1.500 over voor het model.

Het tweede venster bevat technisch gezien het goede antwoord, want het retourbeleid zit er ergens in, en het presteert slechter, vaak veel slechter. Het beleid ligt begraven onder 190.000 tokens ruis, het model heeft nauwelijks ruimte over om te redeneren, en het kost dertig keer zoveel per aanroep. Dit is de meest voorkomende fout die wij in echte uitrol zien, en ik zie hem vaker bij ervaren bouwers dan bij beginners, en precies waarom context engineering ertoe doet: de tweede bouwer deed méér werk en kreeg een slechter systeem.

06

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 aan achtergrond opgaat, is een token die het model niet aan redeneren kan besteden. Vul het venster met een handleiding en er blijft geen ruimte over om de eigenlijke vraag te doordenken.

Modellen raken de weg kwijt in het midden. Dat is een echt, gemeten effect: een model let het meest op het begin en het eind van zijn context en het minst op het midden, dus een cruciaal feit halverwege een lang document wordt vaak simpelweg gemist, zoals je het midden van een lange mail scant en alleen de bovenkant en de afsluiting opvangt. Liu en collega's legden dit vast en noemden het lost in the middle. Het betekent dat wáár een feit in het venster staat uitmaakt, en niet alleen of het er staat, en het retourbeleid op regel vijftigduizend van een opgeblazen venster is technisch aanwezig en praktisch onzichtbaar.

Context rot. Terwijl een agent draait, stapelen verlopen gereedschapsuitvoer en verlaten pogingen en oude beurten zich op, en elk daarvan verdunt de aandacht van het model voor wat nu telt. De kwaliteit kan zakken alleen al doordat het venster langer wordt, nog voordat het vol is, en daarom beschrijft de term evenzeer lengte als veroudering. Een venster dat schoon begon, gaat over een lange taak achteruit tenzij iets het actief snoeit, zoals een bureau dat bedolven raakt onder elk document dat je deze week aanraakte onbruikbaar wordt, ook al ligt het ene dat je nodig hebt er ergens op. Het is het vermelden waard dat context rot vakjargon uit de praktijk is en geen formele onderzoeksbevinding, anders dan lost in the middle.

Bij elkaar betekenen die drie dat een venster vol ruis slechter presteert dan een kort venster met precies de juiste feiten. Daarom is de venstermeter, die iets toont in de trant van 64.000 van 200.000 tokens gebruikt, een getal geworden waar vaklui net zo scherp naar kijken als naar latentie of kosten. Kruipt hij richting vol, dan zakt de kwaliteit, en de oplossing is vrijwel nooit een groter venster. Het is betere curatie.

07

6. Corrigeren of terugspoelen: wat je weghaalt telt

Eén techniek maakt de discipline tastbaar: hoe je met een verkeerde afslag omgaat. Gaat een agent een slecht pad op, dan zijn er twee manieren om te herstellen, en ze laten het venster in een heel verschillende staat achter.

Denk aan een codeer-agent die een bug moet oplossen. Hij leest drie bestanden, schrijft een reparatie, draait de tests, en twee falen. Hij probeert een tweede reparatie en er faalt er nog één. Dan vindt hij de echte oorzaak en lost het goed op. Er zijn nu twee manieren om verder te gaan.

Corrigeren laat de hele geschiedenis in het venster staan: de drie bestanden, de eerste kapotte reparatie, de falende tests, de tweede kapotte reparatie, de nog steeds falende test, en ten slotte de werkende reparatie. Het werkt, en het venster draagt nu een lang verslag van de rommel, dus elke latere stap moet om twee doodlopende wegen heen redeneren 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 reparatie gevonden is, houdt het systeem alleen het schone pad over, de gelezen bestanden en het werkende resultaat, en verwijdert het de twee doodlopende wegen alsof ze er nooit waren. Het venster blijft slank en het model redeneert over het antwoord in plaats van over de omweg. Terugspoelen is meer werk om te bouwen, en volgens onze eigen ervaring vrijwel altijd de betere strategie. Ik ben hem gaan aanhouden nadat een agent van ons drie keer op zijn eigen mislukte poging terugviel. Het is het duidelijkste voorbeeld van de regel dat wat je weghaalt even belangrijk is als wat je houdt. Een mens maakt aantekeningen en gooit het kladpapier weg, en een goed gebouwde agent hoort dat met zijn eigen context ook te doen.

08

7. Geheugen: context die blijft

Alles tot hier gebeurt binnen één taak. Context heeft ook een tijdsdimensie, en die heet geheugen. Een kaal model begint elk gesprek vanaf nul, dus sluit het venster en het is alles vergeten. Een bruikbare agent doet dat niet, en geheugen is het mechanisme dat relevante context meedraagt over stappen en over sessies heen, zodat de agent weet wat hij gisteren deed en wat je voorkeuren zijn en wat hij al geprobeerd heeft.

Het helpt geheugen in twee soorten te splitsen. Kortetermijngeheugen is wat de agent binnen één taak meedraagt, de werkaantekeningen die hij onderweg 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 oplossing vorige keer niet werkte. Langetermijngeheugen woont meestal in opslag buiten het model, of dat nu een bestand is of een database of een notitiesysteem, en de cruciale zet is dat alleen het relevante deel terug in het venster wordt gehaald wanneer het nodig is.

Zo werkt dat in de praktijk. Een terugkerende klant schrijft de supportagent. Het langetermijngeheugen bevat een kort profiel dat uit eerdere contacten is opgebouwd: enterprise-klant sinds 2023, had in april een datamigratieprobleem dat door het integratieteam is opgelost, houdt van beknopte antwoorden, biedt geen telefonische ondersteuning aan want die is twee keer afgewezen. Schrijft deze klant, dan trekt de agent dat profiel in het venster en begroet hem als de terugkerende enterprise-klant die hij is, in plaats van vragen te stellen waarvan hij het antwoord al hoort te weten. De klant voelt zich gekend. Er gebeurde niets magisch; het juiste geheugen werd op het juiste moment het venster in gecureerd.

De val is geheugen als stortplaats behandelen en de hele historie van een klant in de prompt kieperen, wat het opgeblazen venster is met een andere hoed op. Goed geheugen is zelf een curatievraagstuk, onderworpen aan dezelfde discipline van selecteren, samenvatten en weggooien, alleen nu over de tijd heen: houd de duurzame feiten, vat de episodes samen, en haal alleen op wat dit moment vraagt. Goed gedaan laat geheugen een agent aanvoelen alsof hij competentie opbouwt. Slecht gedaan is het ruis met een langer bereik.

09

8. Ophalen: de juiste context binnenhalen

Geheugen beantwoordt wat we al over deze situatie weten. Ophalen beantwoordt wat we weten dat relevant is, uit alles wat de organisatie ooit heeft opgeschreven. Het is het mechanisme dat de juiste documenten of gegevens of feiten van buiten het model haalt en in het venster legt. Dit is het idee achter retrieval-augmented generation, meestal afgekort tot RAG, en het blijft het werkpaard van de meeste echte uitrol omdat het het model in jouw data aardt in plaats van in zijn training.

Zo werkt het, eenvoudig gezegd. Je documenten, dus producthandleidingen en beleid en eerdere tickets, worden in kleine stukken geknipt en zo opgeslagen dat het systeem ze op betekenis kan doorzoeken en niet alleen op trefwoord. Komt er een vraag binnen, dan zoekt het systeem de stukken die het meest bij die specifieke vraag horen en legt er een handvol in het venster. Een vraag over retouren haalt de retourstukken op, een vraag over installatie de installatiestukken, en het model beantwoordt elk geaard in het juiste bronmateriaal.

Context engineering herkadert ophalen wel, en die herkadering telt. Het doel is precies ophalen in plaats van maximaal: haal exact op wat de stap nodig heeft en niet meer. Vergelijk twee bouwsels van dezelfde supportagent. De luie bouw haalt de twintig stukken op die het losjes met de vraag te maken hebben en dumpt ze allemaal. De helft is vaag relevant, het venster loopt vol, en het model, kwijt in het midden, antwoordt soms uit het verkeerde stuk. De zorgvuldige bouw haalt de drie meest relevante stukken op, controleert of ze de vraag werkelijk raken, brengt elk terug tot zijn kernregels, en legt ze waar het model erop let. Dezelfde onderliggende documenten, hetzelfde model. De tweede antwoordt veel vaker juist, kost minder, en is makkelijker te vertrouwen.

Ophalen is een leverancier aan de curator en geen vervanging ervan. Halen is alleen de eerste zet, en het selecteren en samenvatten en plaatsen van wat gehaald is, is de rest. De kwaliteit van de antwoorden van een agent volgt bijna een-op-een de kwaliteit van wat zijn ophaalstap hem voorzet, en daarom stelt "gooi er RAG tegenaan" zo vaak teleur en werkt zorgvuldig ophalen zo vaak wel.

10

9. Vaardigheden: een agent een procedure leren, op afroep

Tot hier was de context feiten: accounts, beleid, documenten, herinneringen. Een model moet ook weten hóé dingen gaan, de procedures en conventies die specifiek zijn voor jouw bedrijf, en dat is wat een vaardigheid is.

Een vaardigheid is een op zichzelf staand pakketje 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 de plank kan pakken. In zijn simpelste vorm is het een klein tekstbestand met drie delen: een naam, een regel over wanneer je het gebruikt, en de instructies zelf.

Voor retouren ziet zo'n bestand er ongeveer zo uit. De naam is retourbeleid. De omschrijving luidt: hoe je retour- en annuleringsverzoeken afhandelt, te gebruiken wanneer een klant vraagt naar geld terug, annuleren of restitutie. En de instructies zijn een genummerde lijst. Controleer de aankoopdatum op het account. Binnen veertien dagen: keur een volledige terugbetaling goed. Dag vijftien tot dertig: bied een terugbetaling naar rato. Boven de 500 euro eerst goedkeuring van een leidinggevende. Na dertig dagen: geen contant geld terug, wel tegoed. Beloof het geld nooit binnen vijf werkdagen terug. En is de klant boos of noemt hij een chargeback, geef dan meteen over aan een mens.

Twee dingen daaraan zijn het overdenken waard, want ze zijn het hele punt.

De omschrijving is de truc. De agent draagt niet altijd de volledige instructies van elke vaardigheid mee. Hij draagt alleen de regels met de omschrijvingen, wat vrijwel niets kost, en leest de volledige tekst van een vaardigheid pas wanneer de omschrijving past bij wat er speelt. Dit heet progressive disclosure, of laden op het juiste moment: de retourinstructies komen het venster in zodra er een retourvraag verschijnt en blijven er de rest van de tijd buiten. Het is de selecteer-en-gooi-weg-logica van de curator, toegepast op de eigen instructies van de agent.

Het lost het probleem van de reusachtige systeeminstructie op. Het verleidelijke alternatief is één enorme set instructies schrijven, elke regel voor elke situatie, en die bij elke aanroep aan het model geven. Dat faalt om precies de redenen uit sectie vijf: het vult het budget, bedelft de regel die telt onder vijftig die dat niet doen, en verdunt de aandacht van het model. Vaardigheden houden het werkende venster klein en laden de juiste procedure op het juiste moment. Een bedrijf heeft misschien vijftig vaardigheden, een voor retouren en een voor onboarding en een voor het afhandelen van een securitymelding en een voor de merkstem, terwijl de agent er nooit meer dan twee of drie tegelijk vasthoudt.

Vaardigheden kunnen meer bevatten dan een checklist: een uitgewerkt voorbeeld, een sjabloon om te volgen, zelfs een klein script dat de agent draait. De kern is simpel. Een vaardigheid is hoe je een agent één keer, in gewone taal, een specifieke manier van werken leert, en die kennis alleen laat toepassen wanneer ze relevant is.

11

10. Gedeelde context in een organisatie

Alles tot hier ging over één agent. De grotere prijs, en het lastigere probleem, is context op de schaal van een hele organisatie.

Begin bij hoe het misgaat, want dat is overal te zien. Het salesteam heeft zijn eigen versie van de prijsregels in zijn eigen chatbot geplakt. Het supportteam heeft een andere versie in de zijne. Iemand bij onboarding schreef een derde. Het retourbeleid veranderde in maart en twee van de drie citeren nog de oude. Een klant stelt dezelfde vraag op twee plekken en krijgt twee verschillende antwoorden. Elk team doet aan context engineering, slecht en in isolement, en de uitkomsten lopen uiteen.

Een bedrijf dat dit goed doet bouwt één gedeelde contextlaag waar elke agent, en vaak elke medewerker, uit put. Daaronder liggen drie lagen.

• Duurzame feiten: wat waar is tot iemand het verandert, dus productspecificaties, beleid, merkstem, het organogram. Eén keer opgeschreven, op één plek.
• Geheugen: wat er is gebeurd en besloten, dus klanthistories en eerdere projecten en de redenen achter eerdere keuzes, opgebouwd door de tijd heen.
• Live data: wat nu waar is, op afroep opgehaald uit de bronsystemen, of dat nu het CRM is of de ticketwachtrij of voorraad of facturatie.

Daarbovenop zit de curatie, hetzelfde selecteren en samenvatten en weggooien, dat bepaalt welk deel elke agent voor elke taak krijgt. De retourvaardigheid en de prijsfeiten en de merkstem leven in de gedeelde laag, en de salesagent en de supportagent en de onboardingagent lezen er alle drie uit. Verander het retourbeleid één keer, op één plek, en het antwoord van elke agent verandert op hetzelfde moment mee. Die consistentie is de opbrengst.

Hoe goed eruitziet, is met een voorbeeld te schetsen. Een middelgroot bedrijf houdt zijn gedeelde context op één beheerde plek. Elk feit heeft een eigenaar en een datum van laatste controle, zodat niemand op een beleid vertrouwt dat verouderd is. Toegang is afgebakend: de supportagent mag klanthistories lezen, de agent op de publieke website niet. Wijzigt het prijsteam een abonnement, dan werken ze één record bij, en diezelfde middag citeren de salesagent, de supportagent en de interne helpdesk allemaal de nieuwe prijs. Een agent die volgend kwartaal gebouwd wordt, sluit op dag één op dezelfde laag aan in plaats van vanaf een lege prompt te beginnen. De context wordt behandeld als een product dat het bedrijf onderhoudt, niet als tekst die in een dozijn tools is geplakt.

Dit is de organisatorische versie van het eindige venster. Een bedrijf heeft enorm veel dat het zijn AI zou kunnen vertellen, en precies als bij één venster maakt alles in elke agent dumpen ze slechter. Het werk is bepalen wat elke agent hoort te zien, het actueel houden, en het op één plek onderhouden. Het is onglamoureus, het is vooral bestuur en leidingwerk, en wij denken dat daar de duurzame waarde van zakelijke AI wordt beslist.

12

11. Context is nu het product

Zet dit bij elkaar en er verschijnt een strategisch punt. Is het model een grondstof en de harness de machine, dan is context de brandstof, en steeds vaker het product. Twee bedrijven met een identiek model en een vergelijkbare harness krijgen heel verschillende resultaten op grond van één ding: de kwaliteit van de context die elk kan samenstellen, hun data en geheugen en ophaalstap en vaardigheden en curatie.

Dat is goed nieuws voor de meeste bedrijven, want context is het enige deel van de stapel dat inherent van jou is. Jouw documenten, jouw gegevens, jouw institutionele geheugen, de specifieke feiten over hoe jouw bedrijf draait: niets daarvan zit in het model en niets daarvan is beschikbaar voor een concurrent. Een rivaal kan morgen hetzelfde model kopen. Hij kan niet twintig jaar klanthistorie kopen, of moeizaam verworven beleid, of de gedeelde contextlaag waar een jaar in ging om hem schoon te krijgen. Context is waar een generiek model jouw model wordt.

13

12. De eerlijke tegenwerping

Drie kanttekeningen houden dit eerlijk. Ten eerste zijn langere contextvensters echt en ze helpen. Het venster groeit door, en sommige problemen die in 2024 zorgvuldige curatie vroegen passen er tegenwoordig comfortabel in. Een groter budget schaft het lost-in-the-middle-effect of de kosten van ruis alleen niet af. Het tilt het plafond op zonder de discipline weg te nemen, en een groot venster dat slordig gevuld is presteert nog altijd slechter dan een klein venster dat goed gevuld is.

Ten tweede kan context engineering zelf overbouwd raken, met uitgebreide ophaal- en samenvatpijplijnen die meer kosten dan ze opleveren en bewegende delen toevoegen die stukgaan. Soms is het juiste antwoord een groter venster en een simpelere pijplijn, en een deel van de vaardigheid is weten wanneer je curatie zich terugverdient en wanneer ze haar eigen soort opgeblazenheid is geworden.

Ten derde beweegt de frontlijn. Naarmate modellen beter worden in het beheren van hun eigen context, en zelf bepalen wat ze houden en vergeten, verschuift een deel van dit werk het model in, en de grens tussen context engineering en de harness blijft schuiven. Niets daarvan verandert de kernclaim. Voor elke agent die vandaag meerstaps werk doet is de grootste hefboom op kwaliteit, zodra er een capabel model en een werkende harness staan, de context die in het venster gaat.

14

13. Wat een bedrijf hiermee doet

Voor een bestuurder herkadert context engineering waar de waarde van de eigen data werkelijk zit. De neiging is te denken dat het model op de eigen data getraind moet worden, wat duur en traag is. Meestal hoeft dat niet. Het model heeft het juiste deel van die data nodig, in het venster gelegd op het moment dat het werkt, wat goedkoper en sneller en beter te sturen is, en het is waar de meeste zakelijke AI-waarde daadwerkelijk landt.

Concreet wijst dat op een korte lijst investeringen, en geen ervan is een nieuw model. De data schoon en vindbaar krijgen, want de ophaalstap kan alleen naar boven halen wat goed geordend is. De gedeelde contextlaag uit sectie tien bouwen, met eigenaren en versheidsdata, zodat elke agent uit één actuele bron put. De belangrijkste procedures als vaardigheden opschrijven, in gewone taal, zodat het hoe-dan van het bedrijf één keer wordt vastgelegd en op afroep geladen. En meten wat de agents feitelijk te zien krijgen, want een contextprobleem vermomt zich als een modelprobleem tot je in het venster kijkt.

Dit is See, Understand, Adopt toegepast op informatie. Zien dat het antwoord van het model alleen zo goed is als wat je hem voorlegt. Begrijpen wat de drie zetten van de curator zijn, selecteren en samenvatten en weggooien, en waar het eigen proces het venster overspoelt in plaats van te cureren. En dan adopteren door te investeren in het onglamoureuze leidingwerk, dus schone data en goed ophalen en echt geheugen en opgeschreven vaardigheden en een gedeelde contextlaag, dat bepaalt wat het model ziet. Het is minder spannend dan een nieuw model en het doet er meer toe.

De zet: stop met de prompt perfectioneren en begin met de context engineeren. Geef het model het juiste deel van je data, gecureerd en samengevat, bij de juiste stap; leg je procedures vast als vaardigheden; bouw één gedeelde, beheerde contextlaag waar elke agent uit put; en snijd alles weg dat zijn plek in het venster niet verdient.

15

14. Verantwoording en bronnen

Dit dossier steunt op live webresearch en een persoonlijk archief van ruim 15.000 bronnen. Dragende claims zijn waar mogelijk gecontroleerd. De uitgewerkte voorbeelden zijn illustratief, gemaakt om de mechaniek uit te leggen en niet om een specifiek bedrijf te beschrijven. De notities hieronder geven per claim het vertrouwen en de belangrijkste voorbehouden, in de geest van ons uitgangspunt: laat zien hoe je eraan gekomen bent.

De ingekaderde figuur in dit dossier komt uit publiek geplaatst materiaal en is in het bijschrift aan de oorspronkelijke bron toegeschreven. Grafieken met het label "BFF" zijn van ons, getekend naar de bronnen die eronder staan. Voorbeeldbestanden en budgetten zijn illustratief, geschreven om het idee uit te leggen.

Back From the Future · BFF Inzichten · Werken met AI · Deel 3 van 5 · juli 2026