Context engineering voor AI-agents: wat er echt in het context window komt

Inhoudsopgave

Gepubliceerd in augustus 2026.

TL;DR: Context engineering is de discipline om te bepalen welke tokens bij elke stap een plek verdienen in het context window van een agent — systeeminstructies, tool-definities, opgehaalde data en gespreksgeschiedenis strijden allemaal om dezelfde beperkte ruimte. Prompt engineering vraagt hoe formuleer ik dit; context engineering vraagt wat moet het model nu écht weten. Het faalmodel is meestal niet te weinig context — het is te veel: verouderde geschiedenis, irrelevante tool-schema’s en opgehaalde documenten waar niemand om vroeg, wat allemaal het signaal verwatert en de kosten opdrijft. Ik hanteer een vast budget per categorie, schrap geschiedenis vóór identiteit, en vat samen voordat ik afkap.

Operator-perspectief: De agents die het lastigst waren om te debuggen faalden niet omdat het model zwak was. Ze faalden omdat ik het context window een rommellade had laten worden: zes tool-schema’s die de taak niet nodig had, een gespreksgeschiedenis die 40 beurten was afgedwaald van het oorspronkelijke verzoek, een opgehaald document dat technisch relevant en praktisch nutteloos was. De prompt repareren hielp niet. Repareren wat vóór de prompt stond, wel.

Prompt engineering leverde je een werkende agent op. Context engineering is wat hem aan het werk houdt zodra hij echt volume, echte geschiedenis en echte randgevallen moet verwerken — en het is de vaardigheid waar ik inmiddels meer tijd in steek dan in de formulering van de prompt.

Prompt engineering en context engineering zijn niet dezelfde klus

Een prompt is één instructie. Context is alles wat het model ziet wanneer het op die instructie handelt: de systeemprompt, de tools die het kan aanroepen, wat je hebt opgehaald of opgezocht, en hoeveel eerdere conversatie of run-geschiedenis je hebt besloten mee te nemen. Prompt engineering optimaliseert de formulering van het eerste. Context engineering optimaliseert de samenstelling van alle vier.

Dit onderscheid doet ertoe in de praktijk, niet alleen in het vocabulaire. Als ik een fijn afgestelde prompt schrijf en de agent vijf irrelevante tool-schema’s en veertig beurten verouderde geschiedenis meegeef, maakt de formulering niet meer uit — het model redeneert over een context die grotendeels ruis is. Elke agent van mij die is gegaan van “werkt in de demo” naar “werkt om 3 uur ‘s nachts bij een rare input” kwam daar door te repareren wat er in het venster stond, niet door de instructies erin te herformuleren.

De vier dingen die om ruimte strijden

Bij elke beurt strijden vier categorieën om dezelfde beperkte ruimte:

1. Systeeminstructies — identiteit, regels, outputformaat. Zie de vijf lagen die ik gebruik voor systeemprompts — dit is de enige categorie die vrijwel vast zou moeten blijven, omdat prompt caching zich alleen terugbetaalt als het prefix niet verschuift.
2. Tool-definities — de schema’s voor elke tool die de agent deze beurt zou kunnen aanroepen, of hij die nu nodig heeft of niet.
3. Opgehaalde data — alles wat wordt opgehaald uit een database, een vector store of een API-aanroep: geheugen, documenten, klantgegevens.
4. Gesprek- of run-geschiedenis — wat er al is gebeurd in deze sessie of run.

Geen van deze is gratis. Elk token in elke categorie is een token dat het model moet afwegen tegen alle andere bij het bepalen wat het vervolgens moet doen, en elk token is een token waarvoor je betaalt bij elk verzoek dat geen cache hit is.

De fout is bijna altijd te veel, niet te weinig

Wanneer een agent zich misdraagt, is het instinct om meer context toe te voegen — meer instructies, meer achtergrond, meer geschiedenis “voor de zekerheid”. Naar mijn ervaring is dat vaker omgekeerd dan je zou denken.

Te veel tool-schema’s. Ik heb gezien dat een agent de verkeerde tool aanriep, niet omdat de juiste ontbrak, maar omdat die verscholen zat achter zes andere die niet nodig waren voor die taak. Stuur alleen de tools die relevant zijn voor de huidige stap, niet de volledige gereedschapskist bij elke aanroep. Een routeringslaag die beslist welke subset van tools wordt blootgesteld, is goedkoop om te bouwen en betaalt zichzelf al terug de eerste keer dat hij een verkeerde aanroep voorkomt.

