Context-engineering voor langlopende AI-agenten

Samen wijzen Arize’s analyse, de arXiv-paper over context window overflow, Redis’s productie-uitleg en Atlan’s vergelijking van harness-engineering op een praktische verschuiving in agentontwerp. Langlopende agenten worden minder beoordeeld op de grootte van het contextvenster van het model en meer op de controlelaag eromheen. Arize maakt die verschuiving concreet. Het noemt uitgebrachte agenttools en geheugen-/harnesssystemen, waaronder Pi, OpenClaw, Claude Code en Letta, als voorbeelden van context-engineering op harnessniveau, en beschrijft een interactieve simulator die laat zien hoe een venster van 200K tokens volloopt.

De publieke details in de aangehaalde bronnen zijn ongelijk verdeeld. Arize geeft concrete implementatiecijfers voor Pi, OpenClaw, Claude Code en Letta. Een onderzoekspaper over het oplossen van context window overflow in AI-agenten geeft een algemener mechanisme voor het omgaan met tool-outputs die elk praktisch venster kunnen overschrijden. Redis’s uitleg over context window overflow vat de productiesymptomen samen: harde API-fouten, stille kwaliteitsdegradatie, opstapeling van tool-output en langere latency naarmate prompts groeien. Atlan’s vergelijking van prompt-, context- en harness-engineering biedt de nuttige stackmetafoor: prompt-engineering vormt het bericht, context-engineering vormt wat het model ziet, en harness-engineering vormt de hele agentomgeving.

Het belangrijke nieuws is niet dat contextvensters te klein zijn. Bouwers weten dat al. Het nuttigere punt is dat de aangehaalde agentsystemen convergeren naar vier harnessmechanismen die werk levend houden nadat het transcript geen veilige bron van waarheid meer is.

Een oppervlakkige agent leest bestanden, roept tools aan, voegt het resultaat toe en hoopt dat het model ermee om kan gaan. Een harness-first agent blokkeert of hervormt grote inputs voordat ze het model bereiken.

Een duidelijkere manier om de eerste set limieten te lezen is:

• Pi: bestandslezingen stoppen bij 2.000 regels of 50KB, afhankelijk van wat het eerst komt. De teruggegeven content bevat een vervolghint die het model vertelt welk regelbereik is getoond en hoe het verder kan met offset en limit. OpenClaw erft dat gedrag en voegt daarna aparte limieten toe: bootstrapbestanden zijn beperkt tot 12.000 tekens per bestand en 60.000 tekens totaal. Toolresultaten krijgen nog een budget van 16.000 tekens of 30% van het contextvenster, afhankelijk van wat kleiner is.

Claude Code gebruikt een ontwerp met twee poorten. Volgens Arize controleert het vóór het openen van een bestand een byteplafond van 256KB, en telt het daarna het resultaat in tokens af tegen een budget van 25.000 tokens. Zelfs voor bestanden onder het plafond geeft het standaard 2.000 regels vanaf het begin terug, en kapt het regels langer dan 2.000 tekens af. Als het model hetzelfde bestandsbereik opnieuw leest en het bestand niet is veranderd, kan Claude Code een stub teruggeven in plaats van de volledige content te herhalen.

Dat is niet alleen optimalisatie. Het verandert de faalmodus. In plaats van één grote read de taak te laten verdringen, verandert de harness “alles lezen” in “een gecontroleerde slice lezen.” Als het model meer nodig heeft, kan het daarom vragen. Voor bouwers die agent-harnesses vanaf nul ontwerpen, is dit de eerste verdedigingslinie: laat ruwe externe data nooit standaard het transcript worden.

Het volgende patroon is om context te behandelen als een viewport, niet als opslag.

Pi en Claude Code bieden paginering via offset en limit. OpenClaw voegt op sommige plekken head/tail-truncation toe, waarbij het begin en einde behouden blijven wanneer het midden waarschijnlijk minder belangrijk is. Arize zegt dat OpenClaw voor te grote bootstrapbestanden een verdeling van 75% head / 25% tail gebruikt, en voor toolresultaten zowel head als tail kan behouden wanneer de tail belangrijk lijkt, zoals bij fouten, afsluitende JSON-accolades of samenvattingsachtige trefwoorden.

Letta gaat verder door bestanden buiten de prompt te laten leven. Geüploade bestanden worden geparsed, in chunks verdeeld en embedded in een vector store, waardoor de agent directe weergave, exact zoeken en semantisch zoeken krijgt. Wanneer een bestand in context openstaat, toont Letta een beheerde weergave waarvan de grootte meeschaalt met de modelcontext: 5.000 tekens voor 8K context, 15.000 voor 32K, 25.000 voor 128K en 40.000 voor 200K+. Het aantal gelijktijdig geopende bestanden schaalt ook, van 3 voor kleine modellen tot 15 voor zeer grote, met een LRU-beleid dat de minst recent geopende bestanden verwijdert.

