Cursus
Je bent misschien een meester in prompt engineering, maar naarmate het gesprek vordert, vergeet je chatbot vaak de vroegste en belangrijkste delen van je instructies, raakt je code-assistent de draad kwijt van de projectarchitectuur en kan je RAG-tool geen verbanden leggen tussen informatie uit complexe documenten en domeinen.
Naarmate AI-use-cases complexer worden, is een slimme prompt schrijven nog maar een klein onderdeel van een veel grotere uitdaging: context engineering.
In deze tutorial leg ik uit wat context engineering is, hoe het werkt, wanneer je het gebruikt in plaats van gewone prompt engineering, en de praktische technieken die AI-systemen slimmer en contextbewuster maken.
If you’d rather follow along with a video, check out this lesson:
Wat is context engineering?
Context engineering is de praktijk van het ontwerpen van systemen die bepalen welke informatie een AI-model te zien krijgt voordat het een antwoord genereert.
Hoewel de term nieuw is, bestaan de principes achter context engineering al een hele tijd. Deze nieuwe abstractie stelt ons in staat na te denken over de meest wezenlijke en alomtegenwoordige kwestie: het ontwerpen van de informatiestroom die AI-systemen in- en uitgaat.
In plaats van perfecte prompts voor losse verzoeken te schrijven, maak je systemen die relevante details uit meerdere bronnen verzamelen en ze ordenen binnen het contextvenster van het model. Dat betekent dat je systeem gespreksgeschiedenis, gebruikersgegevens, externe documenten en beschikbare tools samenbrengt en ze zo opmaakt dat het model ermee kan werken.

