Hermes Agent Memory System: Så fungerar persistent AI-minne i praktiken

Du känner till konceptet. Du öppnar en chatt med en AI-agent, förklarar ditt projekt, delar dina preferenser, får lite arbete gjort och stänger fliken. Du kommer tillbaka nästa vecka och det är som att prata med en främling — all kontext är borta, varje preferens är bortglömd, och projektet måste förklaras från början.

Detta är ingen bugg. Det är så stora språkmodeller (LLM) fungerar till sin design. De är tillståndslösa (stateless): varje förfrågan är oberoende, varje svar genereras från den prompt du skickar just nu, utan minne, ingen historik och ingen kontinuitet bortom de tokens som finns i det nuvarande kontextfönstret.

För interaktioner med ett enda steg är det okej. Ställ en fråga, få ett svar, gå vidare. Men för agenter — system som är tänkta att göra saker över flera sessioner, lära sig av misstag och utvecklas tillsammans med dig — är tillståndslöshet en hård arkitektonisk begränsning. Det är ett av de centrala olösta problemen inom self-hosted AI systems.

Branschen har försökt lösa detta. LangChain lade till minnesmoduler. OpenAI introducerade assistenter med trådar (threads). Ramverk som Letta, Zep och Cognee byggde hela arkitekturer kring persistent minne. Databricks publicerade om “memory scaling” — idén att agentens prestanda förbättras med ackumulerad erfarenhet. Dedikerade benchmark-rapporter, undersökningar om episodiskt minne och ett snabbt växande ekosystem av verktyg har alla dykt upp sedan 2024 för att adressera vad som alltmer erkänns som ett av de centrala olösta problemen inom agentisk AI.

De flesta av dessa tillvägagångssätt delar ett gemensamt problem: de behandlar minne som en eftertanke — en databas som du gör frågor mot, ett kontextfönster som du fyller upp, ett hämtningssystem som tillför latens och brus snarare än klarhet.

Hermes Agent tar en fundamentalt annorlunda approach. Minne är inte något agenten hämtar när det behövs. Det är något agenten är hela tiden — inbyggt i systemprompten, kurerat, avgränsat och alltid aktivt. Det är tillräckligt litet för att vara snabbt, tillräckligt strukturerat för att vara användbart och tillräckligt disciplinerat för att veta vad som ska glömmas bort.

Denna artikel förklarar exakt hur det fungerar.

Del 1: Problemet med AI-agentens minne

Varför “lägga till kontext” inte skalar för agenter

Den uppenbara lösningen på tillståndslös AI är att lägga till kontext. Bifoga den tidigare konversationen. Inkludera projektdokumentationen. Skicka hela historiken.

Under en period fungerar det. Du har ett kontextfönster på 128K. Du kan få plats med mycket text där.

Men kontext är inte minne — det finns en verklig och viktig skillnad mellan dem. Kontext är allt som visas för dig just nu; minne är det du aktivt behåller och bär med dig framåt.

Kontext saknar kurering. Det är en dump: när den växer måste modellen bearbeta tusentals tokens av irrelevant historik för att hitta den enda fakta den behöver. Det kostar tokens och pengar, ökar latensen och når till slut taket.

Minne är kurerat. Det är destillationen av erfarenhet till något kompakt och handlingskraftigt. Det växer inte obegränsat — det konsoliderar, uppdaterar och glömmer.

Det mänskliga minnet fungerar på samma sätt. Du kommer inte ihåg varje konversation du någonsin haft. Du kommer ihåg de delar som spelar roll: vem du pratar med, vad de bryr sig om, vad ni har kommit överens om, vad du har lärt dig. Resten blir antingen bortglömt eller sökbart när du behöver det.

Forskningslandskapet

Marknaden för AI-agentminne har exploderat sedan 2024, med dedikerade benchmark-sviter, en växande forskningslitteratur och ett mätbart prestandagap mellan olika arkitektoniska tillvägagångssätt. Här är läget just nu.

Letta (tidigare MemGPT) var ett av de tidigaste ramverken som behandlade persistent minne som en förstahandsprioritet och nådde 21,7K stjärnor på GitHub. Det använder en OS-inspirerad trestegsmodell: kärnminne (litet, alltid i kontext), recall-minne (sökbar konversationshistorik) och arkivminne (långsiktig kallförvaring). Insikten att inte allt minne är lika värdefullt var korrekt. Implementeringen kräver dock att agenter körs helt inom Letta-runtime — att använda det innebär att man anammar hela plattformen, inte bara ett minneslager.