Dit is hetzelfde ontwerpidee achter productie-RAG: stop niet het hele corpus in de prompt; haal het deel op dat ertoe doet. Het verschil is dat agent-harnesses dit continu moeten doen, over bestanden, tool-outputs, geheugen en tussenliggende plannen heen. Dezelfde beperking geldt voor RAG-systemen: retrieval gaat niet alleen over relevantie, maar ook over het behouden van genoeg contextbudget voor de daadwerkelijke redeneerstap.

Redis maakt een verwant punt: grotere contextvensters nemen de noodzaak van contextbeheer niet weg. Systeemprompts, opgehaalde documenten, gespreksgeschiedenis en tool-outputs concurreren allemaal om dezelfde ruimte. Zelfs voordat een harde limiet wordt bereikt, kunnen modellen degraderen wanneer relevante informatie begraven raakt in lange inputs.

Overflow is de duidelijke fout. Doelverlies is stiller. De agent heeft nog ruimte om te reageren, maar vergeet het oorspronkelijke doel, mist een beperking of begint een lokale subtaak te optimaliseren.

Daarom is compaction belangrijk. Slecht gedaan vervangt samenvatten een rommelige maar getrouwe geschiedenis door een nette maar verliesgevende versie. Goed gedaan behoudt het de taakstatus, recent werk, openstaande items en de integriteit van tool-calls.

Arize meldt dat Pi compaction activeert wanneer geschatte contexttokens het contextvenster minus reservetokens overschrijden, met een standaardreserve van 16.384 tokens. Het behoudt de meest recente ongeveer 20.000 tokens en vat oudere content samen in een synthetisch gebruikersbericht dat vóór de behouden tail wordt geplaatst. Het voorkomt ook dat tool-call/tool-result-paren worden doorgesneden.

OpenClaw voegt een agressiever geschiedenisbeleid toe. Wanneer de geschiedenis meer dan 50% van het contextvenster beslaat, splitst het berichten in tokenchunks met gelijke massa, verwijdert het de oudste chunk, vat het de verwijderde content samen via gefaseerde multi-pass summarization en repareert het tool-call/result-paren. Het voert ook een pre-compaction flush uit: een stille agentische beurt geeft de agent de kans om state naar geheugenbestanden te bewaren voordat de geschiedenis verdwijnt. Afzonderlijk snoeit het toolresultaten in het geheugen met soft-trim- en hard-clear-gedrag op een cache-TTL van 5 minuten.

Claude Code compacteert dicht bij het einde van het venster. Arize zegt dat de trigger het effectieve contextvenster minus een buffer van 13.000 tokens is, waardoor compaction rond 167K tokens plaatsvindt voor een model met 200K context. De samenvattingsprompt vraagt om gestructureerde secties over het primaire verzoek, technische concepten, bestanden en code, fouten en fixes, probleemoplossing, gebruikersberichten, openstaande taken, huidig werk en volgende stap. Na compaction kan het tot 5 recent gelezen bestanden opnieuw koppelen binnen een tokenbudget.

Het patroon is duidelijk: compaction is niet “de chat samenvatten.” Het is checkpointing. Een langlopende agent heeft het equivalent van een savebestand nodig: doel, beperkingen, beslissingen, open handles, recent bewijs en volgende actie.

Sommige outputs mogen helemaal nooit in het contextvenster worden geplaatst.

De arXiv-paper maakt dit concreet met een workflow uit de materiaalkunde. Eén tool genereert een elektronische gridstructuur voor een molecule: een 3D-matrix met afmetingen 128 × 128 × 128, in totaal 2.097.152 float32-elementen. Die output overschrijdt ruimschoots het contextvenster van veelgebruikte LLM’s. Maar de volgende tool heeft het grid als input nodig.

De voorgestelde oplossing is om grote waarden buiten de modelcontext op te slaan en korte identifiers, oftewel pointers, terug te geven. Tool-wrappers inspecteren inputs om te zien of het ruwe waarden of geheugenpaden zijn. Outputs die te groot zijn, worden in runtimegeheugen onder een pad opgeslagen, en latere tools kunnen de pointer ontvangen en intern oplossen. Het model manipuleert referenties, terwijl de harness de volledige data bewaart. In één vergelijkend experiment waarin beide methoden slaagden, gebruikte de pointergebaseerde aanpak volgens de paper ongeveer zeven keer minder tokens dan de traditionele workflow.

Dit is de zuiverste scheiding tussen redeneren en datatransport. Het model hoeft een matrix met 2 miljoen elementen niet te “zien” om die aan een andere tool door te geven. Het moet weten dat de matrix bestaat, wat die vertegenwoordigt en welke bewerking hem daarna moet consumeren.

Dezelfde logica geldt buiten wetenschappelijke arrays. Grote JSON-responses, PDFs, logs, embeddings, mediabestanden en database-exports horen vaak in opslag, niet in de prompt. Voor systemen die rond MCP-tools of custom API-connectors zijn gebouwd, moet pointer passing een ontwerpkeuze van de eerste orde zijn, geen patch na de eerste overflow.

