Context engineering: de vaardigheid die prompt engineering heeft vervangen

Prompt engineering als vakgebied was grotendeels een reactie op modellen die lastig te sturen waren. Je had de magische formulering nodig, het rollenspel, de dreiging met consequenties, het "denk stap voor stap".

Het meeste daarvan is voorbij. Huidige modellen volgen instructies nauwgezet en letterlijk — zó nauwgezet dat de agressieve formuleringen die vroeger nodig waren nu actief schadelijk zijn en overtriggeren en overdreven voorzichtigheid opleveren. Wat ervoor in de plaats kwam is minder glamoureus en veel belangrijker: beslissen welke informatie het model ziet, in welke volgorde, en wat je weglaat.

Dat is context engineering, en daar wordt productiekwaliteit daadwerkelijk gewonnen.

Het venster is een budget, geen bak

Grote contextvensters hebben een slecht instinct gecreëerd: als het past, stuur het mee.

Dat moet je niet doen. Om twee redenen.

Aandacht is niet gelijkmatig. Modellen letten ongelijkmatig op over een lange context. Informatie in het midden van een groot venster is meetbaar minder invloedrijk dan informatie aan het begin of einde. De prompt volproppen voegt geen signaal toe — het verdunt het.

Elke irrelevante token is een afleider. Tien passages waarvan er drie relevant zijn, is een moeilijker probleem dan drie passages die allemaal relevant zijn. Je vraagt het model om retrieval én de taak te doen, terwijl jij de retrieval had moeten doen.

Behandel het venster als een budget met echte kosten. Elke token moet zijn plek verdienen.

De anatomie van een productiecontext

Een goed opgebouwde context heeft vijf lagen, en de volgorde telt — zowel voor aandacht als voor caching.

1. System — identiteit, grenzen en formaat. Stabiel, bevroren, cachebaar. Wat de agent is, wat hij nooit mag doen, welke vorm de output heeft. Dit hoort identiek te zijn bij élk verzoek in de implementatie. Staat er een datum, een gebruikersnaam of een modusvlag in, dan heb je zowel een cachebug als een ontwerpprobleem.

2. Tools — het actie-oppervlak. Volgt direct op system. Definities moeten deterministisch geserialiseerd zijn en stabiel gedurende het gesprek. Elke tool-omschrijving zegt wanneer hij aangeroepen moet worden, niet alleen wat hij doet.

3. Opgehaalde kennis — de feiten voor deze taak. Beleidspassages, documentatie, eerdere vergelijkbare gevallen. Gefilterd op metadata, gerangschikt, gererankt en hard afgekapt. Vijf goede passages, geen twintig acceptabele.

4. State — de actuele specifics. Het echte orderrecord. De klantsegmentatie. De datum van vandaag. Voorraad. Dit is de laag die een verankerd antwoord onderscheidt van een plausibel antwoord, en het is de laag die teams het vaakst overslaan in de hoop dat het model het wel afleidt.

5. Historie — het gesprek, gesnoeid. Recente beurten volledig; oudere samengevat of verwijderd. Tool-resultaten van twintig stappen geleden zijn zelden dragend en altijd duur.

Stabiele content eerst, vluchtige content laatst. Die volgorde is wat caching laat werken, en hij komt toevallig overeen met hoe aandacht zich gedraagt.

Haal state op, beschrijf hem niet

De meest voorkomende contextfout is niet te veel informatie. Het is de verkeerde soort.

Teams schrijven uitgebreide systeemprompts die het retourbeleid in proza beschrijven, en vragen zich vervolgens af waarom de agent het inconsistent toepast. Het beleid heeft uitzonderingen, marktvarianten, categorieregels en datumgrenzen — als paragrafen uitgedrukt is het iets wat het model elke keer opnieuw moet interpreteren, en elke keer anders.

Uitgedrukt als een tool die een beslissing teruggeeft — controleer_retourrecht(order_id) → {recht: true, reden: "binnen 30-dagentermijn", methode: "originele betaalwijze"} — is het een feit. Feiten drijven niet weg.

Alles wat berekenbaar is, hoort berekend te worden. Datums, rechten, totalen, segmenten, drempels. Zet het resultaat in de context, niet de regels om het af te leiden.

Structureer hem zodat hij leesbaar is

Modellen gaan beter om met gestructureerde context dan met prozamuren. Dat is geen bijgeloof — het is dezelfde reden waarom mensen dat ook doen.

• Baken secties duidelijk af. XML-achtige tags, Markdown-koppen, consistente labels. Wat je ook kiest, wees consistent bij élk verzoek.
• Label opgehaalde passages met bron en datum. [Retourbeleid · EU · v2026.1 · geldig vanaf 15-01-2026]. Dat maakt bronvermelding mogelijk, maakt actualiteit leesbaar en laat je achteraf beweringen valideren.
• Zet de instructie tegen het eind, ná de context waarop hij van toepassing is. Het model leest het materiaal en dan de taak.
• Gebruik elke keer dezelfde structuur. Consistentie is zelf een signaal — het betekent dat het model geen energie besteedt aan het uitvogelen van de vorm van elke nieuwe prompt.