Zep / Graphiti fokuserar på konversationsminne med temporal entitetsspårning — fakta har giltighetsfönster så att grafen vet när något var sant. Det är starkt för chatbots som behöver relationsgrafer, men mindre lämpat för autonoma agenter som spårar miljöfakta och projektkonventioner.

Cognee är byggt för kunskapsextraktion från dokument och strukturerad data, med över 30 ingestion-connectors och en knowledge graph-backend. Det utmärker sig inom institutionell kunskap och RAG pipelines men är mindre fokuserat på personligt agentminne. Se self-hosting Cognee with local LLMs för en praktisk installationsguide.

Hindsight utför recall baserat på kunskapsgrafer med entitetsrelationer och ett unikt reflect-syntesverktyg som utför tvärgående minnessyntes — att kombinera flera minnen till nya insikter. Det är bland de bäst presterande på benchmarks för agentminne och finns tillgängligt som en minnesleverantör för Hermes Agent.

Mem0 hanterar minnesextraktion på serversidan via LLM-analys, vilket kräver minimal konfiguration. Mem0-forskningsrapporten, publicerad vid ECAI 2025 (arXiv:2504.19413), benchmarkade tio olika tillvägagångssätt för AI-minne och validerade metoden med selektiv extraktion — att lagra diskreta fakta, ta bort dubbletter och endast hämta det som är relevant. Mem0 har vuxit till cirka 48K stjärnor på GitHub och stöder 21 ramverksintegrationer. Kompromissen är molnberoende och kostnad.

Databricks forskning om memory scaling introducerade konceptet att agentens prestanda förbättras med ackumulerad erfarenhet. Deras arkitektur håller systemprompter, företagsresurser och episodiska/semantiska minnen på organisations- och användarnivå, vilket validerar idén att minneskvalitet är lika viktigt som modellens kapacitet.

Den gemensamma nämnaren för de flesta ramverk är att de behandlar minne som ett hämtningsproblem: lagra det någonstans, gör frågor mot det när det behövs, injicera det i kontexten. Hermes gör tvärtom — minnet hämtas inte vid behov, det injiceras vid sessionens start och är alltid närvarande. Alltid aktivt, alltid tillgängligt, tillräckligt kurerat för att förbli användbart.

Del 2: Arkitektur

Läs denna del uppifrån och ner — lager och recall/store per steg först, sedan vad som finns i MEMORY.md och USER.md, och sist hur man ansluter en extern leverantör.

Två lager

Hermes staplar minnet i två lager:

1. Inbyggt — MEMORY.md och USER.md, filbaserat, alltid aktivt. Hårda gränser på 2 200 tecken (agentanteckningar) och 1 375 tecken (användarprofil).
2. En extern leverantör (valfritt) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory och liknande som du aktiverar via konfiguration. Endast en extern backend körs åt gången. Den tillför hämtning och retention vid sidan av filerna; den ersätter dem inte.

Den mentala modellen är additiv — frysta kärnfiler plus högst ett plugin. Prefetch- och sync-hooks orkestrerar det externa lagret; de två filerna förblir injicerade separat som en del av den frysta systemprompten.

Runtime-flöde (prefetch och sync)

Recall sker innan modellen svarar; persistens sker efter assistentmeddelandet. I Hermes Agents minneshanterare motsvarar detta prefetch på vägen in och sync på vägen ut. Namnen nedan matchar implementationen (MemoryManager, per-leverantör prefetch / sync_turn / queue_prefetch).

User message
    |
    v
MemoryManager.prefetch_all(query)        <-- recall phase
    |
    +-- provider.prefetch(query)        <-- varje extern leverantör söker i sin lagring
    |
    v
Context injected into LLM turn
    |
    v
LLM responds (assistant message)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- store phase
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- bakgrundssökning inför nästa steg

Inbyggda MEMORY.md och USER.md hämtas inte genom prefetch_all — de är redan en del av den frysta systemprompten. Externa backends ansluts till prefetch_all / sync_all; queue_prefetch låter en leverantör förbereda hämtning för nästa steg utan att blockera det nuvarande svaret.

Tre vägar till långtidsminnet

