# Context is een eindige hulpbron, geen emmer

Waarom een groter contextvenster een agent niet betrouwbaarder maakt, en welke vier technieken de aandacht van een model wél efficiënt besteden.

- Bron: https://www.koenholman.nl/onderzoek/context-als-eindige-hulpbron/
- Auteur: Koen Holman
- Rubriek: Agents & pijplijnen
- Gepubliceerd: 23 augustus 2026

## In het kort

- Naarmate een contextvenster voller raakt, daalt het vermogen van het model om er informatie uit terug te halen.
- De vier technieken die tegen die daling ingaan — compactie, externe notities, subagents en just-in-time ophalen — delen één principe: identificatoren bewaren in plaats van inhoud.
- Een subagent verbruikt tienduizenden tokens en geeft er duizend tot tweeduizend terug — compressie is een van de redenen dat die opzet de hoofdcontext ontlast.

---

Contextvensters zijn de afgelopen jaren met ordes van grootte gegroeid, en de intuïtie die daarbij hoort is verleidelijk: hoe meer je erin stopt, hoe beter het model geïnformeerd is. Die intuïtie klopt niet. De hoeveelheid tekst die een model kan verwerken is de capaciteit; wat je ervan overhoudt is iets anders.

Anthropic beschrijft dit in [z'n engineeringdocumentatie](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) als een verschuiving van *prompt engineering* naar *context engineering*: niet de vraag hoe je één instructie formuleert, maar hoe je de volledige verzameling tokens samenstelt die het model bij elke stap ziet. Het onderliggende punt is dat context een eindige hulpbron is met afnemende opbrengst.

Een contextvenster is capaciteit. Wat het model ervan overhoudt is aandacht — en dat is een ander getal.

## Wat er meetbaar degradeert

Anthropic gebruikt hiervoor de term **context rot**. Dat is een framing van een empirische waarneming en geen vastgestelde wet — hou dat onderscheid vast, want het bepaalt hoe hard je erop kunt leunen. De waarneming zelf: naarmate het aantal tokens in het contextvenster toeneemt, daalt het vermogen van het model om informatie uit die context accuraat terug te halen. Niet abrupt, en niet pas bij de bovengrens — geleidelijk, over het hele bereik.

**De architectonische verklaring erachter**

De verklaring die erbij gegeven wordt is architectonisch: klassieke self-attention legt paarsgewijze relaties tussen tokens, en dat aantal groeit kwadratisch met de sequentielengte.

Daar moet ik meteen een streep bij zetten, want die twee dingen worden vaak aan elkaar geplakt terwijl ze niet hetzelfde zijn. Die kwadratische kosten verklaren waarom een langere context *duurder* wordt om te verwerken. Ze verklaren op zichzelf niet waarom het terughalen van informatie *slechter* wordt. Dat laatste hangt ook samen met de architectuur, met wat het model tijdens training aan lengtes heeft gezien, met waar in de reeks de relevante passage staat, en met hoeveel irrelevante tekst eromheen zit.

Wat je overhoudt is dus geen mechanisme maar een waarneming met meerdere kandidaat- oorzaken. Voor het ontwerp maakt dat verschil: het betekent dat je er niet vanaf komt door alleen de context korter te maken, en dat waar iets staat en hoeveel ruis eromheen zit net zo goed knoppen zijn.

> **De praktische omkering**
>
> Als aandacht het schaarse goed is en niet de opslag, dan is de vraag bij elke token niet “past dit erin?” maar “verdient dit een deel van de aandacht?” Dat is een fundamenteel andere ontwerpvraag, en hij leidt tot andere systemen.

## Vier technieken, één principe

De technieken die hiertegen worden ingezet zijn afzonderlijk bekend, maar ze zijn interessanter als je ziet wat ze delen.

### 1. Compactie

Wanneer de context tegen z'n grens loopt, wordt de geschiedenis samengevat en wordt er opnieuw begonnen met die samenvatting. De selectie is het hele vak: in Claude Code worden architecturale beslissingen, onopgeloste bugs en implementatiedetails bewaard, terwijl redundante tooluitvoer wordt weggegooid.

Het advies bij het afstellen ervan is opvallend concreet: begin met hoge *recall* — neem liever te veel mee — en werk daarna toe naar precisie. De reden is asymmetrie in de kosten. Te veel meenemen kost tokens; iets essentieels weggooien kost de taak. Te agressieve compactie verliest subtiele maar kritieke context, en dat verlies is stil: de agent weet niet wat hij niet meer heeft.

### 2. Gestructureerde notities

De agent schrijft naar een persistent bestand buiten de context — een notitiebestand — en raadpleegt dat in latere contextvensters. Daarmee overleeft kennis het leegmaken van het venster.

Het voorbeeld dat Anthropic geeft is illustratief juist omdat het triviaal lijkt: een agent die Pokémon speelt en bijhoudt dat hij de afgelopen 1.234 stappen op Route 1 aan het trainen is en dat Pikachu 8 van de beoogde 10 niveaus heeft gewonnen. Dat is geen redeneerprestatie. Het is boekhouding, en zonder die boekhouding valt coherentie over uren werk uit elkaar.

### 3. Subagents

Een gespecialiseerde agent doet een afgebakende taak in een eigen, schoon contextvenster en geeft alleen het resultaat terug. Het getal dat hierbij hoort is het interessantste van dit hele stuk: zo'n subagent kan tienduizenden tokens of meer verbruiken, en levert een gecondenseerde samenvatting op van doorgaans duizend tot tweeduizend tokens.

Dat is dus een compressieverhouding in de orde van tientallen tegen één, en die compressie is een belangrijk deel van waarom een subagentarchitectuur de hoofdcontext ontlast — naast scope-isolatie, filtering en het feit dat zulk werk parallel kan lopen. De hoofdagent betaalt de aandachtskosten van het antwoord, niet van de zoektocht. De scheiding van verantwoordelijkheden is niet organisatorisch maar economisch.

**Figuur.** Een hoofdagent stuurt een opdracht naar een subagent. Die subagent verbruikt tienduizenden tokens in een eigen, schoon contextvenster aan zoeken en lezen, en geeft daarvan duizend tot tweeduizend tokens terug als samenvatting. De hoofdagent betaalt de aandacht voor het antwoord, niet voor de zoektocht.

De dikte van de twee pijlen ís de bewering. De scheiding van verantwoordelijkheden is hier niet organisatorisch maar economisch.

### 4. Just-in-time ophalen

In plaats van alle mogelijk relevante gegevens vooraf in te laden, houdt de agent lichte identificatoren bij — bestandspaden, URL's, query's — en haalt hij de inhoud pas op als hij die nodig heeft. Het model dat hier expliciet als analogie wordt genoemd is de mens: een engineer memoriseert geen codebase, maar onthoudt waar dingen staan en kijkt op het moment zelf.

Wat daaruit voortkomt heet *progressive disclosure*: de agent ontdekt relevante context gaandeweg, door te verkennen, in plaats van hem vooraf toegediend te krijgen.

## Het gedeelde principe

Alle vier doen ze in de kern hetzelfde: **een verwijzing bewaren in plaats van de inhoud**. Een samenvatting verwijst naar wat er gebeurde. Een notitiebestand verwijst naar wat er is vastgesteld. Een subagentresultaat verwijst naar werk dat elders is gedaan. Een bestandspad verwijst naar code die er nog staat.

Dat is dezelfde beweging die een besturingssysteem maakt met virtueel geheugen, en dezelfde die een database maakt met een index. Het patroon is oud; wat nieuw is, is dat de schaarse hulpbron hier aandacht heet in plaats van RAM.

## Waarom dit nu telt

**Het verband met de lengte van een taak**

Het belang hiervan hangt samen met hoe lang een taak duurt. [METR](https://arxiv.org/abs/2503.14499) meet de bekwaamheid van modellen met een metriek die daarop is gebouwd: de *50%-task-completion time horizon* — de tijd die een menselijke expert doorgaans nodig heeft voor taken die het model in de helft van de gevallen tot een goed einde brengt. Hun bevinding is dat die horizon sinds 2019 ongeveer elke zeven maanden verdubbelt, met aanwijzingen dat het tempo in 2024 versnelde.

Wat daaruit volgt is mijn eigen gevolgtrekking en staat niet in het paper. Langere taken brengen doorgaans meer stappen, meer tooluitvoer en meer tussenresultaten mee, en dat is precies wat een contextvenster vult. Voor een agentarchitectuur suggereert dat een verschuiving: naast het vermogen om iets te bedenken wordt het vermogen om relevante toestand over een langere workflow vast te houden zwaarder wegen.

## Wat hieruit volgt

> **Vanaf hier: mijn interpretatie**
>
> Alles hierboven is terug te lezen in de bronnen onderaan. Wat nu volgt staat daar niet in: het zijn de gevolgtrekkingen die ik eruit trek voor het inrichten van een repository waarin agents werken. Neem ze als voorstel, niet als bevinding.

- **Instructiebestanden zijn niet gratis.** Elk bestand dat een agent bij elke run leest, kost aandacht bij elke run. Lang en volledig is niet beter dan kort en hoogsignaal — het is meetbaar slechter.
- **Verwijs naar diepte, laad hem niet in.** Een korte index met paden erin werkt beter dan de inhoud van die paden, mits de agent de middelen heeft om ze op te halen.
- **Fan-out is een compressietechniek.** Werk opsplitsen over subagents is niet alleen parallellisme; het is de enige manier om tienduizenden tokens verkenning te doen zonder ze in het hoofdvenster te betalen.
- **Wat compactie overleeft, moet je kiezen.** Beslissingen en hun redenen horen in bestanden, niet in de conversatie. Wat alleen in de geschiedenis staat, verdwijnt bij de eerste samenvatting.

## Waar het ophoudt

**Twee voorbehouden bij dit stuk**

Eerlijkheid over de grenzen van dit stuk. De degradatie van terughaalvermogen bij langere context is een waarneming die door de leverancier van het model zelf gerapporteerd wordt in engineeringdocumentatie, niet in een peer-reviewed publicatie met een openbare replicatieset. De richting is consistent met wat andere partijen rapporteren, maar de precieze vorm van de curve — waar hij begint te knikken, en hoe sterk dat per taak verschilt — is daarmee niet vastgelegd.

En de technieken hebben zelf kosten. Compactie is verliesgevend en het verlies is niet zichtbaar. Notities helpen alleen als ze ook echt herlezen worden. Subagents kosten wachttijd en een volledige extra modelaanroep per stuk. Geen van de vier is gratis; ze verplaatsen alleen de kosten naar een plek waar je ze beter kunt dragen.

## Bronnen

1. [Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) — Anthropic · Anthropic Engineering · 2025
2. [Measuring AI Ability to Complete Long Software Tasks](https://arxiv.org/abs/2503.14499) — Kwa et al. (METR) · arXiv:2503.14499 · 2025

## Toets het op je eigen systeem

Laat je eigen systeem zijn contextgebruik nalopen langs de vier technieken uit dit stuk.

```
Je gaat het contextgebruik van dit project doorlichten. Niet de code beoordelen — alleen wat er bij elke run aan context wordt opgebouwd, en of dat efficient is.

Stap 1 — inventariseer wat er standaard wordt ingeladen. Zoek elk bestand dat jij of een andere agent bij vrijwel elke taak leest: instructiebestanden, contracten, README's, configuratie. Geef per bestand een geschatte tokenomvang en de vraag die het beantwoordt.

Stap 2 — beoordeel elk bestand op signaaldichtheid. Welk deel ervan stuurt daadwerkelijk gedrag, en welk deel is achtergrond die net zo goed opgehaald had kunnen worden op het moment dat het nodig was? Wees concreet: noem regelnummers of secties.

Stap 3 — pas de vier technieken toe en zeg per stuk of het hier wat oplevert:
  - compactie: wat moet een samenvatting van een lange sessie in dit project beslist bewaren, en wat mag weg?
  - externe notities: welke kennis gaat nu verloren zodra een contextvenster wordt geleegd, en in welk bestand hoort die thuis?
  - subagents: welk werk verbruikt hier veel tokens maar levert een kort antwoord op? Dat zijn de kandidaten.
  - just-in-time ophalen: welke ingeladen inhoud kan vervangen worden door een pad of een verwijzing?

Stap 4 — geef een concreet voorstel: welke bestanden korter, welke inhoud verplaatst, welke stap naar een subagent. Zeg erbij wat je NIET zou veranderen en waarom, en welke aanname je niet kunt controleren zonder te meten.
```