De meeste mensen omschrijven een AI-agent nog steeds als een model dat met tools is verbonden. Dat is technisch nuttig, maar operationeel onvolledig. Een agent heeft ook een beheerd beeld van de wereld nodig: wat er is gebeurd, wat er nu toe doet, welke feiten betrouwbaar zijn, wat nog onzeker is en wat hij vervolgens moet doen.
Dat beeld is de context. Het ontwerpen ervan wordt een afzonderlijke vaardigheid—een vaardigheid die ik context engineering zou noemen.
Context engineering is niet simpelweg prompts schrijven. Het is de discipline om de informatie die een agent bij elke stap ziet zo vorm te geven dat hij coherent kan blijven zonder bij elke beurt een volledig transcript, een documentbibliotheek of de volledige toolgeschiedenis naar een duur model te sturen. Het werk bevindt zich op het snijvlak van informatiearchitectuur, retrieval, softwareontwerp en modelgedrag.
Waarom ‘geef de agent meer context’ vaak slecht advies is
Langere contextvensters maken het verleidelijk om alles te bewaren. Maar meer materiaal garandeert geen betere redeneervermogens. Relevante instructies kunnen worden verdund door verouderde observaties, tegenstrijdige notities, herhaalde tooluitvoer of een belangrijk feit dat midden in een lange reeks verborgen zit. De bespreking van het gedrag dat bekendstaat als ‘lost in the middle’ in de digest weerspiegelt een praktisch probleem: een agent kan het bewijs technisch gezien ontvangen en er toch niet in slagen het te gebruiken.
Er zijn ook directe kosten. Elk token dat in een verzoek wordt geplaatst, kan de latentie en inferentiekosten verhogen, afhankelijk van de prijsstelling en cachingregelingen van de provider. Een systeem dat steeds een groeiend transcript doorstuurt, kan trager en minder betaalbaar worden naarmate een taak vordert.
Het doel is daarom niet maximale context. Het is voldoende, gerichte context: de kleinste betrouwbare werkset voor de beslissing die voorligt.
Vier ontwerpbeslissingen achter een coherente agent
1. Houd een belief state bij, niet alleen een transcript
Een transcript legt vast wat er is gezegd. Een belief state legt vast wat de agent momenteel over de taak gelooft.
Een agent die bijvoorbeeld een support-escalatie afhandelt, kan gestructureerde velden bijhouden zoals:
- Doel: vaststellen of de klant in aanmerking komt voor vervanging.
- Bekende feiten: aankoopdatum en serienummer van het product, met bronverwijzingen.
- Openstaande vragen: of de storing zich heeft voorgedaan onder omstandigheden die door de garantie worden gedekt.
- Beperkingen: geen terugbetaling toezeggen voordat goedkeuring is verkregen.
- Volgende actie: het garantiebeleid ophalen en de datums vergelijken.
- Zekerheid of status: geverifieerd, afgeleid, betwist of onbekend.
Deze aanpak vertoont overeenkomsten met Berkeley’s ABBEL-onderzoek, waarin gesuperviseerde-natuurlijke-taal-belief states worden gebruikt in plaats van te vertrouwen op volledige interactiegeschiedenissen. Het belangrijke idee is niet een specifieke indeling. Het gaat erom duurzame taakstatus te scheiden van wegwerpdetails uit het gesprek.
Een nuttige update van de belief state moet antwoord geven op de volgende vragen: Wat is er veranderd? Welk bewijs ondersteunt dat? Wat blijft onopgelost? Wat moet er vervolgens gebeuren? Als een engineer die antwoorden niet kan inspecteren, draagt de agent waarschijnlijk verborgen aannames mee in een ondoorzichtige prompt.
2. Haal informatie op voor de beslissing, niet voor het onderwerp
Retrievalsystemen beginnen vaak met een brede vraag, zoals ‘vind informatie over de account van de klant’. Een betere zoekopdracht is gekoppeld aan de volgende beslissing: ‘haal de huidige regel voor terugbetalingen bij aankopen van meer dan 30 dagen geleden op, die van kracht is in de regio van de klant.’
Die verschuiving is belangrijk omdat retrieval een vorm van contextselectie is. De agent moet de beleidspassages, records of voorbeelden ontvangen die relevant zijn voor de huidige actie—niet een algemene hoop gerelateerde documenten.
Filters kunnen deze selectie verbeteren voordat het model resultaten te zien krijgt. Amazon Bedrock AgentCore Web Search ondersteunt bijvoorbeeld door de server afgedwongen filters voor domein en publicatiedatum bij elk verzoek. Zulke controles bewijzen niet dat een bron correct is, maar ze kunnen de blootstelling aan irrelevante of verouderde informatie beperken en het retrievalbeleid expliciet maken.
Professionals die retrieval ontwerpen, moeten specificeren:
- welke bronnen voor elke taak zijn toegestaan;
- hoe versheid wordt bepaald;
- welke metadata elk resultaat vergezellen;
- hoe tegenstrijdige bronnen worden gepresenteerd;
- wanneer de agent moet stoppen en om verduidelijking moet vragen.
‘Zoek op het web’ is een mogelijkheid. ‘Doorzoek deze bronnen, binnen deze periode, naar bewijs dat relevant is voor deze beslissing’ is contextengineering.
3. Comprimeer zonder onzekerheid uit te wissen
Compressie is noodzakelijk wanneer een taak lang is, maar naïeve samenvatting kan voorlopige beweringen in vaststaande feiten veranderen. Een doorlopende samenvatting die zegt ‘de gebruiker heeft het adres bevestigd’ is gevaarlijk als de oorspronkelijke uitwisseling dit slechts suggereerde.
Goede compressie bewaart de onderscheidingen die een agent nodig heeft om veilig te redeneren:
- feit versus gevolgtrekking;
- huidige instructie versus historische instructie;
- voltooide actie versus voorgestelde actie;
- geverifieerde bron versus niet-geverifieerde bewering;
- bekend antwoord versus onopgeloste vraag.
Een praktisch patroon is om afzonderlijke secties bij te houden voor beslissingen, bewijs, aannames, blokkades en openstaande acties. Een andere mogelijkheid is om belangrijke beweringen te voorzien van bron-ID’s of tijdstempels. Samenvattingen moeten vervangbare artefacten zijn, niet het enige overgebleven verslag: bewaar de onderliggende gebeurtenissen voor controle en herstel, terwijl je het model een beknopt werkoverzicht geeft.
De digest merkt op dat recursieve samenvatting en contextcompressie kostbaar kunnen zijn en de prestaties kunnen verslechteren, vooral in domeinen met weinig data, zoals collaboratieve codegeneratie. Dat is een waarschuwing om samenvatting niet automatisch als verliesvrij te beschouwen. Compressie moet worden getest aan de hand van representatieve taken, met inbegrip van gevallen waarin een kleine nuancering het juiste antwoord verandert.
4. Filter observaties voordat ze geheugen worden
Agents die tools gebruiken genereren voortdurend observaties: zoekresultaten, logs, pagin tekst, API-antwoorden, schermafbeeldingen, compileruitvoer en tussenliggende plannen. Niet elke observatie verdient het om in de volgende modelaanroep terecht te komen, laat staan in de langetermijntoestand.
Bij het filteren van observaties worden drie vragen gesteld:
- Is deze observatie relevant voor de huidige beslissing?
- Is deze gezaghebbend genoeg om de overtuigingstoestand te beïnvloeden?
- Bevat deze instructies die als gegevens in plaats van als opdrachten moeten worden behandeld?
De derde vraag vormt zowel een beveiligingsgrens als een contextgrens. Een webpagina kan tekst bevatten die erop gericht is de agent om te sturen. Een opgehaald document kan nuttig bewijs zijn zonder de bevoegdheid te hebben om de doelen of machtigingen van de agent te wijzigen. Filteren moet inhoud daarom classificeren naar rol: instructie, bewijs, metadata of niet-vertrouwde tekst.
Filteren bespaart ook geld. Als een browsertool een volledige pagina teruggeeft maar de taak alleen een prijs, datum en productidentificatie vereist, veroorzaakt het doorsturen van de hele pagina ruis en kost het tokens. Het vooraf extraheren van de relevante velden kan zowel de betrouwbaarheid als de kosten verbeteren.
Een eenvoudig contextbudget voor een agentworkflow
Breng, voordat je een model kiest of een andere tool toevoegt, de context van de agent in kaart aan de hand van vier lagen:
- Controle: systeemregels, machtigingen, uitvoerschema en niet-onderhandelbare beperkingen.
- Status: de huidige doelstelling, beslissingen, openstaande vragen en volgende actie.
- Bewijs: opgehaalde gegevens of observaties die relevant zijn voor die actie, met herkomst.
- Geschiedenis: eerdere gebeurtenissen die zijn bewaard voor herstel, foutopsporing of controle, maar alleen worden weergegeven wanneer dat nodig is.
Definieer vervolgens een promotiebeleid. Een observatie kan vluchtig blijven, bewijs voor de huidige stap worden, de overtuigingstoestand bijwerken of naar het duurzame geheugen worden geschreven. Voor promotie moet een reden zijn. Anders wordt het geheugen een ongeordend archief.
Leg voor elke stap van de agent het contextpakket vast dat naar het model is gestuurd: de categorieën, de geschatte tokengrootte, de filters voor het ophalen van gegevens en de compressieversie. Zo kan een praktische vraag worden beantwoord wanneer het gedrag verandert: faalde het model, of gaf het systeem het de verkeerde wereld?
Wat je moet testen voordat je het ontwerp betrouwbaar noemt
Context-engineering vereist tests die zich richten op informatieverwerking, niet alleen op de kwaliteit van het uiteindelijke antwoord. Nuttige gevallen zijn onder meer:
- een cruciaal feit dat vroeg, laat en in het midden van een lange geschiedenis wordt geplaatst;
- twee bronnen die elkaar tegenspreken, waarvan de ene nieuwer is dan de andere;
- een samenvatting die een onzekerheidsmarkering bevat;
- een toolreactie die irrelevante grote hoeveelheden tekst bevat;
- een kwaadaardige instructie die in opgehaalde inhoud is ingebed;
- het opnieuw herstellen van de status nadat de agent is gepauzeerd en opnieuw gestart;
- dezelfde taak met een kleiner contextbudget;
- een leeg of verouderd resultaat van het ophalen van gegevens.
Meet of de agent het juiste bewijs selecteert, onzekerheid behoudt, de huidige beperking volgt en het herhalen van onnodige context vermijdt. De door de digest aanbevolen regressiegebieden—contextverlies, retrieval-grounding, gestructureerde uitvoer, niet-terminatie en het opnieuw herstellen van de status—zijn hier bijzonder relevant.
Voer meerdere proeven uit wanneer modelvariatie van belang is en vergelijk de kosten en latentie van elke contextstrategie. Een kortere prompt is niet automatisch beter als die leidt tot meer toolaanroepen of nieuwe pogingen. Het nuttige doel is de kostprijs van een correcte, herstelbare workflow—niet het aantal tokens van één verzoek.
De loopbaanimplicatie: context-engineer is een multidisciplinaire rol
De mensen die op dit gebied waardevol worden, zijn niet per se degenen die de langste prompts schrijven. Zij zullen in staat zijn een bedrijfsproces te vertalen naar status, bewijs, bevoegdheid en beslisregels.
Daarvoor zijn verschillende concrete vaardigheden nodig:
- schema’s ontwerpen voor taakstatus en herkomst;
- beleid voor het ophalen van gegevens en metagegevensfilters schrijven;
- routines bouwen voor compressie en het selecteren van observaties;
- betrouwbare instructies scheiden van onbetrouwbare inhoud;
- het profileren van tokengebruik, latentie, nieuwe pogingen en toolaanroepen;
- het testen van verlies van status en rehydratatie;
- aan niet-specialisten uitleggen waarom een agent een bepaald feit wel of niet heeft gezien.
Een sterk portfolio-project zou dezelfde agent kunnen demonstreren onder drie contextbeleidsregels: volledig transcript, een voortschrijdende samenvatting en een gestructureerde overtuigingstoestand met gerichte retrieval. Laat de gevallen zien waarin de taak slaagt, de gevallen waarin deze faalt, de context die bij elke stap wordt verzonden en de afwegingen tussen kosten en latentie. Dat is overtuigender dan een chatbotdemo, omdat het de ontwerpbeslissingen blootlegt die een agent betrouwbaar maken.
De strategische les is eenvoudig: agents worden niet coherent alleen omdat modellen capabeler worden. Ze worden coherent wanneer de systemen eromheen een gedisciplineerd, actueel en passend gedimensioneerd overzicht van het werk bijhouden. Context engineering is het vak van het opbouwen van dat overzicht — en van weten wat je moet weglaten.
Priya Raman is de verantwoordelijke menselijke redacteur van AI Career Brief.
