Anthropic lancerede den 23. april 2026 hukommelse til Claude Managed Agents. Det fjerner et af de største arkitektoniske huller i at bygge AI-agenter i produktion.
Indtil nu har agenter været amnestiske. Hver session startede på bar bund, og alt, hvad agenten lærte undervejs, forsvandt, når sessionen sluttede. Det er slut nu, og i dette indlæg gennemgår vi, hvad der kom, hvordan det fungerer, og hvad det ændrer for et setup som vores.
Hvad er kommet
Indtil nu har Managed Agents været ephemeral by default. En agent kunne løse en opgave i en session, men alt, hvad den lærte undervejs, forsvandt, når sessionen sluttede. Hvis samme type opgave dukkede op dagen efter, startede agenten helt forfra.
Med den nye memory-funktion kan du knytte en eller flere memory stores til en agent-session. En memory store er en workspace-scoped samling af tekstdokumenter, som agenten automatisk læser, før den går i gang med en opgave, og skriver til, når den er færdig. Ingen særlig prompting eller skill-engineering kræves.
Funktionen er i Research Preview og kræver adgang gennem Anthropic. Beta-headeren er managed-agents-2026-04-01. Du kan læse Anthropics egen announcement eller dykke ned i den tekniske dokumentation.
Kan du heller ikke følge med i AI-nyhederne?
Hver uge kommer der nye opdateringer til platforme, modeller og værktøjer. Tilmeld dig nyhedsbrevet og få det vigtigste direkte i indbakken.
Hvordan adskiller memory stores sig fra en vektor-database?
En memory store er en filbaseret dokumentstruktur med path-adressering. Agenten læser og skriver hele dokumenter via et sæt fil-lignende værktøjer. En vektor-database er optimeret til semantisk lighed og kræver embedding-generering. Memory stores er designet til strukturerede læringer, ikke til fri-tekst søgning.
Kan memory stores deles mellem flere agenter samtidig?
Ja. En store kan tilknyttes flere sessioner samtidig, og flere agenter kan skrive til den samme store uden at overskrive hinanden takket være optimistic concurrency via SHA-256 preconditions. Adgangen kan sættes til read_only eller read_write pr. tilknytning.
Er det klar til produktion?
Funktionen er i Research Preview og kræver access-anmodning gennem Anthropic. Det er produktionsklar til pilot og prototyping, men ikke til forretningskritiske workloads uden fallback-planer. Brug betafasen til at validere use-case og observability-setup.
Hvad kan den
På overfladen er det simpelt: agenten husker. Under overfladen er der seks værktøjer, som agenten automatisk får adgang til, når en store er attached.
De seks værktøjer dækker det typiske filbehov. memory_list lister dokumenter, eventuelt filtreret på path-prefix. memory_search laver fuldtekstsøgning på tværs af dokumenter. memory_read henter et dokuments indhold. memory_write opretter eller overskriver et dokument på en sti. memory_edit laver inkrementelle ændringer. Og memory_delete fjerner et dokument.
Det er altså en fil-lignende abstraktion, ikke en vektor-database eller key-value store. Agenten tænker i dokumenter og stier, ikke i embeddings. Det er værd at bemærke for dem, der er vant til at bygge RAG-pipelines som primært memory-lag.
Funktionssættet dækker enterprise-egenskaberne, man ville forvente i et produktionsopsætning. Stores kan deles mellem flere AI-agenter. Adgang kan konfigureres pr. store som read_only eller read_write. Alle ændringer versioneres som immutable memory_versions. Der er audit log, der kan filtreres pr. session, API-nøgle og tidsrum. Et redact-endpoint rydder indhold, men bevarer audit-sporet (GDPR-relevant). Og optimistic concurrency via SHA-256 preconditions betyder, at flere agenter kan skrive til samme store uden at overskrive hinanden.
Hvordan fungerer det
Et dokument i deres store er maksimalt 100 KB (cirka 25.000 tokens). Der er max 8 stores per session. Anthropic anbefaler mange små, fokuserede dokumenter frem for få store, samme mønster som Claude Skills.
Det typiske flow er simpelt. Du opretter en memory store via API med et navn og en beskrivelse. Beskrivelsen bliver givet til agenten, så den forstår, hvad der ligger i den pågældende store. Du kan seede storen med indhold, før nogen agent kører, fx standarder, interne retningslinjer eller domæneviden.
Når du starter en session, knytter du en eller flere stores til den via resources-arrayet. Agenten læser fra stores, inden den går i gang, og skriver læringer til slut. Der er ingen manuel triggering nødvendig.
Hvad det ændrer for et setup som vores
Lad os gøre det konkret. Når man bygger AI-agenter i produktion, har der typisk været tre lag. Statiske instruktioner (prompts, skill-filer), der beskriver, hvordan agenten arbejder. Strukturerede data (databaser, CMS-tabeller), som agenten læser og skriver. Og session-state (kontekstvinduet), der er, hvad agenten kan nå at holde i hovedet netop nu.
Det fjerde lag har altid manglet: hvad agenten har lært over tid. I praksis har den viden enten skullet opdateres manuelt i skill-filer, eller bygges ovenpå i custom retrieval-infrastruktur (vektor-databaser, RAG-pipelines, egne PostgreSQL-layouts med embeddings). Memory stores lukker det hul.
Før havde en forsknings- eller enrichment-agent samme udgangspunkt hver kørsel. Havde den begået en fejl i en tidligere kørsel, eller lært noget vigtigt om et specifikt domæne, var den viden kun bevaret, hvis et menneske manuelt flyttede den ind i en prompt eller skill-fil. Efter kan samme agent have en per-kontekst store, hvor den akkumulerer observationer over tid. Næste kørsel starter med den kontekst allerede til rådighed. Fejl rettes én gang, ikke i hver ny session.
Hvad man skal være opmærksom på
Funktionen er i Research Preview. Det betyder produktionsklar til prototyping og pilot, men ikke til kritiske produktionsbelastninger uden fallback-planer. Det er heller ikke en erstatning for strukturerede databaser. Har man brug for relationel struktur, transaktioner eller forespørgsler med joins, skal data fortsat ligge i en ordentlig database. Memory stores er til det, agenten skal huske, ikke det data, virksomheden ejer.
Afhængig af volumen skal man kigge på omkostninger. Hver session, hvor agenten læser memory, koster tokens. Det kan vokse, hvis mange agenter læser store dokumenter. Endelig vælger agenten selv, hvad den skriver til memory. Det virker godt i praksis, men man bør stadig bygge review-workflows ind. API'et har endpoints til netop det formål: list versioner, inspicer indhold, redigér eller slet manuelt.
Næste skridt for os, der arbejder med agenter i produktion, er enkelt. Anmod om access, byg en pilot med én afgrænset use-case, og mål forskellen på first-pass fejlrater før og efter. Det er det mindste, mest reversible test-scenarie. Memory er et manglende lag, der nu er på plads, og for flere af vores egne agent-pipelines betyder det, at vi kan lade agenterne selv akkumulere læringer med fuld audit og mulighed for menneskelig korrektion.
Kan du heller ikke følge med nyhedsstrømmen?
Det kan vi godt forstå, for hver uge bringer +20 nyheder! Du kan gøre som 1200+ andre profesionelle og modtage nyhederne direkte i din indbakke.
Blot udfyld formularen og du er med på holdet