🤖 AI

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

Het artikel introduceert Scroll, een programmatisch contextbeheersysteem dat agentsessies behandelt als uitvoerbare omgevingen met een append-only eventlog en een persistente Python-kernel, waardoor LLM's dynamisch langdurige toestanden kunnen beheren via code terwijl ze een state-of-the-art prestatie leveren op long-context benchmarks.

Oorspronkelijke auteurs: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Gepubliceerd 2026-08-25

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een gesprek voor dat nooit eindigt. Je praat met een zeer slim computerprogramma, een programma dat je kan helpen bij het schrijven van code, het plannen van complexe reizen of het onderzoeken van diepgaande onderwerpen. In het begin is het gesprek gemakkelijk. Het programma onthoudt alles wat je de afgelopen paar minuten hebt gezegd. Maar naarmate het gesprek zich uitstrekt over uren of dagen, groeit de hoeveelheid informatie. Uiteindelijk wordt het te veel voor het programma om in zijn directe geheugen vast te houden. In de wereld van kunstmatige intelligentie wordt dit directe geheugen een contextvenster genoemd. Het heeft een vaste grootte, zoals een bureau dat slechts een bepaald aantal papieren kan vasthouden. Wanneer de stapel papier te hoog wordt, moet het programma er een aantal weggooien om plaats te maken voor nieuwe.

Het probleem is dat het programma niet weet welke papieren belangrijk zijn totdat het te laat is. Als je een vraag stelt over iets dat je drie dagen geleden hebt vermeld, kan het programma dat papier al lang weggegooid hebben. Traditionele oplossingen proberen dit op te lossen door de oude papieren samen te vatten in een korte notitie of door een paar feiten te selecteren om in een apart schrift bij te houden. Maar deze methoden zijn riskant. Als het programma een specifiek detail, zoals een datum of een getal, weggooit, is dat detail voor altijd verloren. Het kan niet meer worden hersteld. Voor taken die vereisen dat er terug wordt gekeken naar een lange geschiedenis om exacte feiten te vinden of om bij te houden hoe een situatie in de loop van de tijd is veranderd, kan het verliezen van zelfs een enkel detail ervoor zorgen dat het programma faalt.

Een team van onderzoekers heeft een andere manier voorgesteld om met deze groeiende conversatie om te gaan. Ze noemen hun systeem Scroll. In plaats van te proberen de volledige geschiedenis in het directe geheugen van het programma te passen, behandelen ze de geschiedenis als een aparte, permanente omgeving waar het programma kan komen wanneer het dat nodig heeft. Denk aan een uitgestrekt, georganiseerd archief dat net buiten het bureau van het programma staat. Het programma leest niet het hele archief in één keer. In plaats daarvan schrijft het een kleine instructie, zoals een zoekopdracht of een commando, om het archief in te gaan, de specifie�aling specifieke pagina te vinden die het nodig heeft, en alleen die pagina mee terug naar het bureau te brengen.

De kern van dit systeem is een permanent verslag van elke enkele interactie, een Event Log genoemd. Dit logboek is als een tape recorder die nooit stopt en elke boodschap, elk resultaat van een hulpmiddel en elke beslissing in exacte detail vastlegt. Het wordt veilig buiten het directe geheugen van het programma opgeslagen, zodat er niets verloren gaat. Naast dit logboek is er een persistente werkruimte, een soort digitale zandbak waar het programma zijn huidige gedachten en berekeningen kan bewaren. Wanneer het programma iets uit het verleden wil onthouden, vertrouwt het niet op een samenvatting. Het schrijft een stuk code om het Event Log te doorzoeken, het exacte moment te vinden waar het naar op zoek is, en die informatie in zijn werkruimte te laden.

Deze aanpak verandert de manier waarop het programma over zijn eigen geheugen nadenkt. In plaats van te raden wat het moet bewaren, beslist het programma wat het op het moment dat het nodig is moet opzoeken. Als het programma een reis plant en een voorkeur moet onthouden die de gebruiker weken geleden heeft vermeld, schrijft het een commando om te zoeken naar die specifieke voorkeur. Het laadt vervolgens de exacte woorden die de gebruiker gebruikte en gebruikt die om een beslissing te nemen. Het programma brengt alleen de noodzakelijke informatie in zijn directe gezichtsveld. De rest van de gesprekshistorie blijft veilig opgeslagen in het archief, wachtend om opgehaald te worden als het programma dat later nodig heeft.