Verouderde gespreksgeschiedenis. Een support-agent die 60 beurten geschiedenis meesleept van drie ongerelateerde kwesties van lang geleden “herinnert de klant” niet — hij verwatert het huidige verzoek met irrelevante ruis, en handelt af en toe naar iets dat niet meer waar is. Dit is precies het faalmodel dat episodisch geheugen met een begrensd venster zou moeten voorkomen, en het loont om te controleren of jouw venster écht begrensd is of stilletjes onbegrensd is gegroeid.

Opgehaalde documenten waar niemand om vroeg. Een semantische zoekopdracht die de top-10 “meest vergelijkbare” fragmenten teruggeeft in plaats van de top-2 relevante, begraaft het antwoord onder plausibel ogende afleiding. Meer opgehaalde context is niet meer signaal — voorbij een bepaald punt is het actief slechter, omdat het model harder moet werken om het deel te vinden dat ertoe doet.

Defensief herhaalde instructies. Ik zie dit in prompts die dezelfde regel op vier verschillende manieren herhalen omdat een eerdere versie van de agent hem één keer negeerde. Dat is een signaal dat de regel eerder in de prompt moest komen of structureel afgedwongen moest worden (een beperking in het tool-schema, een validatiestap) — geen signaal om de context met herhaling te vullen.

Het budget dat ik daadwerkelijk hanteer

Over 30+ productieagents heen stel ik een expliciet tokenbudget per categorie vast voordat ik de agent bouw, niet nadat hij zich begint te misdragen:

De volgorde in die laatste kolom is het echte beslissingskader: eerst geschiedenis, dan de breedte van het ophalen, dan de tool-scope, en systeeminstructies als laatste. Geschiedenis is het goedkoopst om te comprimeren zonder correctheid te verliezen — een samenvatting van twee zinnen van “wat er gebeurde in beurten 1-30” draagt meestal dezelfde operationele waarde als het volledige transcript. Systeeminstructies schrappen is het gevaarlijkst, omdat daar het werkelijke gedrag van de agent zit.

Vat samen voordat je afkapt

Truncatie — gewoon de oudste beurten laten vallen — is de ruwe versie hiervan. Het werkt totdat de weggevallen beurt precies het ene feit bevatte dat de agent nodig had. Het betere patroon is compactie: voordat je ruwe geschiedenis weggooit, comprimeer je die tot een korte, gestructureerde samenvatting die de beslissingen en feiten vastlegt, en houd je die samenvatting permanent bij, zelfs nadat de ruwe beurten zijn verdwenen.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 zinnen: wat is besloten, opgelost, of nog open staat
  keyFacts: Record<string, string>; // stabiele feiten die het waard zijn om letterlijk te bewaren
  turnCount: number; // hoeveel ruwe beurten deze samenvatting vervangt
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // Een goedkoop model dat samenvat is voor deze stap bijna altijd genoeg
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

Dit is hetzelfde principe als een eval-harness die elke productiefout omzet in een permanent testgeval (zie de eval-harness die ik gebruik om AI-agents te lanceren): gooi informatie niet weg, comprimeer haar tot een vorm die goedkoop is om te bewaren en toch nuttig blijft. De ruwe beurten zijn wegwerpbaar. De feiten erin meestal niet.

Ophalen: minder, relevantere resultaten verslaan meer resultaten

Dezelfde discipline geldt voor alles wat wordt opgehaald uit een vector store of database. Het is verleidelijk om royaal op te halen — top-10, top-20 — volgens de theorie dat meer context niet kan schaden. Dat kan wel. Elk irrelevant fragment is een fragment dat het model moet lezen, afwegen en verwerpen, en een grote genoeg stapel bijna-treffers kan zwaarder wegen dan het ene fragment dat de vraag daadwerkelijk beantwoordt.

Mijn standaard is beginnen met een kleine k (2-4) en die alleen verbreden als ik met echte gevallen kan aantonen dat het antwoord bij die breedte daadwerkelijk ontbreekt — niet omdat een breder net veiliger aanvoelt. Als de ophaalkwaliteit inconsistent is, ligt de oplossing meestal in een betere query of een re-ranking-stap, niet in een grotere k.

Koppel het terug aan kosten en correctheid