1. Inbyggt memory-verktyg. Modellen anropar memory med add, replace eller remove när instruktionerna säger att något bör bestå — varaktiga fakta, preferenser, rättelser, miljöanteckningar. target='user' underhåller USER.md; target='memory' underhåller MEMORY.md. Exempel på format: memory(action='add', target='user', content='…').

2. Passiv retention på externa leverantörer. Varje steg anropar ramverkets sync-väg så att konversationen kan delas upp i bitar (chunks), sammanfattas eller extraheras utan att modellen behöver namnge varje enskild fakta. Beteendet varierar beroende på backend — till exempel batchar Hindsight steg och kör strukturerad retention med entiteter och relationer; Honcho skickar dialogen genom sin dialektiska pipeline; Mem0- och Supermemory-liknande stackar extraherar fakta passivt från stegen.

3. Leverantörsspecifika verktyg. När pluginet exponerar dem, kan explicita skrivningar som honcho_conclude, hindsight_retain eller honcho_profile lagra varaktiga delar vid behov.

Automatisk recall kontra leverantörsverktyg

Kärnminnet behöver inget läsverktyg — det finns redan i prompten. Externa backends tillför antingen automatisk injicering från prefetch (ingen separat recall-verktygsanrop för den delen av kontexten) eller explicita hämtningsverktyg (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect och liknande) när modellen behöver en mer precisionsinriktad fråga än vad prefetch ensamt kan ge.

Recall-lägen (externa leverantörer)

Plugins stöder ett konfigurerbart recall-läge (vanligtvis recall_mode bredvid memory.provider i konfigurationen) som byter tokens mot kontroll.

När ingen extern leverantör är inställd (memory.provider är tom eller ej satt), gäller endast de inbyggda filerna och sökning i sessionen — ingen prefetch/sync från ett plugin.

Sökvägar på disk och budgetar

Hermes Agents inbyggda minne finns i två filer.

• ~/.hermes/memories/MEMORY.md — Agentens personliga anteckningar (2 200 tecken, ~800 tokens)
• ~/.hermes/memories/USER.md — Användarprofil (1 375 tecken, ~500 tokens)

Detta är hela den persistenta minneyta: två filer, totalt under 3 600 tecken, färre än 1 300 tokens. Det ser medvetet litet ut eftersom det är det — och det är precis den avsedda designen.

MEMORY.md: Agentens anteckningar

Detta är där agenten lagrar allt den lär sig om sin miljö, projektet, verktyg, konventioner och lärdomar. Så här ser det ut:

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

Detta är inte loggar. Det är fakta. Täta, deklarativa, informationsrika. Inga tidsstämplar, inget fluff, inget “den 5 januari bad användaren mig att…”.

USER.md: Användarprofilen

Detta är där agenten lagrar allt den vet om dig.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

Identitet, roll, preferenser, tekniska färdigheter, kommunikationsstil, irritationsmoment. Det som gör att agenten svarar annorlunda på dig än på någon annan.

Mönstret med frysta snapshots (The Frozen Snapshot Pattern)

Vid sessionens start laddas båda filerna från disk och injiceras som ett fryst block i systemprompten. Så här ser det ut:

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]
══════════════════════════════════════════════
User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
§
This machine runs Ubuntu 22.04, has Docker and kubectl installed
§
User prefers snake_case for variable names and avoids camelCase
§

══════════════════════════════════════════════
USER PROFILE (who the user is) [8% — 110/1,375 chars]
══════════════════════════════════════════════
User is a full-stack developer comfortable with TypeScript, Go, and Python.
§
User prefers snake_case for variable names and avoids camelCase.
§

Formatet använder rubriker, användningsprocent, teckenräkning och § (avsnittstecken) som avgränsare. Inlägg kan vara flerradiga. Det är designat för att vara parsebart för modellen samtidigt som det förblir mänskligt läsbart.

Varför fryst? Prefix caching. Systemprompten är densamma under varje steg i en session. Genom att hålla minnet statiskt efter sessionens start kan modellen cachelagra prefix-beräkningen och endast bearbeta de föränderliga delarna — konversationen. Detta är en betydande prestandaoptimering. Du räknar inte om attention för samma minnestokens vid varje steg.

Ändringar som görs under en session sparas till disk omedelbart, men de visas i systemprompten först vid nästa sessionsstart. Svar från verktyg visar alltid det aktuella tillståndet, men modellens “medvetande” ändras inte mitt under sessionen. Detta förhindrar att modellen jagar sin egen svans — att uppdatera minnet och sedan reagera på sin egen uppdatering i samma konversation.