Om te voorkomen dat het directe gezichtsveld te vol raakt, heeft het systeem een manier om oude informatie die momenteel niet wordt gebruikt, op te ruimen. Wanneer de werkruimte te vol wordt, verplaatst het systeem de oudste delen van het gesprek terug naar het archief. Echter, in tegen tegenstelling tot andere systemen die deze oude delen misschien verwijderen of samenvatten, bewaart Scroll ze precies zoals ze zijn. Het maakt een kleine kaart, een index, die het programma precies vertelt waar in het archief die oude delen zijn opgesgeslagen. Als het programma later beseft dat het een oud deel van het gesprek moet controleren, kan het deze kaart gebruiken om direct naar de juiste plek te springen en de originele tekst op te halen. Dit zorgt ervoor dat het programma altijd naar de bron kan terugkeren, zelfs als de informatie niet langer in zijn directe gezichtsveld is.

De onderzoekers testten dit systeem op verschillende moeilijke uitdagingen die ontworpen zijn om te zien hoe goed een kunstmatige intelligentie een lange conversatie kan afhandelen. In één test moest het systeem vragen beantwoorden op basis van een geschiedenis van meer dan één miljoen woorden aan conversatie. In een andere test moest het fungeren als een agent die beslissingen neemt over een lange periode, waarbij hulpmiddelen worden gebruikt om informatie te verzamelen en problemen op te lossen. De resultaten toonden aan dat deze nieuwe methode zeer effectief was. Op een test die mat hoe goed het systeem over lange geschiedenissen kon onthouden en redeneren, behaalde het een score van 94,8 procent. Op een andere test met een geschiedenis van tien miljoen woorden scoorde het 73,1 procent, wat hoger was dan elk ander eerder gepubliceerd systeem. In een test waarbij het systeem een groeiende omgeving moest beheren terwijl het complexe taken oploste, bereikte het 86,7 procent, waarmee het de beste eerdere resultaten ruim overtrof.

Het succes van dit systeem komt voort uit het vermogen om geheugen als een programmeertaak te behandelen. Door het programma toe te staan zijn eigen instructies te schrijven voor het vinden en gebruiken van informatie, maakt het systeem gebruik van het groeiende vermogen van het programma om code te schrijven. Het dwingt het programma niet om zijn geschiedenis samen te persen in een samenvatting die belangrijke details zou kunnen verliezen. In plaats daarvan geeft het het programma de instrumenten om toegang te krijgen tot de volledige, onbewerkte geschiedenis wanneer dat nodig is. De onderzoekers ontdekten dat deze methode goed werkt bij verschillende soorten krachtige programma's, wat suggereert dat het vermogen om langetermijngeheugen via code te beheren een algemene vaardigheid is die door diverse systemen geleerd kan worden.

Dit werk suggereert een verschuiving in hoe we intelligente agenten bouwen. In plaats van te proberen het directe geheugen van het programma groter of beter in het samenvatten te maken, kunnen we het toegang geven tot een permanent, doorzoekbaar verslag van zijn eigen leven. Het programma leert dit verslag te navigeren, waarbij het beslist wat het naar voren brengt en wat het achterlaat. Dit houdt het directe gezichtsveld helder en gefocust, terwijl de volledige waarheid van het verleden altijd beschikbaar blijft. De onderzoekers geloven dat deze aanpak kunstmatige intelligentie in de toekomst kan helpen bij het afhandelen van nog langere en complexere taken, waardoor het kan leren van een veel diepere geschiedenis zonder de details die er toe doen te verliezen.

Technische Samenvatting: Scroll – Programmatisch Contextbeheer voor Long-Horizon Agents

1. Probleemformulering