Langlopende agents beheersen

Agentische sessies stapelen op. Twintig tool-aanroepen verder bestaat het venster grotendeels uit historische tool-output die er niet meer toe doet. Drie technieken, die elkaar aanvullen in plaats van vervangen:

Snoeien. Verwijder oude tool-resultaten en verouderde redeneringen ronduit. De meeste providers ondersteunen dit inmiddels server-side. De gespreksstructuur blijft intact; het dode gewicht verdwijnt. Goedkoopste optie en de juiste standaard.

Compactie. Vat eerdere historie samen tot een compacte vorm wanneer je de venstergrens nadert. Behoudt de rode draad, ten koste van detail. Let op: geeft je provider compactie-state terug, dan moet je die weer meesturen — hem laten vallen verliest de samenvatting stilletjes.

Persistent geheugen. Een bestand dat de agent tussen sessies leest en schrijft. Dit is ondergebruikt en verrassend effectief: agents met een kladblok worden meetbaar beter in langlopend werk. Geef het structuur — één les per bestand, een samenvatting van één regel bovenaan, een expliciete instructie om het te raadplegen vóór het beginnen, en de opdracht bij te werken in plaats van te dupliceren.

Wat je weglaat

Makkelijker verkeerd te doen dan wat je toevoegt.

Instructies voor situaties die niet kunnen voorkomen. Elke voorwaarde die je toevoegt is een vertakking die het model evalueert. Handelt de agent alleen vragen na aankoop af, dan heeft hij geen richtlijnen voor het verkoopproces nodig.

Agressieve nadruk. KRITIEK:, JE MOET, ALTIJD, bij twijfel, gebruik de tool. Deze taal is geschreven om de terughoudendheid van oudere modellen te overwinnen. Huidige modellen volgen hem letterlijk, wat overtriggeren oplevert — tools aangeroepen die niet aangeroepen hadden moeten worden, escalaties die niet nodig waren, slagen om de arm bij vragen met een duidelijk antwoord. Vuurt een tool te vaak, dan is de oplossing bijna altijd de taal afzwakken, niet nog een guardrail toevoegen.

Verificatiesteigers. "Controleer je antwoord nog eens voordat je reageert." "Voeg een laatste verificatiestap toe." Recente topmodellen verifiëren hun eigen werk zonder dat je het vraagt, en het opdragen levert overbodige lussen en verspilde tokens op. Dit keert een langlopende best practice om, en precies daarom overkomt het mensen — een promptbibliotheek die "vraag om zelfcontrole" uniform toepast, heeft hier een uitzondering nodig.

Few-shot-voorbeelden die je niet meer nodig hebt. Voorbeelden waren essentieel toen modellen zwakker waren. Op huidige modellen versmallen ze vaak het gedrag — het model matcht op de voorbeelden in plaats van over het geval te redeneren. Test met de voorbeelden verwijderd; je betaalt mogelijk tokens voor een beperking die je niet wilt.

Overbodige herhaling. Dezelfde beperking in de systeemprompt, de tool-omschrijving én het gebruikersbericht zetten verdrievoudigt het gewicht niet. Het verdrievoudigt de kosten en voegt dubbelzinnigheid toe zodra de drie formuleringen uit elkaar gaan lopen.

De debug-beweging

Gedraagt een agent zich verkeerd, dan is het instinct om de prompt te bewerken. De betere eerste stap is precies kijken wat er in de context stond bij dat verzoek.

Log de volledig opgebouwde context. Niet het sjabloon — de uiteindelijke bytes. Lees het vervolgens alsof jij het model bent.

Je zult, vaker wel dan niet, aantreffen:

• De relevante passage werd helemaal niet opgehaald
• Hij werd wel opgehaald maar stond op plek negen, begraven in het midden
• Een verouderd document sprak het actuele tegen en beide waren aanwezig
• De state-laag ontbrak volledig en het model leidde af uit algemene kennis
• Twee instructies in verschillende lagen zeiden iets anders

Geen van die dingen is een promptprobleem. Ze worden allemaal gewoonlijk "opgelost" door de prompt te herschrijven, wat een wijziging oplevert die lijkt te helpen op het geval waar je naar keek en systematisch niets oplost.

De samenvatting in één regel

Prompt engineering vraagt: hoe formuleer ik dit? Context engineering vraagt: wat moet het model zien, en wat ziet het dat het niet zou moeten zien?

De tweede vraag is waar de winst zit.

---

Wij meten de context voordat we prompts bijschaven — opgebouwde logs, retrieval-scores, toewijzing per laag. Plan een auditgesprek.