Teckenbegränsningar som en funktion

2 200 tecken. 1 375 tecken. Detta är inte godtyckliga gränser. Det är designmässiga begränsningar som tvingar fram kurering.

Obegränsat minne är en belastning. Det uppmuntrar till att dumpa in allt, aldrig konsolidera och till slut bli brus. Avgränsat minne tvingar agenten att vara selektiv. Vad är faktiskt viktigt? Vad kommer jag behöva igen? Vad kan komprimeras utan att förlora betydelse?

När minnet är fullt misslyckas inte agenten bara tyst. Den får ett felmeddelande med nuvarande inlägg och användning, och följer sedan ett arbetsflöde:

1. Läs nuvarande inlägg från felmeddelandet
2. Identifiera inlägg som kan tas bort eller konsolideras
3. Använd replace för att slå samman relaterade inlägg till kortare versioner
4. Lägg till det nya inlägget

Det är så minnet förblir användbart. Det är inte en databas. Det är en kurerad samling av fakta som betyder något.

Säkerhet: Scanning av prompt injection

Varje minnesinlägg skannas innan det accepteras. Systemet blockerar försök till prompt injection, läckage av autentiseringsuppgifter, SSH-bakdörrar och osynliga Unicode-tecken.

Minnet dedupliceras också. Exakt dubblerade inlägg förkastas automatiskt. Detta förhindrar att motståndare försöker injicera skadligt innehåll genom upprepade inskickningar.

Externa minnesleverantörer (aktivering och länkar)

Utöver inbyggda MEMORY.md och USER.md kan Hermes Agent ansluta en extern minnesplugin åt gången — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover eller Supermemory — för persistent kunskap över sessioner. Endast en extern leverantör är aktiv samtidigt; de två kärnfilerna förblir laddade vid sidan av den (additivt, inte som en ersättning).

Aktivera och inspektera leverantörer med hermes memory setup, hermes memory status och hermes memory off, eller ställ in memory.provider och recall_mode i ~/.hermes/config.yaml. Mönster för autentisering varierar (till exempel HINDSIGHT_API_KEY, Honcho-nycklar under $HERMES_HOME/honcho.json); använd hermes memory setup för interaktiv konfiguration.

Minimalt YAML-format för endast inbyggda funktioner:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Exempel på aktivering för en backend (byt ut hindsight mot honcho, mem0, supermemory eller andra som din installation stöder):

memory:
  provider: "hindsight"

För den fullständiga jämförelsetabellen, anteckningar om LLM- och embedding-beroenden, genomgångar per leverantör och hur dessa backends relaterar till OpenClaw och andra stackar, se Agent memory providers compared.

För profilspecifik konfiguration och produktionsarbetsflöden, se Hermes Agent production setup. AI Systems Memory hub listar denna guide samt relaterade artiklar om Cognee och kunskapslager.

Del 3: När minnet aktiveras — Triggers och beslut

Den vanligaste frågan om Hermes Agents minne är när det faktiskt sparar något.

Svaret är: ständigt, men selektivt. Agenten hanterar sitt eget minne via memory-verktyget, och beslutet att spara drivs av en kombination av explicita signaler och implicita mönster.

Skriv-triggers: När bestämmer agenten att spara?

Agenten sparar minne proaktivt. Den väntar inte på att du ska be den. Här är vad som triggar det.

Användarrättelser. När du rättar agenten är det en signal att komma ihåg. “Gör inte så igen.” “Använd detta istället.” “Kom ihåg detta.” Detta är explicita instruktioner att uppdatera minnet.

Exempel: du ber agenten konfigurera en Python-miljö. Den föreslår pip. Du säger “Jag använder poetry till allt.” Agenten sparar: User prefers using the 'poetry' package manager for all Python projects.

Upptäckta preferenser. Agenten observerar mönster och drar slutsatser om preferenser. Om du konsekvent använder ett visst verktyg, ramverk eller arbetsflöde, sparas det.

Exempel: efter att ha sett dig använda poetry flera gånger i olika projekt, sparar agenten det som en preferens.

Miljöfakta. Saker som rör maskinen, projektet, de installerade verktygen. Dessa upptäcks genom utforskning och sparas som fakta.

Exempel: agenten kontrollerar vad som är installerat och sparar: This machine runs Ubuntu 22.04, has Docker and kubectl installed.