Bron: 12-factor-agents
Deze aanpak vereist het beheren van verschillende informatietypen die samen de volledige context vormen:
- Systeeminstructies die gedrag en regels bepalen
- Gespreksgeschiedenis en gebruikersvoorkeuren
- Opgehaalde informatie uit documenten of databases
- Beschikbare tools en hun definities
- Gestructureerde outputformaten en schema's
- Realtime data en externe API-responsen
De grootste uitdaging is werken binnen de beperkingen van het contextvenster en toch door de tijd heen coherente gesprekken behouden. Je systeem moet beslissen wat het meest relevant is voor elk verzoek, wat meestal betekent dat je retrievalsystemen bouwt die de juiste details vinden wanneer je ze nodig hebt.
Dit houdt in dat je geheugensystemen maakt die zowel de kortetermijn-gespreksflow als langetermijn-gebruikersvoorkeuren bijhouden, plus verouderde informatie verwijderen om ruimte te maken voor de huidige behoeften.
De echte winst ontstaat wanneer verschillende soorten context samenwerken en AI-systemen creëren die intelligenter en alerter aanvoelen. Wanneer je AI-assistent eerdere gesprekken kan aanhalen, je agenda kan raadplegen en je communicatiestijl tegelijk begrijpt, voelen interacties niet langer repetitief maar juist alsof je werkt met iets dat je onthoudt.
Context engineering vs. prompt engineering
Als je ChatGPT vraagt om “een professionele e-mail te schrijven”, is dat prompt engineering — je schrijft instructies voor één taak. Maar als je een klantenservicebot bouwt die eerdere tickets moet onthouden, gebruikersgegevens moet raadplegen en gespreksgeschiedenis over meerdere interacties moet bijhouden, dan is dat context engineering.
Andrej Karpathy legt dit goed uit:
Mensen associëren prompts met korte taakbeschrijvingen die je een LLM geeft in je dagelijks gebruik. Terwijl in elke industriële LLM-app context engineering de delicate kunst en wetenschap is van het vullen van het contextvenster met precies de juiste informatie voor de volgende stap.
Andrej Karpathy
De meeste AI-toepassingen gebruiken zowel prompt engineering als context engineering. Je hebt nog steeds goed geschreven prompts nodig binnen je context engineering-systeem. Het verschil is dat die prompts nu werken met zorgvuldig beheerde achtergrondinformatie in plaats van elke keer opnieuw te beginnen.
|
Aanpak |
Beste gebruikt voor |
|
Prompt engineering |
Losse taken, contentgeneratie, outputs met specifiek format |
|
Context engineering |
Conversationele AI, documentanalysetools, code-assistenten |
|
Beide samen |
Productie-AI-toepassingen die consistente, betrouwbare prestaties nodig hebben |
Context engineering in de praktijk
Context engineering gaat van theorie naar praktijk wanneer je AI-toepassingen gaat bouwen die met complexe, onderling verbonden informatie moeten werken. Denk aan een klantenservicebot die eerdere supporttickets moet openen, accountstatus controleren en productdocumentatie raadplegen, terwijl hij een behulpzame toon in het gesprek behoudt. Dit is waar traditionele prompting tekortschiet en context engineering noodzakelijk wordt.
RAG-systemen
Context engineering is vermoedelijk begonnen met retrieval augmented generation (RAG)-systemen. RAG was een van de eerste technieken waarmee je LLM's kon introduceren aan informatie die niet deel uitmaakte van hun oorspronkelijke trainingsdata.
RAG-systemen gebruiken geavanceerde context engineering-technieken om informatie effectiever te organiseren en presenteren. Ze breken documenten op in betekenisvolle stukken, rangschikken informatie op relevantie en passen de meest bruikbare details binnen tokenlimieten.
Voor RAG moest je, als je een AI vragen wilde laten beantwoorden over interne documenten van je bedrijf, het hele model opnieuw trainen of fine-tunen. RAG veranderde dit door systemen te bouwen die je documenten konden doorzoeken, relevante fragmenten vonden en die samen met je vraag in het contextvenster opnamen.
Daardoor konden LLM's ineens meerdere documenten en bronnen analyseren om complexe vragen te beantwoorden die normaal een mens hundreds of pagina's zouden laten doorlezen.
AI-agents
RAG-systemen openden de deur naar externe informatie, maar AI-agents gingen een stap verder door context dynamisch en responsief te maken. In plaats van alleen statische documenten op te halen, gebruiken agents tijdens gesprekken externe tools.
De AI beslist welke tool het huidige probleem het beste oplost. Een agent kan een gesprek starten, beseffen dat hij actuele beursdata nodig heeft, een financiële API aanroepen en vervolgens met die verse informatie het gesprek voortzetten.
De dalende kosten van LLM-tokens maakten ook multi-agentsystemen mogelijk. In plaats van alles in het contextvenster van één model te proppen, kun je gespecialiseerde agents hebben die verschillende aspecten van een probleem afhandelen en informatie tussen hen delen via protocollen zoals A2A of MCP.
Wil je meer leren over AI-agents, bekijk dan deze cheat sheet over AI-agents.
AI-codeassistenten
AI-codeassistenten — zoals Cursor of Windsurf — behoren tot de meest geavanceerde toepassingen van context engineering, omdat ze zowel RAG- als agentprincipes combineren terwijl ze werken met sterk gestructureerde, onderling verbonden informatie.
Deze systemen moeten niet alleen individuele bestanden begrijpen, maar hele projectarchitecturen, afhankelijkheden tussen modules en codeerpatronen in je codebase.
Als je een codeassistent vraagt om een functie te refactoren, heeft die context nodig over waar die functie wordt gebruikt, welke datatypes worden verwacht en hoe wijzigingen andere delen van je project kunnen beïnvloeden.
Context engineering is hier cruciaal omdat code relaties heeft die meerdere bestanden en zelfs meerdere repositories overspannen. Een goede codeassistent bewaart context over je projectstructuur, recente wijzigingen die je hebt aangebracht, je codeerstijl en de frameworks die je gebruikt.
Daarom werken tools zoals Cursor beter naarmate je ze langer binnen een project gebruikt. Ze bouwen context op over jouw specifieke codebase en kunnen relevantere suggesties doen op basis van je patronen en voorkeuren.
Contextfouten en technieken om ze te beperken
Terwijl je dit artikel leest, denk je misschien dat context engineering onnodig is of zal worden in de nabije toekomst, aangezien contextvensters van de meest geavanceerde modellen blijven groeien. Dat is een logische aanname, want als de context maar groot genoeg is, zou je alles in een prompt kunnen gooien (tools, documenten, instructies en meer) en het model de rest laten doen.
Toch laat dit uitstekende artikel van Drew Breunig vier verrassende manieren zien waarop de context ontspoort, zelfs wanneer het model in kwestie contextvensters van 1 miljoen tokens ondersteunt. In deze sectie beschrijf ik kort de problemen die Drew Breunig toelicht en de context engineering-patronen die ze oplossen — ik raad sterk aan om Breunigs artikel voor meer details te lezen.
Contextvergiftiging
Contextvergiftiging treedt op wanneer een hallucinatie of fout in de context van je AI-systeem belandt en vervolgens steeds opnieuw wordt aangehaald in toekomstige reacties. Het DeepMind-team identificeerde dit probleem in hun technisch rapport over Gemini 2.5 bij het bouwen van een Pokémon-spelende agent. Wanneer de agent soms hallucineerde over de spelstatus, vergiftigde deze valse informatie de “doelen”-sectie van zijn context, waardoor de agent onzinnige strategieën ontwikkelde en lange tijd onmogelijke doelen nastreefde.
Dit probleem wordt erg groot in agent-workflows waarin informatie zich ophoopt. Zodra een vergiftigde context is ontstaan, kan het eeuwig duren om dit te herstellen, omdat het model de onjuiste informatie blijft aanhalen alsof die waar is.
Contextvalidatie en quarantaine is de beste oplossing. Je kunt verschillende soorten context in aparte threads isoleren en informatie valideren voordat die wordt toegevoegd aan het langetermijngeheugen. Contextquarantaine houdt in dat je nieuwe threads start zodra je mogelijke vergiftiging detecteert, zodat slechte informatie zich niet verspreidt naar toekomstige interacties.
Contextafleiding
Contextafleiding ontstaat wanneer je context zo groot wordt dat het model te veel focust op de opgebouwde geschiedenis in plaats van op wat het tijdens training heeft geleerd. De Gemini-agent die Pokémon speelde liet dit zien — zodra de context boven de 100.000 tokens kwam, begon de agent acties uit zijn enorme geschiedenis te herhalen in plaats van nieuwe strategieën te ontwikkelen.
Een Databricks-studie (zeer interessant; zeker het lezen waard) vond dat de nauwkeurigheid van modellen begon te dalen rond 32.000 tokens voor Llama 3.1 405b, waarbij kleinere modellen veel eerder hun limiet bereikten. Dit betekent dat modellen al fouten gaan maken lang voordat hun contextvensters daadwerkelijk vol zijn, wat doet afvragen wat de echte waarde is van zeer grote contextvensters voor complexe redeneertaken.

