Anthropic voegt een geheugenlaag toe aan Claude Managed Agents. Tot nu toe begon elke sessie met een schone lei: alles wat een agent leerde, verdween zodra de sessie eindigde. Met de nieuwe memory stores kan een agent informatie meenemen tussen sessies, leren van eerdere fouten en kennis delen met andere agents binnen dezelfde workspace. De functie is sinds kort beschikbaar in publieke beta op het Claude Platform.

Voor wie agents in productie draait is dit een belangrijke stap. Niet omdat geheugen op zich nieuw is, maar omdat de manier waarop het hier is uitgewerkt aansluit bij hoe agents werken in lange, complexe workflows. In deze post duiken we in de architectuur, de praktische werking en wat het verschil is met de bestaande memory tool.

Waarom agents geheugen nodig hebben

Een Managed Agent voert taken uit binnen een sessie. Die sessie heeft een eigen container, eigen tools en een eigen contextvenster. Zonder geheugen herhaalt elke nieuwe sessie hetzelfde werk: de codebase opnieuw verkennen, dezelfde conventies leren, dezelfde fouten maken. Voor eenmalige taken is dat geen probleem. Voor agents die dagelijks dezelfde soort werk doen, zoals documentverificatie, codereviews of klantondersteuning, is het een rem op performance en kwaliteit.

Geheugen lost dit op door een agent toegang te geven tot een blijvende opslag die de sessie overleeft. Niet als een statische database, maar als een werkruimte die de agent zelf leest en bijwerkt met dezelfde tools waarmee hij ook code schrijft of bestanden bewerkt.

Hoe memory stores zijn opgebouwd

Een memory store is een verzameling tekstdocumenten die op workspace-niveau leeft. Elke memory binnen de store heeft een pad, een beetje zoals een bestand in een directory. Wanneer je een store koppelt aan een sessie, wordt die gemount als een directory binnen de container van de sessie, onder /mnt/memory/. De agent leest en schrijft erin met dezelfde filesystem-tools die hij voor de rest van zijn werk gebruikt.

De systeemprompt krijgt automatisch een korte beschrijving van elke gemounte store: het pad, de toegangsmodus, de beschrijving van de store en eventuele instructies. Zo weet de agent wat er staat en hoe hij ermee om moet gaan, zonder dat je dat handmatig in elke prompt hoeft te herhalen.

Belangrijke kenmerken

  • Versioning: elke wijziging aan een memory creëert een onveranderlijke versie. Je krijgt een audit trail en de mogelijkheid om naar een eerder punt terug te keren.
  • Granulaire toegang: stores kunnen read-only of read-write worden gekoppeld. Voor gedeelde referentiemateriaal is read-only de veilige standaard.
  • Meerdere stores per sessie: tot acht stores tegelijk, handig om verschillende eigenaars of levenscycli te scheiden.
  • Programmatische controle: stores zijn volledig beheerbaar via de API, dus je kunt ze seeden, exporteren, bewerken of archiveren zonder dat een agent erbij hoeft te komen.
  • Limieten: individuele memories zijn gelimiteerd tot 100 kB, een store tot 100 MB. Versies worden minimaal 30 dagen bewaard.

De aanbeveling is om memory te structureren als veel kleine, gefocuste bestanden in plaats van een paar grote. Dat past beter bij hoe Claude content selecteert en verwerkt: de agent haalt enkel op wat hij nodig heeft voor de huidige taak.

De architectuur achter Managed Agents

Om te begrijpen waarom deze geheugenoplossing werkt zoals ze werkt, helpt het om de bredere architectuur van Managed Agents te kennen. Anthropic koos hier voor een ontwerp dat het “brain” scheidt van de “hands” en de “session”. Drie aparte interfaces die los van elkaar kunnen falen of vervangen worden.

  • De session is een append-only log van alles wat er gebeurt. Hij staat los van het contextvenster van Claude en kan via getEvents worden bevraagd.
  • De harness is de loop die Claude aanroept en zijn tool calls naar de juiste plek stuurt. Hij leeft buiten de container.
  • De sandbox is de uitvoeringsomgeving waar Claude code draait en bestanden bewerkt. Hij wordt aangesproken via een generieke interface: execute(name, input) → string.

Deze ontkoppeling lost een aantal problemen op die ontstonden toen alles in één container leefde. Als die container faalde, was de sessie weg. Debuggen was moeilijk omdat dezelfde container zowel de harness als de gebruikersdata bevatte. En security was kwetsbaar: een prompt injection in dezelfde container als de credentials gaf een aanvaller direct toegang tot tokens.

Door de brain uit de container te halen, werd de container “cattle in plaats van pets”. Crasht hij, dan vangt de harness dat op als een tool-call error en kan Claude beslissen om opnieuw te proberen. De brain zelf kan ook crashen en herstarten: de sessie-log staat ergens anders en bevat alles om door te gaan waar het gebleven was.

Een mooi neveneffect: omdat containers alleen worden geprovisioneerd als ze nodig zijn, daalde de p50 time-to-first-token met ongeveer 60 procent en p95 met meer dan 90 procent. Sessies die geen sandbox nodig hebben, hoeven er ook niet op te wachten.

Verschil met de bestaande memory tool

Claude had al een memory tool, maar die werkt anders. Die tool draait client-side: jij beheert de opslag in je eigen infrastructuur, en Claude doet tool calls die jouw applicatie lokaal uitvoert. Dat geeft volledige controle, maar het betekent ook dat je zelf de hele opslaglaag moet bouwen, beveiligen en onderhouden.

Memory op Managed Agents is daarentegen een hosted oplossing. Anthropic beheert de opslag, de versionering, de audit logs en de toegang. Voor teams die snel willen schalen zonder een eigen geheugeninfrastructuur op te zetten, scheelt dat veel werk. De client-side memory tool blijft beschikbaar voor wie absolute controle wil over waar de data staat, bijvoorbeeld voor strikte compliance-vereisten.