Taken met een lange horizon (long-horizon tasks) voor Large Language Model (LLM) agents—zoals software engineering op repository-niveau en diepgaand webonderzoek—genereren interactiegeschiedenissen die het contextvenster van een enkel model ver overstijgen. Bestaande oplossingen vertrouwen primair op contextcompressie (het inkorten, samenvatten of weggooien van verouderde segmenten) of extern geheugen (het extraheren van feiten naar een aparte opslag). Beide benaderingen zijn fundamenteel verlieslatend: ze leggen vast welke informatie behouden moet worden voordat toekomstige behoeften bekend zijn. Bijgevolg, als een samenvatting een specifiek detail niet vangt of een extractie een nuance mist, wordt die informatie onherstelbaar, zelfs als de ruwe log op de schijf aanwezig is. Deze beperking belemmert agents in het uitvoeren van exacte historische vergelijkingen of niet-triviale berekeningen over gebeurtenissen uit het verleden waarbij de vereiste informatie niet vooraf bekend is.

2. Methodologie: Het Scroll-framework

Het paper introduceert Scroll, een contextmanager die de sessiegeschiedenis niet herdefinieert als tekst om te worden geserialiseerd in prompts, maar als een uitvoerbare Sessie-omgeving (Session Environment). Deze omgeving stelt de agent in staat om programmatisch met zijn eigen geschiedenis te interageren.

Kerncomponenten

Append-Only Event Log ( $L_t$ ): Een duurzaam, grondwaarheid-record van alle interacties (gebruikersberichten, modelresponsen, tool-aanroepen, resultaten). Elk event krijgt een onveranderlijk, monotoon toenemend sequentieadres (seq). De log wordt opgeslagen in SQLite, waarbij gebruik wordt gemaakt van BM25 voor deterministische full-text search in plaats van embeddings.
Duurzame Opslag ( $P_t$ ): Ruwe payloads (bijv. volledige tool-outputs, artefacten) worden extern opgeslagen (JSON, bestandssysteem) en worden via uitgestelde handles (deferred handles) door de Event Log gerefereerd. Dit zorgt ervoor dat de log lichtgewicht blijft terwijl de volledige getrouwheid (fidelity) behouden blijft.
Persistente Python Kernel ( $V_t$ ): Een gesandboxed Python-kernel die persisteert over modeloproepen heen. Deze houdt een getypeerde namespace bij van resident variabelen (Python-objecten, DataFrames, deferred handles). Cruciaal is dat tussenliggende berekeningen en tool-resultaten in deze kernel blijven en niet in de prompt worden geserialiseerd, tenzij dit expliciet wordt gevraagd.

Programmatische Interface

Het model construeert zijn context door code te schrijven die wordt uitgevoerd binnen de persistente kernel. De interface, die wordt geëxposeerd via een capability-object ms, verdeelt contextconstructie in vier operaties:

LOCATE: ms.search(query, k, ...) vindt kandidaat Event Log-records via full-text search en gestructureerde filters, en retourneert stabiele seq-adressen.
MATERIALIZE: ms.expand(seq) herstelt exacte beurten of segmenten en laadt externe payloads als Python-objecten.
COMPUTE: Het model voert filtering, joins, aggregatie en afleiding uit met behulp van standaard Python en toegestane database-interfaces op resident variabelen.
EXPOSE: print(value) is het enige mechanisme dat de grens oversteekt naar de werkview van het model. Alleen expliciet geprojecteerde waarden komen in de volgende modelcontext terecht.

Evictie en Navigatie

Wanneer de werkview het tokenbudget nadert, gebruikt Scroll een evictieprocedure die verouderde segmenten uit de view verwijdert, maar nooit uit de Event Log.

Herstelbaarheid: Verwijderde events blijven letterlijk aanwezig in de Event Log.
Evictie-index: Om de noodzaak voor volledige log-zoekopdrachten te voorkomen, onderhoudt Scroll een gelaagde index van "headlines" (taak, staat, volgende actie) voor verwijderde segmenten. Deze index stelt de agent in staat om direct naar verwijderde regio's te navigeren met behulp van adres-ankers, waarbij oudere entries worden samengevoegd tot grovere bereiken om de $O(k \log k n)$ complexiteit te handhaven.

