En kørende MCP-server er demonstreret med reel trafik og protokollogs. Den giver en AI-agent vedvarende hukommelse på tværs af sessioner, forstærker brugte minder, lader ubrugte falme eksponentielt og konsoliderer dubletter. Der er tale om et system med konkrete endpoints, kode og en gennemgang, der kan omsættes til drift.
De medfølgende logs viser minder, der styrkes ved brug, falder i vægt, når de ikke aktiveres, og smelter sammen, når samme faktum gemmes flere gange. Sjældent ser man hele kredsløbet dokumenteret så tydeligt.
Fra stateless til stateful
Stateless prompt-engineering rammer en grænse i mange forretningsflows: kontekst gentages, personlig viden går tabt mellem sessioner, og man ender i dokumenthåndtering forklædt som prompts. Et memory‑lag gør agenten mere konsekvent over tid og reducerer støjen fra gentagelser.
Snilld vurderer i sin manual, at skiftet mod stateful assistenter giver reel værdi i daglige processer: færre kontekstskift, mere vedholdende præferencer og mulighed for længere forløb. Enkel mekanik, praktisk effekt.
Hvad MCP-serveren udsætter for værktøjer
Implementeringen eksponerer følgende værktøjer via MCP-protokollen:
- remember — persisterer et nyt minde eller opdaterer et eksisterende
- recall — henter relevante minder til den aktuelle opgave
- forget — markerer eller sletter et minde
- list — gennemser lagrede minder og metadata
- consolidate — deduplikerer og sammensmelter overlappende minder
- run_maintenance — kører baggrundspleje som decay og pruning
Hvert endpoint gør én ting og kan derfor testes, logges og måles isoleret.
Styring af minder i praksis
Mekanismen er samlet set tredelt. Forstærkning: når agenten bruger et minde, øges dets score. Eksponentiel decay: ubrugte minder mister vægt over tid. Konsolidering: dubletter og nært overlappende udsagn slås sammen til en renere post. Ifølge de publicerede logs stiger en præferencenote i styrke efter gentagne opslag og aftager, når den ikke nævnes. Det er ikke kun teksten, men også metadata, der ændrer sig.
Konsolidering reducerer støj i recall, så agenten ser én samlet sandhed frem for flere næsten ens varianter. Det kræver dog fornuftig normalisering, ellers går nuance tabt.
Demo‑mode og live‑mode
Walkthroughen skelner mellem to tilgange til udtræk. I demo‑mode sker udtræk regelbaseret, fx mønstre i tekst, der udløser remember‑kald. I live‑mode udleder Claude, hvad der bør gemmes. To veje til samme mål med forskellige fejlkilder.
Regelbaseret ekstraktion er deterministisk og nem at fejlrette, men overser ofte implicit viden. Claude‑baseret ekstraktion fanger mere, men kan kategorisere for bredt eller gemme midlertidige fakta som permanente. Logs viser realistiske spor af forstærkning og glemsel i begge modes, men uden kvantificeret fejlrate i live‑mode. Det bør måles.
Et kort kig i protokollen
Et lille, anonymiseret uddrag i samme form som i kilden viser mønsteret fra huskekald til forstærkning:
{"tool":"remember","timestamp":"2026-07-16T10:12:04Z","memory_id":"m_8f9...","content":"User prefers concise bullet summaries","score_before":0.32,"score_after":0.58}
{"tool":"recall","timestamp":"2026-07-16T10:13:22Z","query":"formatting preference","returned_ids":["m_8f9..."],"latency_ms":124}
{"tool":"run_maintenance","timestamp":"2026-07-17T02:00:05Z","operation":"decay","affected":[{"memory_id":"m_1a2...","score_before":0.21,"score_after":0.18}]}
{"tool":"consolidate","timestamp":"2026-07-17T02:00:08Z","merged":[{"kept":"m_8f9...","removed":"m_3c4..."}]}
Pointen er synlig: brug løfter scoren, inaktivitet sænker den, og overlappende minder samles.
Hvad logs dokumenterer
Protokollogsene viser tre ting: styrkelse, fading og merging. Minder, der bruges ved recall, løftes i score. Ubrugte minder daler eksponentielt og prunes under vedligehold. Næsten ens poster foldes sammen under consolidate. Timestamps og maintenance‑kørsler gør det muligt at følge årsag og virkning.
Begrænsningen er også klar: der er ingen publicerede benchmarks for latens eller throughput, og intet sammenligningsgrundlag på tværs af datamængder. Logs dokumenterer adfærd, ikke kapacitet.
Hvorfor det betyder noget i produktion
Med persistent hukommelse flytter ansvaret fra prompt‑tricks til drift. Det rammer performance, skalering, sikkerhed og fejlsøgning. En recall på 400 ms er fin for én bruger, men ikke for hundrede parallelle flows med stramme SLO’er. Et consolidate‑job over tusindvis af minder er billigt om natten og tungt kl. 9.15.
Skalering kræver valg af lagring. En enkel database kan række langt, men sharding melder sig hurtigt, hvis brugere eller teams skal isoleres. Konsistensmodellen betyder noget: eventual consistency kan være nok til forstærkning, mens compliance‑sletninger kræver stærkere garantier. Små arkitekturvalg bliver hurtigt store.
Sikkerhed og governance
Persistent memory rummer typisk persondata og forretningskritik. Adgangskontrol skal være eksplicit: hvem må kalde recall på hvilket domæne. Kryptering i transit er givet; kryptering i hvile bør være default med adskilt nøglestyring. Auditlogs skal vise, hvem der skrev eller læste et minde, hvornår og hvorfor.
Snilld anbefaler i sin manual et privacy‑by‑design‑greb: start med få datatyper, kort retention og klare slette‑ og rollback‑workflows. Integrer derefter med CRM og ERP via sikre API‑gateways. Uden det bliver memory‑laget en compliance‑gæld.
RBAC og audit i praksis
En enkel rollemodel kan komme langt: writer kan oprette og opdatere minder, reader kan hente dem, validator kan godkende eller kassere forslag fra live‑udtræk. Et simpelt retention‑workflow: præferencer bevares i 180 dage uden brug og slettes derefter automatisk, mens kontraktuelle noter kræver manuel review før sletning. En auditpost bør mindst indeholde operation, actor, memory_id, tidspunkt og policy‑beslutning.
Eksempel på auditlinje: {"op":"write","actor":"svc_agent:billing","memory_id":"m_9d7...","ts":"2026-07-16T11:02:31Z","policy":"allow","reason":"preference:update"}
Debugging og observabilitet
En moden MCP‑opsætning bør eksponere metrikker som:
- p95 og p99 recall‑latens samt QPS pr. tenant
- memory hit‑rate ved recall og forstærkningsfrekvens
- gennemsnitlig decay‑rate over tid og antal konsolideringshændelser
- median varighed for consolidate‑jobs og memory growth rate pr. dag
- mismatch‑rate mellem foreslåede minder i live‑mode og efterfølgende validator
Kobl dem til SLO’er: fx p95 recall under 250 ms ved 50 QPS, højst 1 procent invalid memory‑merge pr. uge og maintenance i et fast nattetidsvindue. End‑to‑end tracing er afgørende: når et svar er forkert, skal man kunne se, hvilke minder der blev recalled, hvor de kom fra, og hvorfor de blev vægtet højest.
Evaluering af memory‑nytte
Målet er ikke flest mulige minder, men om de hjælper. Pragmatisk måling: reduktion i gentaget kontekst, kortere tid til korrekt svar i gentagne opgaver og færre fejl i præferencer over tid. Det kan testes i en to‑ugers pilot og giver mere end pyntede dashboards.
Der mangler stadig standardiserede benchmarks og TCO‑tal. Et centralt, ubesvaret spørgsmål er omkostningen ved f.eks. én million recall‑kald om måneden inklusive maintenance.
Hvilke data bør gemmes
Start smalt med datatyper, der ofte giver høj værdi til lav risiko:
- Stabile præferencer, fx sprog eller formattering
- Tilbagevendende instruktioner, der normaliserer adfærd på tværs af flows
- Projekt‑ eller kundehistorik i korte, entydige påstande
Undgå at gemme hele samtaler. Gem kondenseret viden og reference til kilden. Det muliggør sletning, rollback og forklarbarhed senere.
Pilotplan for produktteams
En trinvis tilgang reducerer risiko og øger læring:
- Udvælg datatyper og fastlæg slettekriterier — skriftligt fra start
- Definer consolidation‑regler og kør run_maintenance i sandbox; tjek for nuance‑tab
- Instrumenter live‑mode med validator‑loop; mål både false positives og false negatives
- Fastlæg SLO’er for recall‑latens og maintenance‑vinduer; overvåg dem som produktkrav
- Load‑test til forventet peak, mens consolidate kører i baggrunden
Typiske faldgruber: for brede datatyper i første sprint, manglende sletteflow og for sjælden konsolidering, der mudrer hukommelsen.
Testplan for live‑mode
Når ekstraktion drives af en model, bør målingerne være eksplicitte. Kør A/B mellem rule‑based og live‑mode på samme datasæt. Sample f.eks. 10 procent af live‑forslag til manuel validering og rapportér precision/recall. Log confidence‑scores ved udtræk og undersøg korrelationen med fejl. Tryk‑test recall under samtidige skriverier og kør maintenance i et kontrolleret vindue.
Hvis der mangler tal i kilden, bør teams selv etablere et reproducerbart script, der måler end‑to‑end latens og gennemløb under stigende QPS. Det er den hurtigste vej til at afklare, om løsningen kan bære produktion.
Licens og kodeadgang
Den primære kilde viser en kørende MCP‑implementation med kodeuddrag og logs. Licens‑ og distributionsvilkår fremstår dog ikke entydigt beskrevet i materialet. Det bør præciseres af udgiveren, så teams ved, om brug og tilpasning er åbent tilladt eller kræver særskilt aftale.
Økosystemet rører på sig
Agentinfrastruktur udvikler sig hurtigt. SpaceXAI har åbnet Grok Build, et agent‑harness i Rust med værktøjslag og TUI. Det peger på et miljø, hvor memory‑servere, harnesses og protokoller kobles mere modulært. MCP passer ind som en standardiseret hukommelseskomponent i den retning.
Hvis flere bygger ovenpå MCP, kan memory blive en udskiftelig komponent med klare grænseflader — og presse leverandører til at være transparente om forstærknings‑ og decay‑logik.
Implementeringsdetaljer der gør forskellen
Følgende valg gør en stor forskel i drift:
- Tidsbaserede decay‑jobs i nattetimerne med backoff ved spidsbelastning
- Adskilt nøgletjeneste til kryptering, så rotation ikke kræver nedetid
- Idempotente remember‑kald, så retries ikke skaber dubletter
- Versionering af mindeformat, så skemaændringer ikke bryder recall
Og sørg for, at list faktisk paginerer ordentligt. Det betaler sig i drift.
Konklusion
Den kørende MCP‑server viser, at persistent hukommelse til agenter er en konkret arkitektur med værktøjer, logs og driftskonsekvenser. Forstærkning, eksponentiel glemsel og konsolidering giver et selvrensende lager, der kan holde signalet skarpt. Den store opgave ligger nu i operativ disciplin: målinger, sikkerhed og håndfaste SLO’er.
Næste skridt: vælg smalle datatyper, sæt en validator foran live‑udtræk, kør maintenance som planlagte jobs og mål memory‑nytten. Lad resten afgøres af beviserne.
Kildeliste og metode
Primær kilde: Towards AI‑artiklen “I Gave Claude a Memory That Survives Between Conversations — Here’s the MCP Server That Does It” (id 2425). Den dokumenterer endpoints remember, recall, forget, list, consolidate og run_maintenance, beskriver demo‑mode og live‑mode og indeholder logs fra reel MCP‑eksekvering, der viser forstærkning, glemsel og konsolidering.
Supplerende kontekst: Snilld‑manualen (id 2426) for vurderinger af governance, privacy‑by‑design, faseopdelt implementering og integration via sikre API‑gateways. Disse udsagn er markeret som Snillds synspunkter i artiklen.
Økosystemperspektiv: Marktechpost‑omtale af SpaceXAI Grok Build open source‑udgivelsen (id 2427) som indikation af aktivitet i agent‑harness‑ og værktøjslaget.
Verifikation: Tekniske påstande om forstærkning, eksponentiel decay og konsolidering er krydstjekket med logs og kodegennemgang i 2425. Der foreligger endnu ikke offentlige, reproducerbare benchmarks for latens, throughput eller ressourceforbrug, og det markeres som åbne spørgsmål.