Context engineering is niet alleen een kwaliteitsprobleem — het is de grootste enkele hefboom op wat het kost om een agent te draaien, omdat je bij de meeste agentworkloads veel meer betaalt voor input-tokens dan voor output-tokens. Een opgeblazen context window is een opgeblazen rekening voordat het ooit een gedragsbug is. Als je de kostenrekensom voor het kiezen tussen modelniveaus nog niet hebt bekeken: het contextbudget dat je hanteert verandert die rekensom direct — een kleinere, goed afgebakende context maakt een goedkoper model haalbaar voor meer van je taken, omdat het model niet wordt gevraagd een speld te zoeken in een onnodig grote hooiberg.

Elke agent die ik draai, draait op Claude, en de beslissing over het modelniveau heeft pas zin zodra het contextbudget vaststaat — kosten vergelijken over een opgeblazen, onbegrensde context vertelt je niets over wat de taak daadwerkelijk nodig heeft.

En omdat het veranderen van wat er in het context window staat het gedrag net zo sterk verandert als het veranderen van de prompt, gaat elke contextwijziging door dezelfde poort als een promptwijziging: laat hem draaien tegen de eval-set opgebouwd uit echte productiefouten voordat je hem lanceert. Geschiedenis inkorten of de breedte van een zoekopdracht versmallen is precies het soort “vanzelfsprekend veilige” wijziging die stilletjes een randgeval laat regresseren als je niet controleert.

Het eindoordeel van de operator

Context engineering is bij elke beurt beslissen wat een plek verdient in een begrensd venster — en de standaardfout is te veel opnemen, niet te weinig. Houd systeeminstructies stabiel en als laatste om te schrappen. Beperk tool-definities tot de huidige stap. Haal smal op en verbreed alleen met bewijs. Comprimeer geschiedenis tot samenvattingen voordat je haar weggooit, en schrap eerst de oudste ruwe beurten. Verifieer daarna elke wijziging tegen je evals, want contextwijzigingen veranderen het gedrag precies zoals promptwijzigingen dat doen — het is alleen makkelijker om te doen alsof dat niet zo is.

Veelgestelde vragen

Wat is context engineering voor AI-agents?

Het is de discipline om te bepalen welke tokens — systeeminstructies, tool-definities, opgehaalde data en gespreksgeschiedenis — bij elke stap in het context window van een agent terechtkomen, in tegenstelling tot prompt engineering, dat gaat over hoe één instructie wordt geformuleerd. Het doet er het meest toe in productie, waar alle vier de categorieën bij elk verzoek om dezelfde beperkte ruimte strijden.

Is context engineering anders dan prompt engineering?

Ja. Prompt engineering optimaliseert de formulering van een instructie. Context engineering optimaliseert alles wat het model verder ziet naast die instructie — welke tools worden blootgesteld, wat is opgehaald, en hoeveel geschiedenis wordt meegenomen. Een goed geformuleerde prompt faalt nog steeds als hij omringd is door irrelevante tool-schema’s of verouderde geschiedenis.

Hoeveel gespreksgeschiedenis moet een AI-agent bewaren?

Minder dan je denkt. Een begrensd schuivend venster (10-20 recente beurten is typisch) plus een samengevatte digest van alles wat ouder is, presteert meestal beter dan een volledig ruw transcript, omdat het ruis verwijdert zonder de feiten die ertoe doen te verliezen. Comprimeer voordat je geschiedenis weggooit, kap niet gewoon af.

Betekent een groter context window dat ik minder context engineering nodig heb?

Nee — het verwijdert het harde technische plafond, maar niet het kosten- of ruisprobleem. Een groter venster maakt slordigheid goedkoper, maar elk irrelevant token verwatert nog steeds het signaal dat het model moet verwerken en kost nog steeds geld bij elk verzoek dat geen cache hit is. De discipline doet er evenzeer toe bij 200K tokens als bij 8K.

Gerelateerd: Hoe schrijf je AI-agent systeemprompts die niet falen in productie · Hoe voeg je geheugen toe aan een AI-agent · Prompt caching: verlaag je Claude-kosten zonder van model te wisselen · De eval-harness die ik gebruik om AI-agents te lanceren

Hulp nodig bij het ontwerpen van context en geheugen voor een agent? Neem contact op — ik ontwerp productie-agentsystemen voor operatorteams.