Projektkonventioner. Hur projektet är strukturerat, vilka verktyg det använder, vilka mönster det följer. Dessa upptäcks genom kodgranskning och sparas.

Exempel: User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.

Slutförda komplexa arbetsflöden. Efter att ha slutfagit en uppgift som krävde 5+ verktygsanrop, överväger agenten att spara tillvägagångssättet som en färdighet, eller åtminstone notera vad som fungerade.

Verktygsegenskaper och lösningar (workarounds). När agenten upptäcker något icke-uppenbart om ett verktyg, ett API eller ett system — en begränsning, en lösning, en konvention — sparar den det.

Vad som hoppas över:

• Triviell eller uppenbar information
• Saker som enkelt kan återupptäckas
• Rådata-dumps
• Sessionsspecifik förgänglighet (ephemera)
• Information som redan finns i kontextfilerna (SOUL.md, AGENTS.md)

Läs-triggers: När gör agenten en recall?

Minnet hämtas inte — det finns alltid där. Men det finns olika nivåer av åtkomst.

Sessionsstart (automatiskt). MEMORY.md och USER.md injiceras i systemprompten. Agenten har dem från första token. Ingen fråga behövs, ingen latens, inget verktygsanrop. Detta är kärnminnet — alltid aktivt.

session_search (vid behov). När agenten behöver hitta något från tidigare konversationer som inte finns i kärnminnet, använder den verktyget session_search. Detta gör frågor mot SQLite (~/.hermes/state.db) med FTS5 fulltext-sökning och Gemini Flash-sammanfattning. Använd detta när frågan låter som “vi pratade om det här tidigare” snarare än “kom ihåg den här faktan för alltid”.

Exempel: du frågar “Diskuterade vi Docker-nätverk förra veckan?”. Agenten söker i sessionshistoriken och returnerar en sammanfattning av den relevanta konversationen.

Verktyg för externa leverantörer (när konfigurerat). När en extern minnesleverantör är aktiv, kör ramverket även ett automatiskt prefetch-steg före varje svar (se Del 2). Ytterligare verktyg som honcho_search, hindsight_recall eller mem0_search är till för riktade sökningar när agenten väljer explicit hämtning — beroende på recall_mode kan automatisk injicering, verktyg eller båda vara aktiva.

Beslutsträdet

Så här väger agenten frågan “är detta värt att komma ihåg?”:

Is this a correction or explicit instruction?
  YES → Save to memory
  NO → Is this a preference or pattern?
    YES → Save to user profile
    NO → Is this an environment fact or convention?
      YES → Save to memory
      NO → Is this easily re-discovered?
        YES → Skip
        NO → Is this session-specific?
          YES → Skip
          NO → Save to memory

Agenten överanalyserar inte detta. Den sparar proaktivt, konsoliderar när det är fullt och litar på teckenbegränsningarna för att hålla allt kortfattat.

Del 4: Internt minne kontra externa kunskapsbaser

Det är här förvirring ofta uppstår. Hermes Agent har internt minne (MEMORY.md, USER.md, externa leverantörer) och externa kunskapsbaser (LLM Wiki, Obsidian, Notion, ArXiv, filsystem), och de tjänar helt olika syften. Detta liknar skillnaden mellan retrieval-augmented generation pipelines och en agents arbetsminne — extern hämtning är bra för djup kunskapssökning, inte för att bära identitet och preferenser. Internt minne är agentens hjärna — alltid aktiv, kurerad, medförd i varje session. Externa kunskapsbaser är dess bibliotek — omfattande referensresurser som konsulteras vid behov.

Skillnaden

Internt minne (hjärnan):

• Litet, persistent, injicerat i systemprompten
• Innehåller: användarpreferenser, agentkonventioner, omedelbara lärdomar
• Alltid “i tankarna” under konversationen
• Kurerat, avgränsat, aktivt hanterat
• Exempel: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Externa kunskapsbaser (biblioteket):

• Omfattande, endast för referens, åtkomst vid behov
• Innehåller: dokument, artiklar, kod, anteckningar, databaser
• Åtkomms via verktyg vid behov
• “Kommer inte ihåg” — slås upp
• Exempel: LLM Wiki, Obsidian, Notion, ArXiv, filsystem, GitHub

Hur de förhåller sig till varandra

Agenten åtkomstar externa baser via verktyg vid behov. Den “kommer inte ihåg” dem — den slår upp dem.