Bron: Databricks
De beste aanpak is contextsamenvatting. In plaats van context eindeloos te laten groeien, kun je opgehoopte informatie comprimeren tot kortere samenvattingen die belangrijke details behouden en redundante geschiedenis verwijderen. Dit helpt wanneer je het afleidingsplafond raakt — je kunt het gesprek tot nu toe samenvatten en met een schone lei verdergaan, terwijl je consistent blijft.
Contextverwarring
Contextverwarring treedt op wanneer je extra informatie in je context opneemt die het model gebruikt om slechte antwoorden te genereren, zelfs wanneer die informatie niet relevant is voor de huidige taak. De Berkeley Function-Calling Leaderboard laat dit zien — elk model presteert slechter wanneer het meer dan één tool krijgt, en modellen roepen soms tools aan die niets met de taak te maken hebben.
Het probleem wordt erger bij kleinere modellen en meer tools. Een recente studie vond dat een gequantiseerde Llama 3.1 8b faalde op de GeoEngine-benchmark wanneer het alle 46 beschikbare tools kreeg, zelfs al viel de context ruim binnen de 16k-windowlimiet. Maar toen onderzoekers hetzelfde model slechts 19 tools gaven, werkte het prima.
De oplossing is toolloadoutmanagement met RAG-technieken. Onderzoek van Tiantian Gan en Qiyao Sun liet zien dat het toepassen van RAG op toolbeschrijvingen de prestaties sterk kan verbeteren. Door toolbeschrijvingen op te slaan in een vectordatabank kun je per taak alleen de meest relevante tools selecteren. Hun studie vond dat het aantal tools onder de 30 houden driemaal betere toolselectienauwkeurigheid gaf en veel kortere prompts.
Contextconflict
Contextconflict treedt op wanneer je informatie en tools in je context verzamelt die direct in tegenspraak zijn met andere informatie die er al staat. Een studie van Microsoft en Salesforce toonde dit aan door benchmarkprompts te nemen en hun informatie te “sharden” over meerdere gespreksbeurten in plaats van alles in één keer te geven. De resultaten waren enorm — een gemiddelde prestatiedaling van 39%, waarbij het model van OpenAI’s o3 daalde van 98,1 naar 64,1.

