Context Engineering: Wat Het Is en Hoe Ik Het Gebruik om Betere AI-Agenten te Bouwen

Inhoudsopgave

Gepubliceerd in juli 2026.

TL;DR: Prompt engineering gaat over woordkeuze; context engineering gaat over informatiearchitectuur. Je hebt een eindig contextvenster en elk token is een afweging. Ik structureer de agentcontext in vier lagen: de systeemprompt, de gespreksgeschiedenis, opgehaalde inhoud en tool-uitvoer. De venster behandelen als een budget, niet als een leeg canvas, heeft de betrouwbaarheid meer verbeterd dan van model wisselen.

[Operatornotitie] Ik beheer meer dan 30 agenten in productie. De verbetering die het afgelopen jaar het meeste verschil heeft gemaakt, is niet een beter model of een geavanceerder framework — het is bewuster zijn over wat er in het contextvenster gaat en wat buiten blijft. Context engineering is nu de kernvaardigheid die ik zoek bij het evalueren van agentwerk.

De meeste mensen spreken nog steeds over “prompt engineering” als de kritieke vaardigheid voor het werken met AI. Prompt engineering is echt en het telt. Maar het is een deelverzameling van een grotere discipline — en het behandelen als het volledige werk verklaart waarom veel agenten die er goed uitzien in demo’s bezwijken in productie.

Waarom “prompt engineering” het verkeerde kader werd

“Prompt engineering” impliceert dat de sleutelrol de tekst is die je schrijft in de systeemprompt of het gebruikersbericht. Besteed genoeg tijd aan het opstellen van de juiste instructies, de juiste formulering, het juiste formaat, en het model doet wat je nodig hebt.

Dat klopt tot op zekere hoogte. Een goed geschreven systeemprompt is noodzakelijk. Maar het gedrag van het model wordt bepaald door alles wat zich in het contextvenster bevindt — niet alleen door je systeemprompt. Het wordt gevormd door:

• De gespreksgeschiedenis (wat er in eerdere beurten is gebeurd)
• De documenten of gegevens die je hebt opgehaald en geïnjecteerd
• De resultaten van tool-aanroepen die het model tot nu toe heeft gezien
• Het tokenaantal en de positie van elk stuk informatie

Als je alleen denkt aan de formulering van de prompt en de rest negeert van wat het contextvenster vult, optimaliseer je één invoer terwijl je de anderen onbeheerd laat. Dat is waarom “context engineering” het nauwkeurigere kader is voor serieus agentwerk.

Wat context engineering echt is

Context engineering is de discipline om te beslissen welke informatie het contextvenster van het model ingaat, in welke volgorde, op welk punt in het gesprek.

Het contextvenster is het werkgeheugen van het model. Het is eindig. Elk token dat je erin stopt, verdringt iets anders — of verhoogt de kosten. En in tegenstelling tot het menselijk werkgeheugen heeft het model geen manier om “iets op te zoeken” buiten wat er in het venster staat (tenzij je het tools geeft om dat te doen). Wat het ziet, is alles wat het heeft.

Context engineering is de praktijk om dat venster te behandelen als een resource die bewust wordt beheerd:

• Wat moet het model weten om deze stap te voltooien?
• Wat moest het in een eerdere stap weten maar heeft het niet meer nodig?
• Wat is stabiel over runs heen vs. wat is dynamisch per verzoek?
• Waar in het venster moet elk stuk informatie verschijnen?

Dit zijn geen vragen over de formulering van prompts. Dit zijn vragen over informatiearchitectuur. En de antwoorden sturen de betrouwbaarheid van de agent net zo sterk als de modelselectie.

De vier lagen die ik ontwerp

Elke agent die ik bouw heeft vier afzonderlijke contextlagen. Ik denk aan elk van hen afzonderlijk.

Laag 1: De systeemprompt

Dit is de stabiele, beurt-onafhankelijke basis. Het definieert wie de agent is, wat hij kan doen, wat hij niet kan doen en hoe hij met randgevallen moet omgaan.

De fout die de meeste mensen hier maken, is de systeemprompt één keer schrijven en als voltooid beschouwen. In de praktijk moet de systeemprompt expliciet drie vragen beantwoorden:

1. Waarvoor is deze agent? (Het model heeft een precies bereik nodig, geen vage missie.)
2. Wat moet het doen als de invoer dubbelzinnig of onvolledig is?
3. Wat mag het nooit doen? (Negatieve beperkingen tellen.)

Houd de systeemprompt minimaal. Elke onnodige zin is overhead die concurreert met de dynamische inhoud waar het echte redeneren plaatsvindt.

Een praktische tip: als je Claude met de API gebruikt, gebruik dan cache_control op je systeemprompt. Een grote, stabiele systeemprompt in de cache kost ongeveer 10% van wat een niet-gecachede zou kosten per beurt.

Laag 2: Gespreksgeschiedenis

In een meerbeurts-agent is de gespreksgeschiedenis dynamisch en groeit met elke beurt. Zonder beheer wordt het de grootste drijvende kracht achter contextinflatie.

Het probleem: vroege beurten bevatten informatie die het model niet meer nodig heeft. Alles bijhouden verspilt tokens en kan het model verwarren door hem verouderde context te geven om van te redeneren.