LLM Wiki (llm-wiki): Karpathys sammanlänkade Markdown-kunskapsbas för att bygga och söka i domänkunskap. Agenten använder färdigheten llm-wiki för att läsa, söka och ställa frågor i den. Det är en referensresurs, inte ett minne.

Obsidian: Personliga anteckningsarkiv med tvåvägslänkar. Agenten använder färdigheten obsidian för att läsa, söka och skapa anteckningar. Obsidian är en del av det bredare personal knowledge management ekosystemet som Hermes kan använda som en biblioteksresurs.

Notion/Airtable: Strukturerade databaser och wikis som nås via API. Agenten gör frågor mot dem vid behov.

ArXiv: Repositorier för akademiska artiklar. Agenten söker efter och extraherar artiklar när den forskar om ett ämne.

Filsystem: Projektkod, dokumentation, konfigurationer. Agenten läser filer när den arbetar med ett projekt.

Destilleringsmönstret

Här är den viktigaste insikten: kritiska insikter från externa baser kan destilleras in i det interna minnet.

Exempel: agenten läser en artikel från ArXiv om minnesskalning för AI-agenter. Den sparar inte hela artikeln i minnet. Den sparar den viktigaste slutsatsen: Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.

Den externa resursen är enorm. Det interna minnet är destillationen.

När man ska använda vad

Internt minne för:

• “Vem hjälper jag?”
• “Vad föredrar de?”
• “Vad lärde vi oss precis?”
• “Hur ser projektuppsättningen ut?”
• “Vilka verktyg finns tillgängliga?”

Externa kunskapsbaser för:

• “Vad är den senaste forskningen om X?”
• “Vad finns i min projektdokumentation?”
• “Vad diskuterade vi förra månaden?”
• “Vad är API:et för denna tjänst?”
• “Hur ser kodstrukturen ut?”

Agenten förstår skillnaden och använder dem på lämpligt sätt — den blandar inte ihop att slå upp ett dokument med att komma ihåg något den har lärt sig om dig och din miljö.

Del 5: Hur det faktiskt fungerar

Låt oss titta på mekaniken.

memory-verktyget

Agenten hanterar minnet genom ett enda verktyg med tre handlingar: add, replace, remove.

Det finns ingen read-handling — minnesinnehållet injiceras automatiskt i systemprompten. Agenten behöver inte läsa det eftersom det alltid finns där.

add — Lägger till ett nytt inlägg.

memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

replace — Ersätter ett befintligt inlägg med hjälp av substring-matchning.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

remove — Tar bort ett inlägg med hjälp av substring-matchning.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Substring-matchning

replace och remove använder korta, unika delsträngar via old_text. Du behöver inte hela inläggets text. Detta möjliggör kirurgiska ändringar utan att veta det exakta innehållet.

Om en delsträng matchar flera inlägg returneras ett felmeddelande som ber om en mer specifik matchning. Agenten förfinar sedan sin fråga.

Mållager: memory vs user

Parametern target avgör vilken fil som uppdateras.

• memory — Agentens personliga anteckningar. Miljöfakta, projektkonventioner, verktygsegenskaper, lärdomar.
• user — Användarprofil. Identitet, roll, tidszon, kommunikationspreferenser, irritationsmoment, arbetsmönster.

Kapacitetshantering

När minnet är >80 % fullt, konsoliderar agenten. Den slår samman relaterade inlägg, tar bort föråldrad fakta och komprimerar information.

Bra minnesinlägg är kompakta och informationsrika:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

Dåliga minnesinlägg är vaga eller ordrika:

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

Det första är tätt och användbart. Det andra är antingen för vagt eller för ordrikt.

Session Search kontra persistent minne

session_search och persistent minne tjänar olika syften.

Tumregel: använd minne för kritiska fakta som alltid bör finnas i kontexten. Använd session search för historiska uppslag.

Del 6: Filosofin

Varför avgränsat minne slår obegränsat minne

Instinkten är att göra minnet så stort som möjligt. Spara allt. Hämta det du behöver.

Avgränsat minne fungerar bättre. Här är varför.

Kurering tvingar fram kvalitet. När du har begränsat utrymme sparar du bara det som betyder något. Du komprimerar, konsoliderar och prioriterar. Obegränsat minne uppmuntrar till att dumpa in allt och aldrig städa upp.

