Context Engineering: het 2026-draaiboek voor AI-agents

Context engineering is de discipline waarbij u precies bepaalt welke tokens — systeeminstructies, tooldefinities, opgehaalde documenten, gespreksgeschiedenis — een plek verdienen in het beperkte contextvenster van een AI-agent, bij elke stap van zijn werk. Het heeft prompt engineering vervangen als dé kernvaardigheid voor productie-agents, want onderzoek uit 2025 en 2026 laat zien dat elk topmodel meetbaar slechter presteert naarmate de context groeit — ruim voordat het venster daadwerkelijk vol zit. De oplossing is geen groter venster, maar een gedisciplineerd budget.

Wat context engineering in 2026 werkelijk betekent

In september 2025 publiceerde het Applied AI-team van Anthropic Effective Context Engineering for AI Agents, en omschreef het als de natuurlijke volgende stap na prompt engineering. In plaats van de vraag "welke woorden geven het beste losse antwoord" wordt het "welke configuratie van context — systeemprompt, tooldefinities, voorbeelden, berichtgeschiedenis en runtime-data — leidt het meest waarschijnlijk tot het gedrag dat ik wil op dit punt in de lus van de agent." Die herkadering is belangrijk omdat al die onderdelen strijden om dezelfde eindige hulpbron: de aandacht van het model binnen het venster, niet alleen de ruwe grootte van dat venster. Een agent die plant, tools aanroept en reflecteert, raakt dit budget bij elke afzonderlijke beurt — precies waarom de discipline veel zwaarder weegt bij agents dan bij losse chatvragen.

Context rot: waarom een groter venster het probleem niet oploste

Modelleveranciers besteedden 2024 en 2025 aan een race naar contextvensters van 1 miljoen tokens, en het was verleidelijk te denken dat het contextprobleem daarmee met brute kracht was opgelost. De Context Rot-studie van Chroma Research, gepubliceerd in juli 2025, testte 18 topmodellen — waaronder GPT-4.1, Claude 4 en Gemini 2.5 — op eenvoudige ophaal- en reproductietaken en vond dat stuk voor stuk verslechterden naarmate de invoer langer werd. De achteruitgang verliep niet geleidelijk: modellen sloegen om bij duidelijke drempels, ruim vóór de opgegeven venstergrens. Een venster van 200K tokens kon al bij 50K tokens invoer forse nauwkeurigheidsverliezen tonen, en het plaatsen van het relevante feit op positie 5–15 van een context met 20 documenten kostte sommige modellen 30-plus procentpunten nauwkeurigheid vergeleken met vooraan of achteraan plaatsen.

Voor coding- en researchagents specifiek is dit het belangrijkste faalpatroon in productie: een agent stapelt zoekresultaten, tooluitvoer en verlaten redeneerpaden op tijdens het werk, en die opgebouwde ruis tast elke volgende stap aan — niet alleen het einantwoord. Een venster van 1 miljoen tokens betekent niet dat een agent betrouwbaar redeneert over 1 miljoen tokens; het betekent dat de drempel later komt, niet dat hij verdwijnt.

Waarom dit nu opduikt, niet vorig jaar

Twee signalen uit juli 2026 laten zien dat dit van onderzoekstaal naar een productieprobleem verschuift. ICML 2026 opende in Seoul met een ongewoon zware nadruk op agentic AI in het workshopprogramma — "agentic AI" kwam voor in minstens 60 van de 247 geaccepteerde workshopvoorstellen, een forse stijging ten opzichte van eerdere jaren. En Amazon CloudWatch lanceerde Coding Agent Insights, een monitoringproduct dat engineering-leiders specifiek laat zien hoe AI-codeeragents presteren binnen een organisatie, met telemetrie uit Claude Code, Codex en GitHub Copilot. Leveranciers bouwen geen monitoringproducten voor problemen die teams nog geen geld kosten — context rot is van academische curiositeit een begrotingspost geworden die engineering-leiders nu volgen.

De vier hendels: schrijven, selecteren, comprimeren, isoleren

Het engineeringteam van LangChain destilleerde de discipline tot vier strategieën die nu, benoemd of niet, in de meeste productie-agentframeworks opduiken:

• Schrijven: sla context buiten het actieve venster op — scratchpads, geheugenbestanden, lopende plannen — zodat het model feiten die het twee stappen geleden al vaststelde niet opnieuw hoeft af te leiden.
• Selecteren: haal de juiste informatie op het juiste moment het venster in. Hier verdienen RAG, tool-aanroepen en bestandsleeswerk hun plek — en hier wordt te gretig ophalen het probleem in plaats van de oplossing.
• Comprimeren: reduceer wat al in het venster staat tot de tokens die er nog toe doen — samenvatten van afgeronde beurten, ruwe tooluitvoer inkorten, afgeronde deeltaken schrappen.
• Isoleren: verdeel werk over aparte contextvensters — subagents of gesandboxte stappen — zodat de ruis van de ene taak nooit de context van een andere besmet.

LangGraph, het framework waar de meeste teams naar grijpen voor stateful, controleerbare agentworkflows, bouwt zijn checkpointing en state graphs precies rond deze vier bewerkingen — een groot deel van de reden waarom het in 2026 de gangbare standaard is geworden voor gereguleerd of risicovol agentwerk.