Wat ik doe:

• Oude beurten inkorten of samenvatten wanneer de geschiedenis een drempel overschrijdt.
• Alleen nog relevante resultaten van tool-aanroepen bewaren.
• Nooit de geschiedenis onbeperkt laten groeien in een langlopende agent.

Laag 3: Opgehaalde inhoud

Dit is de laag die middelmatige agenten scheidt van goede. De meeste agenten moeten externe gegevens ophalen tijdens uitvoering.

Twee principes die ik toepas:

Haal alleen op wat relevant is voor de huidige stap. Injecteer geen document van 50 pagina’s als de huidige stap slechts één sectie nodig heeft.

Positie telt. Informatie aan het begin en einde van de context krijgt meer gewicht dan informatie in het midden. Als er een opgehaald stuk is dat het model absoluut moet gebruiken, begraaf het dan niet in het midden van een lange injectie.

Laag 4: Tool-uitvoer

In een agentische lus roept het model tools aan en krijgt resultaten terug. Die resultaten stapelen zich op. En in tegenstelling tot de gespreksgeschiedenis denken mensen er zelden aan om ze te beheren.

De oplossing is dezelfde: nadat een tool-resultaat zijn doel heeft gediend, hoef je het niet in het venster te houden. In een meerstaps-agent draag ik een gestructureerde samenvatting van “wat we tot nu toe hebben vastgesteld” mee in plaats van de ruwe uitvoer van elke eerdere stap.

Het contextbudget: wat op te nemen en wat weg te laten

Ik gebruik een eenvoudig mentaal model: het contextvenster is een budget en elk token is een uitgave. Voor elke agentbeurt vraag ik:

• Wat moet het model nu weten om deze stap te doen?
• Wat kan ik weglaten of samenvatten zonder iets belangrijks te verliezen?
• Wat is gedupliceerd over lagen heen?

Het doel is het venster te vullen met de hoogst-signaal informatie per stap, niet volledig te zijn.

Drie context engineering-fouten die ik in productie heb gemaakt

1. Zwevende tijdstempels in het stabiele prefix. Ik zette Huidige datum: {{datum}} bovenaan mijn systeemprompt. Die string verandert elke dag, wat mijn promptcache elke 24 uur stilletjes ongeldig maakte. Verplaats vluchtige informatie — tijdstempels, gebruikers-ID’s — naar het einde van de context, na het stabiele prefix.

2. Tool-uitvoer behandelen als alleen-append. Ik voerde agentische lussen uit waarbij elk resultaat van een tool-aanroep in de context bleef. Bij beurt 8 redeneerde het model vanuit een context die voor 80% bestond uit verouderde tool-uitvoer.

3. De evaluatie overslaan bij contextwijzigingen. Contextwijzigingen zijn modelgedragswijzigingen. Ik voer nu hetzelfde evaluatieharnas uit op contextwijzigingen als op promptwijzigingen.

Mijn context engineering-workflow in de praktijk

Voordat ik een enkele regel agentcode schrijf, schets ik de contextlagen:

Systeemprompt:       ~500 tokens, stabiel, gecacht
Geschiedenisbudget:  ~2000 tokens max, samengevat na elke stap
Opgehaalde context:  ~1000-3000 tokens per stap, alleen relevante fragmenten
Uitvoerbudget:       alleen huidige stap, samengevat meegedragen

De vraag over modelselectie komt daarna. Zodra ik weet welke context engineering ik nodig heb, kies ik het goedkoopste model dat de betrouwbaarheidsdrempel handhaaft onder de juiste contextconfiguratie.

Veelgestelde vragen

Wat is het verschil tussen prompt engineering en context engineering?

Prompt engineering richt zich op de formulering van je systeemprompt en gebruikersberichten. Context engineering is de bredere discipline: beslissen welke informatie het volledige contextvenster ingaat — inclusief gespreksgeschiedenis, opgehaalde gegevens en tool-uitvoer — in welke volgorde en tegen welke tokenkosten.

Hoe groot moet mijn systeemprompt zijn?

Zo klein mogelijk terwijl hij specifiek is. Ik streef naar minder dan 800 tokens voor de meeste agenten. Een systeemprompt die elk scenario probeert te anticiperen, wordt uiteindelijk te lang om betrouwbaar door het model gelezen te worden.

Is context engineering belangrijker voor sommige modellen dan voor andere?

Het telt voor alle modellen, maar de inzetten zijn hoger met kleinere modellen. Een groot frontier-model kan zich soms herstellen van een slecht gestructureerde context; een kleiner model met een krapper budget niet.

Hoe weet ik of mijn context engineering werkt?

Volg dezelfde statistieken die je zou bijhouden voor elke betrouwbaarheidswijziging: succespercentage op je evaluatieset, kosten per succesvol resultaat en foutdistributie per stap.

Moet ik de geschiedenis altijd comprimeren of samenvatten?

Voor korte transactionele agenten: nee. Voor meerbeurts-agenten die meer dan 5-6 uitwisselingen uitvoeren: ja, altijd. De vuistregel die ik gebruik — zodra het geschiedenisbudget 30% van mijn totale contextbudget overschrijdt, begin ik samen te vatten.