Bron: Laban et. al, 2025
Het probleem ontstaat omdat, wanneer informatie in etappes binnenkomt, de samengestelde context vroege pogingen van het model bevat om vragen te beantwoorden voordat het alle informatie heeft. Deze onjuiste vroege antwoorden blijven in de context en beïnvloeden het model bij het genereren van definitieve antwoorden.
Context snoeien en offloaden zijn de beste oplossingen. Context snoeien betekent verouderde of conflicterende informatie verwijderen zodra er nieuwe details binnenkomen. Context offloaden, zoals Anthropic’s “think”-tool, geeft modellen een aparte werkruimte om informatie te verwerken zonder de hoofdcontext te vervuilen. Deze kladblokaanpak kan tot 54% verbetering geven in gespecialiseerde agentbenchmarks door te voorkomen dat interne tegenstrijdigheden de redenering verstoren.
Conclusie
Context engineering vertegenwoordigt de volgende fase van AI-ontwikkeling, waarin de focus verschuift van het perfectioneren van prompts naar het bouwen van systemen die de informatiestroom door de tijd heen beheren. Het vermogen om relevante context over meerdere interacties te behouden, bepaalt of je AI intelligent aanvoelt of alleen goede losse antwoorden geeft.
De technieken in deze tutorial — van RAG-systemen tot contextvalidatie en toolmanagement — worden al gebruikt in productiesystemen die miljoenen gebruikers bedienen.
Als je iets bouwt dat complexer is dan een simpele contentgenerator, heb je waarschijnlijk context engineering-technieken nodig. Het goede nieuws is dat je klein kunt beginnen met basisimplementaties van RAG en geleidelijk geavanceerder geheugen- en toolmanagement kunt toevoegen naarmate je behoeften groeien.
Wil je meer leren, dan raad ik deze bronnen aan:
- Cursor AI Code Editor-tutorial — Leer hoe context engineering in de praktijk werkt met AI-codeassistenten
- Vergelijking Cursor vs. Windsurf — Leer de verschillen tussen Cursor en Windsurf
- Beste AI-codeassistenten — Vergelijk verschillende tools en hun aanpak van contextbeheer
- Retrieval Augmented Generation (RAG) met LangChain-cursus — Praktische cursus voor het bouwen van RAG-systemen
- Wat is Retrieval Augmented Generation (RAG)? — Basisconcepten voor context engineering
- Agentic RAG-tutorial — Geavanceerde technieken voor dynamisch contextbeheer
- Wat is prompt engineering? — Begrijp het verschil tussen prompt en context engineering
- Multi-agent-systemen met LangGraph-cursus — Leer hoe je multi-agentsystemen bouwt met LangGraph
- Introduction to AI Agents-cursus — Systemen bouwen die tools gebruiken en context over tijd behouden
FAQs
Wanneer moet ik context engineering gebruiken in plaats van alleen prompts?
Begin met context engineering zodra je AI dingen moet onthouden tussen gesprekken door, met meerdere informatiebronnen moet werken of langlopende taken moet bijhouden. Als je iets bouwt dat complexer is dan een simpele contentgenerator, heb je deze technieken waarschijnlijk nodig.
Wat is het belangrijkste verschil tussen context engineering en prompt engineering?
Prompt engineering richt zich op het schrijven van instructies voor losse taken, terwijl context engineering systemen ontwerpt die de informatiestroom over meerdere interacties beheren. Context engineering bouwt geheugen- en retrievalsystemen; prompt engineering formuleert individuele verzoeken.
Kan ik grotere contextvensters gebruiken in plaats van context engineering?
Grotere contextvensters lossen de kernproblemen niet op. Onderzoek toont aan dat de modelprestatie rond 32.000 tokens daalt, zelfs met contextvensters van een miljoen tokens, door contextafleiding en -verwarring. Je hebt nog steeds technieken nodig zoals samenvatten, snoeien en slimme informatieselectie, ongeacht de contextgrootte.
Waarom presteren AI-modellen slechter als ik ze meer tools of informatie geef?
Dit heet contextverwarring — modellen raken afgeleid door irrelevante informatie en kunnen tools gebruiken die niet bij de taak passen. De oplossing is toolloadoutmanagement: gebruik RAG-technieken om alleen de meest relevante tools voor elke specifieke taak te selecteren en houd de selectie onder de 30 tools.

Ik ben een contentmaker op het gebied van data science met meer dan 2 jaar ervaring en een van de grootste achterbannen op Medium. Ik schrijf graag diepgaande artikelen over AI en ML met een vleugje sarcasme, want je moet íets doen om ze wat minder droog te maken. Ik heb meer dan 130 artikelen en een DataCamp-cursus gemaakt, met nog een in de maak. Mijn content is door meer dan 5 miljoen ogen bekeken, van wie 20k mij is gaan volgen op zowel Medium als LinkedIn.