Een contextvenster van 200K tokens voelt groot totdat een agent begint te handelen. Een systeemprompt, tooldefinities, een paar opgehaalde documenten, bestandslezingen, logs, fouttraces en samenvattingen kunnen het sneller vullen dan verwacht. Het praktische kader is niet hoe groot het venster op papier lijkt, maar hoe snel agenten het tijdens runtime uitgeven. Redis’s richtlijnen voor agentgeheugen wijzen naar extern, duurzaam geheugen voor state die over calls heen moet overleven, terwijl Atlan’s framing van context-engineering betere prompts scheidt van betere contextassemblage. Samen behandelen ze het contextvenster minder als een magazijn en meer als een beperkte working set.

De diepere les is dat een contextvenster een schaarse runtime-resource is. Het als “geheugen” behandelen is nuttig, maar alleen als de harness zich gedraagt als een besturingssysteem: alloceren, evicten, pagen, compacten, dedupliceren en persisteren. Atlan’s onderscheid tussen lagen is hier nuttig. Prompt-engineering kan een bestandslezer niet repareren die 80.000 irrelevante tokens in de volgende call dumpt. Context-engineering kan de working set verbeteren. Harness-engineering bepaalt of die working set überhaupt beschermd is.

Dit verandert ook hoe teams agenten moeten evalueren. Een demo-prompt is niet genoeg. Evaluatie over een lange horizon moet groeiende transcripts, herhaalde bestandslezingen, grote tool-outputs, mislukte tool-calls, hervattingen na compaction en taken bevatten waarbij de juiste volgende stap afhangt van een vroege beperking. Onze gids over context-engineering voor agenten behandelt de modelzijde van dat probleem; de harnesslaag is waar het operationeel wordt.

Zet eerst budgetten op elke contextbron. Bestanden, tool-outputs, opgehaalde chunks, geheugeninserts en gespreksgeschiedenis moeten elk expliciete limieten hebben. Eén globaal maximumaantal tokens is te bot.

Maak truncation vervolgens actiegericht. Als de harness content afkapt, moet het model weten welk bereik het heeft gezien en hoe het meer kan aanvragen. Stille truncation is erger dan afwijzing, omdat die zelfverzekerd werk creëert op basis van ontbrekende data.

Compacteer ten derde rond state, niet rond proza. Samenvattingen moeten het doel van de gebruiker, beperkingen, beslissingen, openstaande taken, aangeraakte bestanden, relevante toolresultaten en de onmiddellijke volgende stap behouden. Tool-call-paren moeten intact blijven.

Verplaats grote waarden ten vierde uit de prompt. Sla ze op, geef ze namen en geef pointers door tools heen door. Dit is vooral belangrijk voor agenten die API’s aanroepen, documenten verwerken of multi-agent-systemen coördineren.

Test tot slot doelverlies los van overflow. Een agent kan onder het harde venster blijven en toch afdwalen. De juiste vraag is niet alleen “heeft de API de prompt geaccepteerd?” Het is “dient de volgende actie nog steeds de oorspronkelijke taak?”

De samenvatting hieronder zet die patronen om in een snelle checklist vóór de FAQ.

• Langlopende agenten falen door zowel context-overflow als doelverlies, dus de harness moet meer beheren dan promptlengte.
• Productie-agentsystemen gebruiken harde budgetten voor bestanden, tool-outputs en geschiedenis voordat ruwe data het model bereikt.
• Paginering, zoeken en beheerde weergaven behandelen context als een beperkte viewport in plaats van permanente opslag.
• Compaction werkt het best als checkpointing: het behoudt doelen, beperkingen, beslissingen, openstaand werk en de integriteit van tool-calls.
• Grote tool-outputs horen vaak in externe opslag met korte pointers die tussen tools worden doorgegeven, in plaats van volledige waarden in de prompt.

Deze sectie beantwoordt de praktische vragen achter context-engineering voor langlopende agenten: wat er overstroomt, hoe doelen verloren gaan en welke harnesspatronen werk op koers houden.

Context-overflow ontstaat wanneer de opgebouwde prompt, geschiedenis, opgehaalde data, bestanden en tool-outputs van een agent het bruikbare contextvenster van het model overschrijden of de kwaliteit aantasten voordat de harde limiet is bereikt.

Doelverlies ontstaat wanneer de oorspronkelijke taak nog ergens in het transcript aanwezig is, maar de volgende actie van de agent niet langer stuurt, vaak na lange geschiedenissen of slechte samenvatting.

Ze stellen budgetten per bron in, pagineren bestandslezingen, halen alleen relevante weergaven op, compacten geschiedenis rond state, dedupliceren herhaalde reads en slaan grote outputs buiten de prompt op.

Pointers laten het model verwijzen naar grote waarden die in runtimegeheugen zijn opgeslagen, zoals matrices, logs of PDFs, terwijl downstreamtools de volledige data oplossen zonder die in het contextvenster te plaatsen.

Nee. Grotere vensters helpen, maar systeemprompts, tooldefinities, opgehaalde documenten, logs en geschiedenis concurreren nog steeds om ruimte, en relevante informatie kan begraven raken voordat een harde limiet wordt bereikt.