Agents die hun eigen context curateren

Het interessantste onderzoek van 2026 gaat een stap verder: in plaats van dat een engineer het contextbudget handmatig bepaalt, beheert de agent het zelf. Een paper van Stanford, SambaNova en UC Berkeley over Agentic Context Engineering (ACE) verdeelt het werk over drie rollen — een Generator die redeneertrajecten produceert, een Reflector die concrete lessen destilleert uit wat werkte en wat mislukte, en een Curator die die lessen terugvouwt in een gestructureerd, evoluerend context-"draaiboek" in plaats van één statische systeemprompt. Getest op agent- en financiële-analysebenchmarks versloegen door ACE beheerde contexten sterke baselines met 10,6% op agenttaken en 8,6% op financiële taken — zonder één enkele gradient-update. Niet het model werd slimmer; zijn context wel.

Dit sluit rechtstreeks aan op het agentgeheugen-vraagstuk: geheugen bepaalt wat een agent zich tussen sessies kan herinneren, terwijl context engineering bepaalt wat er uit dat geheugen — en al het andere — nu, meteen, het levende venster in wordt getrokken. Doet u dat tweede verkeerd, dan levert zelfs een perfect geheugensysteem nog een verrottende agent op.

Een concreet tokenbudget voor een productie-agent

Neem een realistische Nederlandse klantenservice-agent die een supportticket afhandelt. Een ruwe, eerlijke tokenberekening ziet er zo uit:

• Systeemprompt en tooldefinities: ruwweg 3.000–6.000 tokens, en deze post groeit elke keer dat er weer een tool wordt bijgeplakt — de meeste teams kijken er nooit meer naar om als hij eenmaal geschreven is.
• Opgehaalde kennis: 2.000–4.000 tokens als de retrievalpijplijn goed herrangschikt en filtert; al snel tien keer zoveel als ruwe stukken ongefilterd worden gedumpt.
• Gespreksgeschiedenis: 500–2.000 tokens per beurt, oplopend over een meerbeurts-ticket, en zelden ingekort ook nadat een deelvraag volledig is opgelost.
• Resultaten van tool-aanroepen: orderopzoekingen, CRM-records en vergelijkbare aanroepen kosten vaak 500–3.000 tokens elk — meestal de minst onderzochte en meest opgeblazen bron, omdat ruwe API-JSON rechtstreeks in de context wordt geplakt in plaats van teruggebracht tot de drie velden die ertoe doen.

Tel een bescheiden versie van elk op — 5.000 voor tools, 3.000 voor retrieval, 4.000 voor een geschiedenis van acht beurten, drie tool-aanroepen van gemiddeld 1.500 tokens — en één enkel ticket verbruikt al zo'n 16.500 tokens werkcontext. De data van Chroma laat nauwkeurigheidsverlies zien vanaf ongeveer 50.000 tokens werkelijk relevante informatie, zelfs binnen vensters van 200.000 tot 1.000.000 tokens. De praktische vuistregel: begroot de werkcontext van een agent op een fractie van de opgegeven venstergrootte, niet op het plafond, en meet het totaal opnieuw zodra er een tool of een retrievalbron bijkomt, want die kost meestal meer dan de post die u verwachtte.

Het budget telt ook commercieel, niet alleen voor nauwkeurigheid: elk token in dat ticket van 16.500 tokens wordt bij elke modelaanroep voor die beurt gefactureerd, en een slecht gecomprimeerde geschiedenis stapelt zich net zo op als hij de nauwkeurigheid aantast — een ticket dat bij beurt tien een onverkorte transcriptie meesleept, is niet alleen vatbaarder voor hallucinaties, het is ook de duurste aanroep van het hele gesprek.

Wat dit betekent voor Nederlandse mkb's die agents bouwen

Pas schrijven/selecteren/comprimeren/isoleren toe op een bedrijf van 20–50 fte dat offerte- of werkbonprocessen automatiseert met n8n of Make tegen een Nederlandse backoffice. De meest voorkomende fout is een volledige Exact Online- of AFAS-export "voor de zekerheid" in een systeemprompt plakken — dat is de snelste manier om context rot te veroorzaken op precies het veld dat ertoe doet, een klantnummer dat drie schermen diep verstopt zit. Een beter patroon:

• Selecteer nauw via een MCP-koppeling of een afgebakende RAG-opzoeking gekoppeld aan het specifieke record, in plaats van de hele export.
• Isoleer intake, opzoeken, opstellen en goedkeuring in kleine, controleerbare subagents in plaats van één agent die het hele ticket in één context meedraagt.
• Comprimeer de geschiedenis zodra een ticket is opgelost, zodat een herhaald contact drie weken later niet de ruis van vijf eerdere tickets meesleept naar het volgende antwoord.

Precies daarom bakenen wij AI-agentprojecten af rond smalle, van checkpoints voorziene contextvensters met een menselijke poort op het punt waar geld of gegevens veranderen, in plaats van één open-einde agent die een heel proces in zijn hoofd houdt. Het is ook waarom wij bouwen voor productie, niet voor demo's: een demo verdraagt een opgeblazen context omdat niemand hem stresstest met het 40e ticket van de dag; een productie-agent heeft die luxe niet.

Veelgestelde vragen