Lokal LLM-hukommelse: når agentkodning skal huske projektet

Agent-LLM’er har fået en praktisk blind vinkel: de kan skrive kode, læse projektet og kalde værktøjer, men de glemmer stadig for meget mellem sessioner. Det er ikke bare irriterende. Det er en driftsfejl forklædt som produktivitet. Når en agent ikke kan huske arkitekturvalg, lokale regler, tidligere fejl og hvorfor en løsning blev fravalgt, ender udvikleren med at være manuel cache.

Derfor er denne uges mest interessante LLM-nyhed ikke endnu en større model. Det er PMB, et nyt local-first memory-system for AI coding agents, som blev delt på Hacker News 22. juni. PMB kobler sig på agentens livscyklus via MCP, gemmer projektviden lokalt i SQLite og LanceDB, og injicerer relevante minder før agenten svarer. Den korte version: lokal LLM-hukommelse bliver en del af udviklingsmiljøet, ikke en chatfunktion man skal huske at bruge.

Hukommelse er ikke pynt, det er kontrolplan

PMB beskriver sig selv som “local-first memory for your AI coding agent”. Ifølge projektets README gemmes beslutninger, erfaringer, projektfakta og præferencer i én lokal SQLite-fil. Der bruges en lokal LanceDB-vektorindeks til søgning, og systemet kan køre uden cloud, API-nøgler eller abonnement. Det understøtter Claude Code, Cursor, Codex og andre MCP-aware agenter.

Det interessante er ikke SQLite i sig selv. Det interessante er placeringen i agentflowet. PMB forsøger at gemme læring automatisk efter en tur og hente relevant kontekst før næste svar. På Hacker News forklarede udvikleren, at læsning kombinerer BM25, embeddings og en graf over entiteter med reciprocal rank fusion. Målet er ikke bare den semantisk nærmeste tekstbid, men den rigtige hukommelse for netop det projekt.

Det lyder nørdet, men konsekvensen er enkel: hvis agenten skal være mere end en hurtig autocomplete med terminaladgang, skal den have en stabil model af projektet. Ikke en global, magisk personlighed. En lokal, auditerbar og sletbar projektmodel. Her rammer PMB et reelt hul i dagens agentværktøjer.

Hvorfor lokal hukommelse betyder noget for danske udviklere

Der er en sikkerhedsvinkel, som er vigtigere end hypen. Mange teams bruger allerede LLM’er til kode, fejlsøgning og driftstekster, men de har ikke styr på, hvor projektkonteksten ender. Hvis agenthukommelse bliver en hosted API, bliver hukommelsen endnu en datakategori, der skal klassificeres, logges, slettes og forklares ved revision.

Lokal LLM-hukommelse ændrer ikke automatisk compliance-billedet, men den gør arkitekturvalget mere konkret. Du kan pege på en fil, en mappe, en backupstrategi og en sletteprocedure. Du kan beslutte, om hukommelsen må indeholde kundedata, incident-noter, kodeudsnit eller navne på interne systemer. Det er meget mere håndterbart end “noget ligger i en leverandørs memory layer”.

Der er også en mere jordnær produktivitetsvinkel. Hvis du arbejder på en kodebase over flere måneder, er de værdifulde ting ofte ikke i README-filen. De ligger i beslutninger som “brug ikke denne pakke, fordi den brød PDF-generering”, “denne test fejler kun på CI”, eller “denne integration må ikke kaldes synkront”. Det er præcis den type kontekst, agenten skal huske, hvis den ikke skal lave de samme dumme forslag igen og igen.

Det hænger direkte sammen med den udvikling, jeg tidligere har skrevet om i Claude Code kan nu selv reviewe, fixe og merge dine pull requests og Claude Design gør design systems til LLM-kontrolplan. Når agenter får mere handlekraft, bliver de små kontrolmekanismer vigtigere. Hukommelse er en af dem.

MCP gør hukommelse til infrastruktur

PMB bygger oven på Model Context Protocol, som efterhånden er blevet standardvejen til at koble LLM-klienter sammen med værktøjer og data. MCP gør ikke automatisk noget sikkert eller godt, men det giver et fælles integrationspunkt. Det er afgørende, fordi hukommelse ellers let bliver låst til én klient eller én leverandør.

Hvis PMB’s tilgang virker i praksis, peger den mod en mere fornuftig agentarkitektur: modellen kan skiftes, klienten kan skiftes, men projektets hukommelse kan blive liggende lokalt. Det er samme tanke som at holde kode i Git og ikke i IDE’ens cache. Værktøjet må gerne være smart, men den varige viden skal ikke forsvinde, når du skifter model eller betaler for en ny plan.

Der er stadig åbne spørgsmål. Hvor godt virker recall på store projekter? Hvor mange falske minder bliver gemt? Hvordan håndteres hemmeligheder, persondata og midlertidige debugging-noter? Og hvem rydder op, når agenten har misforstået en beslutning og gjort den til regel? Lokal hukommelse gør problemet nemmere at eje, men den fjerner det ikke.

Min vurdering

PMB er værd at holde øje med, fordi det angriber et lavpraktisk problem i agentic coding: kontinuitet. Ikke med endnu en benchmark, men med en konkret hukommelsesmekanisme, som kan inspiceres og køre lokalt. Det er sundere end at vente på, at de store LLM-leverandører løser al kontekst med større vinduer og mere opaque personalisering.

For teams er anbefalingen ikke at smide PMB direkte ind i produktionen og kalde det en strategi. Start med et ikke-følsomt repo. Log hvad der bliver gemt. Test om agenten faktisk bliver bedre, eller bare mere selvsikker. Lav en sletteprocedure. Og hold hemmeligheder ude, indtil I har bevis for, at jeres memory layer er lige så kontrolleret som resten af jeres udviklingsmiljø.

LLM-udviklingen handler ikke kun om større modeller. Den handler også om de små lokale systemer omkring modellerne. Hukommelse, værktøjsadgang, audit trail, politikker og rollback. Det er dér, agent-LLM’er enten bliver seriøs infrastruktur eller bare dyrere chatbots med shell-adgang.