3. Belangrijkste Bijdragen

Het paper levert drie primaire bijdragen:

Deferred Selection Policy: In tegenstelling tot bestaande methoden die de contextmap vastleggen voordat toekomstige behoeften bekend zijn, stelt Scroll de selectie van de werkview uit naar query-tijd. Het model schrijft een programma $\pi_t$ bij elke stap om te beslissen wat te herinneren, te berekenen en te exposen.
Uitvoerbaar Context-substraat: De implementatie van een persistente, gesandboxed Python-kernel gecombineerd met een append-only Event Log. Dit verschuift contextbeheer van tekstverwerking naar programmeren, waarbij de programmeervaardigheden van de LLM worden benut om de context dynamisch te doorzoeken, te transformeren en te materialiseren.
Lossless Navigatie-algoritme: Een evictiemechanisme dat de werkview begrensd houdt zonder de geschiedenis te verliezen. Verwijderde segmenten blijven intact en zijn geïndexeerd door compacte, adres-verankerde entries, waardoor de agent direct naar verwijderde regio's kan navigeren in plaats van de volledige log te doorzoeken.

4. Experimentele Resultaten

De auteurs evalueerden Scroll met behulp van Qwen3.8-Max als backbone over drie benchmarks:

LongMemEvalS (Long-term Memory Retrieval): Scroll behaalde een nauwkeurigheid van 94,8%, waarmee het concurrerend presteert met state-of-the-art systemen.
BEAM10M (10M Token Geschiedenis): Scroll behaalde 73,1%, waarmee het het beste gepubliceerde geheugensysteem met 5,1 punten versloeg. Het excelleerde met name in categorieën die exacte historische bewijsvoering vereisen, zoals kennisupdates (92,5%) en contradictie-resolutie (88,1%), waar verlieslatende samenvattingen doorgaans falen.
LOCA256K (Long-Horizon Acting): Scroll behaalde 86,7% nauwkeurigheid. In directe vergelijking met andere contextbeheerstrategieën met dezelfde backbone, demonstreerde Scroll superieure stabiliteit naarmate de context groeide, met slechts een daling van 2,6% van 128K naar 256K tokens, vergeleken met dalingen van ~21% voor samenvattings- en retrieval-agents.

Ablatie-studies bevestigden dat de lossless Event Log cruciaal is (het verwijderen ervan veroorzaakte een daling naar ~20% op BEAM10M), de persistente kernel de prestaties met 7,3 punten verbetert door in-kernel aggregatie mogelijk te maken, en de evictie-index een winst van 1,8 punt oplevert door navigatie in verspreide geschiedenissen te vergemakkelijken.

Kostenefficiëntie: Scroll exposeert slechts een klein deel van de corpus aan het model. Op BEAM10M was het mediane aantal input-tokens ~105K (ongeveer 1% van de corpus), met output-tokens die een orde van grootte kleiner zijn.

5. Betekenis en Claims

Het paper claimt dat Scroll contextbeheer fundamenteel verandert van een compressieprobleem naar een programmeeropgave. Door de sessie te behandelen als een uitvoerbare omgeving, erft de agent de verbeterende programmeervaardigheden van LLM's om zijn eigen context dynamisch te beheren.

De auteurs benadrukken dat Scroll niet dicteert welke staat behouden moet worden of hoe de retrieval-code geschreven moet worden; deze beslissingen worden overgelaten aan het model. Deze flexibiliteit maakt het systeem schaalbaar met de capaciteiten van het model. Het paper suggereert dat succesvolle trajecten van frontier-modellen kunnen worden gedestilleerd naar kleinere modellen via supervised fine-tuning, waarbij de onderliggende contextmechanismen vast blijven staan.

Het werk stelt dat voor taken met een lange horizon die exacte historische bewijsvoering of complexe berekeningen over het verleden vereisen, lossless retrieval via programmatische toegang superieur is aan vooraf berekende samenvattingen of vaste geheugenopslag, omdat het de onherstelbare informatieverlies vermijdt die inherent is aan huidige compressieparadigma's.