Beide opties delen wel hetzelfde idee: geheugen als bestanden in een directory, niet als een vector database of een vaag “context object”. Dat sluit aan bij hoe Claude getraind is om met filesystems om te gaan.

Praktische patronen voor productie

Een effectief geheugenontwerp begint met het bewust kiezen wie wat mag lezen en schrijven. Een paar patronen die in productie nuttig blijken:

Gedeelde referentiemateriaal als read-only store

Standaarden, conventies en domeinkennis die voor meerdere agents relevant zijn, horen in een read-only store thuis. Je vermijdt dat een onverwachte schrijfactie de gedeelde basis vervuilt, en je kunt de store zonder zorgen aan veel sessies tegelijk koppelen.

Per-gebruiker of per-project stores

Voor persoonlijke voorkeuren of projectspecifieke kennis pas je het patroon “een store per eenheid” toe. Dezelfde agentconfiguratie kan zo voor verschillende eindgebruikers werken, terwijl elke gebruiker zijn eigen geleerde context houdt.

Bewust seeden voor lange projecten

Voor softwareprojecten die meerdere sessies overspannen, loont het om de eerste sessie te gebruiken als initializer. Die zet een progress log op, een feature checklist en eventuele opstartscripts. Volgende sessies lezen die artefacten en pikken in seconden de draad weer op, zonder de codebase opnieuw te verkennen.

Read-only voor onvertrouwde input

Een belangrijk veiligheidspunt. Als een agent input verwerkt die afkomstig kan zijn van eindgebruikers, externe websites of derde-partij tools, kan een geslaagde prompt injection de store besmetten. Latere sessies lezen die besmette content dan als vertrouwd geheugen. Voor referentiemateriaal en gedeelde lookups is read-only daarom de standaard die je wilt aanhouden.

Wat teams ermee bouwen

De eerste resultaten uit de praktijk geven een idee van waar het verschil zit. Rakuten meldt dat hun task-based long-running agents 97 procent minder first-pass errors maken doordat ze leren van eerdere sessies, met 27 procent lagere kosten en 34 procent lagere latency. Wisedocs gebruikt cross-session memory in hun documentverificatiepijplijn om terugkerende problemen te herkennen en versnelt verificatie zo met 30 procent.

Netflix laat agents context meenemen tussen sessies, inclusief inzichten die meerdere turns kostten om bloot te leggen en correcties die een mens halverwege gaf. Dat vermijdt het handmatig bijwerken van prompts en skills. Ando bouwt zijn workplace messaging platform op Managed Agents en gebruikt geheugen om te capteren hoe elke organisatie interageert, zonder zelf een geheugenlaag te moeten bouwen.

De rode draad is duidelijk: teams gebruiken geheugen vooral om feedback loops te sluiten en om verificatie te versnellen. Niet om alles te onthouden, maar om de patronen te onthouden die ertoe doen.

Audit, redactie en compliance

Productieomgevingen hebben meer nodig dan opslag alleen. Memory stores op Managed Agents brengen daarom volledige versionering mee. Elke wijziging krijgt een eigen versie-ID, gekoppeld aan de sessie waarin ze plaatsvond. Je kunt zien welke agent wat schreef, wanneer, en je kunt teruggaan naar elke eerdere staat door de inhoud van een oude versie terug te schrijven via memories.update.

Voor compliance is er ook een redact-functie. Die haalt gevoelige inhoud uit een historische versie zonder de audit trail kapot te maken. Wie, wanneer en welke handeling blijft zichtbaar, alleen de inhoud zelf wordt geschoond. Handig voor lekken, persoonsgegevens of verzoeken tot verwijdering. Een versie die nog de huidige head van een live memory is, kun je niet redacteren: je schrijft eerst een nieuwe versie en redacteert dan de oude.

Beperkingen en aandachtspunten

Geheugen is geen wondermiddel. Een paar zaken om in het achterhoofd te houden:

  • Stores kunnen alleen worden gekoppeld bij het aanmaken van een sessie. Je kunt ze niet onderweg toevoegen of verwijderen.
  • De feature zit in publieke beta. Limieten zoals 100 kB per memory en 100 MB per store zijn soms te krap voor specifieke use cases.
  • Versiehistoriek wordt minimaal 30 dagen bewaard. Wil je langer bewaren, dan exporteer je versies via de API.
  • Je hebt de managed-agents-2026-04-01 beta header nodig in API-calls. SDK’s zetten die automatisch.
  • De agent toolset moet ingeschakeld zijn bij het aanmaken van de agent, anders kan hij niet met de gemount directory werken.

Een praktisch perspectief

Het interessantste aan deze release is niet dat agents nu kunnen onthouden. Dat kon technisch gezien al langer, met de nodige eigen plumbing. Het interessante is dat de geheugenlaag is ontworpen rond hetzelfde principe als de rest van Managed Agents: ontkoppeling, generieke interfaces en een filesystem als gemeenschappelijke taal. Dat maakt het mogelijk om geheugen te combineren met andere bouwstenen zonder dat je vastzit aan één manier van werken.

Voor wie nu begint met agents in productie is de afweging simpel. Bouw je een prototype of zoek je controle over waar data fysiek staat? Dan blijft de client-side memory tool relevant. Schaal je naar meerdere agents, teams of klanten en wil je niet zelf een audit trail, versionering en toegangscontrole onderhouden? Dan is de hosted memory store van Managed Agents een directe versneller. Het echte werk zit niet in het inschakelen van geheugen, maar in het bewust kiezen wat je laat onthouden en wat je liever vergeet.