Hastighet spelar roll. 1 300 tokens i systemprompten är snabbt. 100 000 tokens hämtade från en databas är långsamt. Minne bör vara omedelbart, inte en fråga.

Brus försämrar prestandan. Mer minne innebär inte bättre minne. Det innebär brusigare minne. Modellen måste skilja signal från brus, och det kräver attention — attention som istället borde läggas på den faktiska uppgiften.

Att glömma är en funktion. Det mänskliga minnet glömmer. Det är ingen bugg — det är så vi prioriterar. Agenter bör också glömma. Inte allt förtjänar att komma ihågs.

“Glömska”-problemet

Agenter behöver avlära sig. Inte bara glömma, utan aktivt ta bort föråldrad information.

Så här hanterar Hermes Agent det:

• remove-handling: Ta bort inlägg som inte längre är relevanta.
• replace-handling: Uppdatera inlägg med ny information.
• Kapacitetstryck: När minnet är fullt konsoliderar agenten och tar bort gamla inlägg.
• Säkerhetsskanning: Blockerar skadliga eller korrupta inlägg.

Att glömma är inte ett misslyckande — det är underhåll. En agent som inte kan avlära sig kommer till slut att bära på lika mycket brus som signal.

Minnesskalning (Memory Scaling)

Databricks introducerade konceptet “memory scaling”: presterar en agent med tusentals användare bättre än en med en enda användare?

Deras forskning tyder på ja, men med förbehåll. Minnesskalning kräver:

1. Kvalitativ extraktion: Alla interaktioner är inte värda att komma ihåg. Agenten måste extrahera insikter, inte loggar.
2. Effektiv hämtning: Hämtade minnen måste vara relevanta. Brus försämrar prestandan.
3. Generalisering: Minnen bör vara mönster, inte specifika detaljer. “Användaren föredrar Python” skalar. “Användaren körde kommando X vid tidpunkt Y” gör det inte.

Hermes Agents avgränsade minne stöder naturligt minnesskalning. Genom att tvinga fram kurering säkerställer det att minnen är generaliserbara, kompakta och användbara.

Vad detta innebär för framtiden

Minnet håller på att bli den konkurrensfördel (moat) som definierar agentisk AI — inte själva modellen, utan vad modellen bär med sig mellan sessioner. Två agenter med identiska underliggande modeller kan prestera mycket olika: en kommer ihåg dina preferenser, din miljö och dina tidigare misstag; den andra börjar från noll varje gång.

Frågan är inte längre om agenter bör ha ett persistent minne. Det är avgjort: de måste ha det. Den öppna frågan är hur man designar det minnet väl — vad man ska behålla, vad man ska kasta, hur man gör det omedelbart och hur man förhindrar att det blir brus.

Hermes Agents svar är att hålla minnet litet, kurerat och alltid aktivt — inte en databas som du ställer frågor mot, utan en arbetande modell av användaren som agenten bär med sig in i varje konversation.

Slutsats

Hermes Agents minnessystem är medvetet enkelt: två filer, fasta teckenbegränsningar, ingen hämtningspipeline, ingen vector database och ingen latens per fråga. Det som låter som en begränsning är själva poängen.

Det fungerar eftersom det behandlar minne på samma sätt som en hjärna fungerar snarare än som en databas — litet, kurerat och alltid aktivt. Agenten hämtar inte minnet när den behöver det; minnet är helt enkelt alltid där, vävt in i systemprompten från den första token i varje session.

Externa minnesleverantörer utökar detta system för användare som behöver mer: kunskapsgrafer, stöd för flera agenter, självhostad lagring, företagsfunktioner. Men kärnan förblir densamma: avgränsad, kurerad, alltid tillgänglig.

Och externa kunskapsbaser — LLM Wiki, Obsidian, Notion, ArXiv — tjänar en annan roll. De är biblioteket, inte hjärnan. Agenten slår upp dem, kommer dem inte ihåg. Kritiska insikter destilleras in i det interna minnet; resten stannar i biblioteket.

Detta är hur en AI-agent kommer ihåg dig. Inte genom att lagra allt, utan genom att komma ihåg det som betyder något.

Hermes Agent släpptes av Nous Research i februari 2026 och nådde över 64 000 stjärnor på GitHub i april 2026 (v0.9.0), med över 242 bidragsgivare. Den är open-source och finns tillgänglig på github.com/NousResearch/hermes-agent. För installation, konfiguration och guider för arbetsflöden, se Hermes Agent overview.