Hermes Agent Memory System: come funziona realmente la memoria persistente dell'IA

Sai come funziona. Apri una chat con un agente AI, spieghi il tuo progetto, condividi le tue preferenze, porti a termine un lavoro e chiudi la scheda. Torni la settimana successiva ed è come parlare con uno sconosciuto: tutto il contesto è sparito, ogni preferenza è dimenticata, il progetto va spiegato da capo.

Questo non è un bug. È il modo in cui i Large Language Models sono progettati per funzionare. Sono stateless: ogni richiesta è indipendente, ogni risposta viene generata in base a qualsiasi prompt tu invii in questo momento, senza memoria, senza cronologia e senza continuità oltre i token nella finestra di contesto corrente.

Per le interazioni a turno singolo, va bene. Fai una domanda, ottieni una risposta, vai avanti. Ma per gli agenti — sistemi che dovrebbero fare cose attraverso più sessioni, imparare dagli errori ed evolversi con te — l’assenza di stato è un limite architettonico invalicabile. È uno dei centrali problemi irrisolti nei sistemi AI self-hosted.

Il settore ha cercato di risolvere il problema. LangChain ha aggiunto moduli di memoria. OpenAI ha introdotto gli assistenti con i thread. Framework come Letta, Zep e Cognee hanno costruito intere architetture attorno alla memoria persistente. Databricks ha pubblicato ricerche sul “memory scaling” — l’idea che le prestazioni dell’agente migliorino con l’esperienza accumulata. Dal 2024 sono emersi paper dedicati ai benchmark, sondaggi sulla memoria episodica e un ecosistema di strumenti in rapida crescita per affrontare ciò che è sempre più riconosciuto come uno dei problemi centrali irrisolti dell’AI agentica.

La maggior parte di questi approcci condivide un problema comune: trattano la memoria come un elemento secondario — un database da interrogare, una finestra di contesto da riempire, un sistema di recupero che aggiunge latenza e rumore invece di chiarezza.

Hermes Agent adotta un approccio fondamentalmente diverso. La memoria non è qualcosa che l’agente recupera quando necessario. È qualcosa che l’agente è in ogni momento — integrata nel system prompt, curata, delimitata e sempre attiva. È abbastanza piccola da essere veloce, abbastanza strutturata da essere utile e abbastanza disciplinata da sapere cosa dimenticare.

Questo articolo spiega esattamente come funziona.

Parte 1: Il problema della memoria dell’agente AI

Perché “aggiungere solo contesto” non scala per gli agenti

La soluzione ovvia alla statelessness dell’AI è aggiungere contesto. Allegare la conversazione precedente. Includere la documentazione del progetto. Inviare l’intera cronologia.

Per un po’, questo funziona. Hai una finestra di contesto da 128K. Puoi inserire molto testo lì dentro.

Ma il contesto non è la memoria — c’è una differenza reale e importante tra i due. Il contesto è tutto ciò che ti viene mostrato in questo momento; la memoria è ciò che conservi e porti avanti attivamente.

Il contesto non ha una curatela. È un accumulo: man mano che cresce, il modello deve elaborare migliaia di token di cronologia irrilevante per trovare l’unico fatto di cui ha bisogno. Ciò costa token e denaro, aumenta la latenza e alla fine raggiunge il limite massimo.

La memoria è curata. È la distillazione dell’esperienza in qualcosa di compatto e azionabile. Non cresce indefinitamente: si consolida, si aggiorna e dimentica.

La memoria umana funziona allo stesso modo. Non ricordi ogni singola conversazione che hai mai avuto. Ricordi le parti che contano: con chi stai parlando, cosa gli interessa, cosa avete concordato, cosa hai imparato. Il resto viene dimenticato o è consultabile quando ne hai bisogno.

Il panorama della ricerca

Lo spazio della memoria degli agenti AI è esploso dal 2024, con suite di benchmark dedicate, una crescente letteratura di ricerca e un divario di prestazioni misurabile tra i diversi approcci architettonici. Ecco la situazione attuale.

Letta (precedentemente MemGPT) è stato uno dei primi framework a trattare la memoria persistente come una priorità di primo livello, raggiungendo 21,7K stelle su GitHub. Utilizza un modello a tre livelli ispirato ai sistemi operativi: memoria core (piccola, sempre nel contesto), memoria di richiamo (cronologia delle conversazioni consultabile) e memoria di archivio (storage a lungo termine). L’intuizione che non tutta la memoria sia uguale era corretta. L’implementazione, tuttavia, richiede che gli agenti girino interamente all’interno del runtime di Letta — adottarlo significa adottare l’intera piattaforma, non solo uno strato di memoria.

Zep / Graphiti si concentra sulla memoria conversazionale con tracciamento temporale delle entità — i fatti hanno finestre di validità in modo che il grafo sappia quando qualcosa era vero. È forte per i chatbot che necessitano di grafi di relazioni, meno adatto per agenti autonomi che tracciano fatti dell’ambiente e convenzioni di progetto.

Cognee è costruito per l’estrazione di conoscenza da documenti e dati strutturati, con oltre 30 connettori di ingestione e un backend basato su knowledge graph. Eccelle nella conoscenza istituzionale e nelle pipeline RAG, ma è meno focalizzato sulla memoria personale dell’agente. Consulta self-hosting Cognee con LLM locali per una guida pratica alla configurazione.

Hindsight esegue il richiamo basato su knowledge graph con relazioni tra entità e un unico strumento di sintesi reflect che esegue la sintesi cross-memory — combinando più memorie in nuove intuizioni. È tra i migliori nei benchmark sulla memoria degli agenti ed è disponibile come provider di memoria per Hermes Agent.

Mem0 gestisce l’estrazione della memoria lato server tramite analisi LLM, richiedendo una configurazione minima. Il paper di ricerca di Mem0, pubblicato all’ECAI 2025 (arXiv:2504.19413), ha testato dieci approcci distinti alla memoria AI e ha convalidato l’approccio di estrazione selettiva — memorizzando fatti discreti, eliminando i duplicati e recuperando solo ciò che è rilevante. Mem0 è cresciuto fino a circa 48K stelle su GitHub e supporta 21 integrazioni di framework. Il compromesso è la dipendenza dal cloud e i costi.

La ricerca di Databricks sullo scaling della memoria ha introdotto il concetto che le prestazioni dell’agente migliorano con l’esperienza accumulata. La loro architettura contiene system prompt, asset aziendali e memorie episodiche/semantiche con scope a livello di organizzazione e utente, convalidando l’idea che la qualità della memoria sia importante quanto la capacità del modello.

Il filo conduttore di la maggior parte dei framework è che trattano la memoria come un problema di recupero: memorizzala da qualche parte, interrogala quando necessario, iniettala nel contesto. Hermes fa l’opposto — la memoria non viene recuperata su richiesta, viene iniettata all’inizio della sessione ed è sempre presente. Sempre attiva, sempre disponibile, sufficientemente curata per rimanere utile.

Parte 2: Architettura

Leggi questa parte dall’alto verso il basso — prima i livelli e il richiamo/memorizzazione per turno, poi cosa vive in MEMORY.md e USER.md, infine come collegare un provider esterno.

Due livelli

Hermes impila la memoria in due livelli:

1. Integrati (Built-in) — MEMORY.md e USER.md, basati su file, sempre attivi. Limiti massimi di 2.200 caratteri (note dell’agente) e 1.375 caratteri (profilo utente).
2. Un provider esterno (opzionale) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory e i peer che abiliti tramite config. Solo un backend esterno è attivo alla volta. Aggiunge recupero e ritenzione accanto ai file; non li sostituisce.

Il modello mentale è additivo — file core congelati più al massimo un plugin. Gli hook di prefetch e sync orchestrano lo strato esterno; i due file vengono iniettati separatamente come parte del system prompt congelato.

Flusso del runtime (prefetch e sync)

Il richiamo avviene prima che il modello risponda; la persistenza avviene dopo il messaggio dell’assistente. Nel memory manager di Hermes Agent, questo si traduce in prefetch in entrata e sync in uscita. I nomi qui sotto corrispondono alla superficie di implementazione (MemoryManager, per-provider prefetch / sync_turn / queue_prefetch).

Messaggio dell'utente
    |
    v
MemoryManager.prefetch_all(query)        <-- fase di richiamo (recall)
    |
    +-- provider.prefetch(query)        <-- ogni provider esterno cerca nel proprio store
    |
    v
Contesto iniettato nel turno LLM
    |
    v
LLM risponde (messaggio dell'assistente)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- fase di memorizzazione (store)
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- ricerca in background verso il turno successivo

I file integrati MEMORY.md e USER.md non vengono recuperati tramite prefetch_all — fanno già parte del system prompt congelato. I backend esterni si collegano a prefetch_all / sync_all; queue_prefetch consente a un provider di preparare il recupero per il turno successivo senza bloccare la risposta corrente.

Tre percorsi verso la memoria a lungo termine

1. Strumento memory integrato. Il modello chiama memory con add, replace o remove quando le istruzioni indicano che qualcosa deve persistere — fatti durevoli, preferenze, correzioni, note sull’ambiente. target='user' mantiene USER.md; target='memory' mantiene MEMORY.md. Esempio di forma: memory(action='add', target='user', content='…').

2. Ritenzione passiva sui provider esterni. Ogni turno il framework invoca il percorso di sync del provider in modo che la conversazione possa essere suddivisa in chunk, riassunta o estratta senza che il modello debba nominare ogni singolo fatto. Il comportamento varia in base al backend — ad esempio Hindsight raggruppa i turni ed esegue una ritenzione strutturata con entità e relazioni; Honcho invia il dialogo attraverso il suo pipeline dialettico; stack in stile Mem0 e Supermemory estraggono i fatti passivamente dai turni.

3. Strumenti specifici del provider. Quando il plugin li espone, scritture esplicite come honcho_conclude, hindsight_retain o honcho_profile memorizzano frammenti durevoli su richiesta.

Richiamo automatico rispetto agli strumenti del provider

La memoria core non ha bisogno di uno strumento di lettura — è già nel prompt. I backend esterni aggiungono o l’iniezione automatica dal prefetch (nessuna chiamata separata allo strumento di richiamo per quella parte di contesto) o strumenti di recupero espliciti (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect e simili) quando il modello ha bisogno di una query più precisa rispetto al solo prefetch.

Modalità di richiamo (provider esterni)

I plugin supportano una modalità di richiamo configurabile (tipicamente recall_mode accanto a memory.provider in config) che scambia token per controllo.

Quando non è impostato alcun provider esterno (memory.provider vuoto o non impostato), si applicano solo i file integrati e la ricerca della sessione — nessun prefetch/sync da un plugin.

Percorsi su disco e budget

La memoria integrata di Hermes Agent risiede in due file.

• ~/.hermes/memories/MEMORY.md — Note personali dell’agente (2.200 caratteri, ~800 token)
• ~/.hermes/memories/USER.md — Profilo utente (1.375 caratteri, ~500 token)

Questa è l’intera superficie della memoria persistente: due file, per un totale inferiore a 3.600 caratteri, meno di 1.300 token. Sembra deliberatamente piccola perché lo è — ed è esattamente l’intento del design.

MEMORY.md: Le note dell’agente

Qui l’agente memorizza tutto ciò che impara sul proprio ambiente, il progetto, gli strumenti, le convenzioni e le lezioni apprese. Ecco come appare:

Il progetto dell'utente è un microservizio Go in ~/code/gateway che usa gRPC + PostgreSQL
Questa macchina esegue Ubuntu 22.04, ha Docker e kubectl installati
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase

Questi non sono log. Sono fatti. Densi, dichiarativi, ricchi di informazioni. Niente timestamp, niente fronzoli, niente “il 5 gennaio l’utente mi ha chiesto di…”.

USER.md: Il profilo utente

Qui l’agente memorizza tutto ciò che sa su di te.

L'utente è uno sviluppatore full-stack esperto in TypeScript, Go e Python.
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase.
L'utente usa principalmente Linux Ubuntu 22.04.
L'utente effettua il deploy su AWS usando Terraform.

Identità, ruolo, preferenze, competenze tecniche, stile di comunicazione, fastidi. Le cose che fanno sì che l’agente risponda a te in modo diverso rispetto a chiunque altro.

Il pattern dello Snapshot Congelato (Frozen Snapshot)

All’inizio della sessione, entrambi i file vengono caricati dal disco e iniettati come un blocco congelato nel system prompt. Ecco come appare:

══════════════════════════════════════════════
MEMORY (le tue note personali) [7% — 166/2.200 caratteri]
══════════════════════════════════════════════
Il progetto dell'utente è un microservizio Go in ~/code/gateway che usa gRPC + PostgreSQL
§
Questa macchina esegue Ubuntu 22.04, ha Docker e kubectl installati
§
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase
§

══════════════════════════════════════════════
PROFILO UTENTE (chi è l'utente) [8% — 110/1.375 caratteri]
══════════════════════════════════════════════
L'utente è uno sviluppatore full-stack esperto in TypeScript, Go e Python.
§
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase.
§

Il formato utilizza intestazioni, percentuali di utilizzo, conteggi dei caratteri e delimitatori § (segno di sezione). Le voci possono essere multi-riga. È progettato per essere analizzabile dal modello pur rimanendo leggibile dagli umani.

Perché congelato? Prefix caching. Il system prompt è lo stesso per ogni turno in una sessione. Mantenendo la memoria statica dopo l’inizio della sessione, il modello può memorizzare la computazione del prefisso e processare solo le parti variabili — la conversazione. Questa è una significativa ottimizzazione delle prestazioni. Non stai ricalcolando l’attenzione sugli stessi token di memoria in ogni turno.

Le modifiche apportate durante una sessione vengono salvate immediatamente su disco, ma appaiono nel system prompt solo all’inizio della sessione successiva. Le risposte degli strumenti mostrano sempre lo stato live, ma la “mente” del modello non cambia a metà sessione. Ciò evita che il modello giri a vuoto — aggiornando la memoria e poi reagendo al proprio aggiornamento nella stessa conversazione.

I limiti di caratteri come una funzionalità

2.200 caratteri. 1.375 caratteri. Questi non sono limiti arbitrari. Sono vincoli di progettazione che impongono la curatela.

Una memoria illimitata è un rischio. Incoraggia l’inserimento di tutto, senza mai consolidare, e finisce per diventare rumore. Una memoria delimitata costringe l’agente a essere selettivo. Cosa è realmente importante? Di cosa avrò di nuovo bisogno? Cosa può essere compresso senza perdere significato?

Quando la memoria è piena, l’agente non fallisce semplicemente in silenzio. Riceve un errore con le voci attuali e l’utilizzo, quindi segue un flusso di lavoro:

1. Legge le voci attuali dalla risposta di errore
2. Identifica le voci rimovibili o consolidabili
3. Usa replace per unire voci correlate in versioni più brevi
4. Aggiunge la nuova voce

In questo modo la memoria rimane utile. Non è un database. È una collezione curata di fatti importanti.

Sicurezza: Scansione della Prompt Injection

Ogni voce di memoria viene scansionata prima dell’accettazione. Il sistema blocca tentativi di prompt injection, esfiltrazione di credenziali, backdoor SSH e caratteri Unicode invisibili.

Anche la memoria viene de-duplicata. Le voci duplicate esatte vengono rifiutate automaticamente. Ciò impedisce agli avversari di tentare di iniettare contenuti malevoli tramite invii ripetuti.

Provider di memoria esterni (attivazione e link)

Oltre ai file integrati MEMORY.md e USER.md, Hermes Agent può collegare un plugin di memoria esterno alla volta — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover o Supermemory — per una conoscenza persistente e multi-sessione. Solo un provider esterno è attivo alla volta; i due file core rimangono caricati insieme ad esso (additivo, non sostitutivo).

Attiva e ispeziona i provider con hermes memory setup, hermes memory status e hermes memory off, oppure imposta memory.provider e recall_mode in ~/.hermes/config.yaml. I pattern delle credenziali variano (ad esempio HINDSIGHT_API_KEY, chiavi Honcho sotto $HERMES_HOME/honcho.json); usa hermes memory setup per il collegamento interattivo.

Forma YAML minima con soli componenti integrati:

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

Esempio di attivazione per un backend (sostituisci hindsight con honcho, mem0, supermemory o altri supportati dalla tua installazione):

memory:
  provider: "hindsight"

Per la tabella comparativa completa, le note sulla dipendenza da LLM ed embedding, l’analisi per provider e come questi backend si relazionano con OpenClaw e altri stack, consulta Agent memory providers compared.

Per la configurazione specifica del profilo e i flussi di lavoro di produzione, consulta Hermes Agent production setup. L’AI Systems Memory hub elenca questa guida insieme agli articoli correlati su Cognee e lo strato di conoscenza.

Parte 3: Quando la memoria scatta — Trigger e decisioni

La domanda più comune sulla memoria di Hermes Agent riguarda quando essa salvi effettivamente qualcosa.

La risposta è: costantemente, ma selettivamente. L’agente gestisce la propria memoria tramite lo strumento memory, e la decisione di salvare è guidata da una combinazione di segnali espliciti e pattern impliciti.

Trigger di scrittura: Quando decide l’agente di salvare?

L’agente salva la memoria in modo proattivo. Non aspetta che tu glielo chieda. Ecco cosa lo attiva.

Correzioni dell’utente. Quando correggi l’agente, è un segnale che deve ricordare. “Non farlo più.” “Usa questo invece.” “Ricorda questo.” Queste sono istruzioni esplicite per aggiornare la memoria.

Esempio: chiedi all’agente di configurare un ambiente Python. Suggerisce pip. Tu dici “Uso poetry per tutto”. L’agente salva: L'utente preferisce usare il package manager 'poetry' per tutti i progetti Python.

Preferenze scoperte. L’agente osserva i pattern e deduce le preferenze. Se usi costantemente un certo strumento, framework o workflow, questo viene salvato.

Esempio: dopo aver visto che usi poetry più volte in diversi progetti, l’agente lo salva come preferenza.

Fatti sull’ambiente. Cose riguardanti la macchina, il progetto, gli strumenti installati. Vengono scoperti tramite esplorazione e salvati come fatti.

Esempio: l’agente controlla cosa è installato e salva: Questa macchina esegue Ubuntu 22.04, ha Docker e kubectl installati.

Convenzioni di progetto. Come è strutturato il progetto, quali strumenti usa, quali pattern segue. Vengono scoperti tramite ispezione del codice e salvati.

Esempio: Il progetto dell'utente è un microservizio Go in ~/code/gateway che usa gRPC + PostgreSQL.

Workflow complessi completati. Dopo aver completato un compito che ha richiesto più di 5 chiamate agli strumenti, l’agente valuta di salvare l’approccio come una competenza o almeno di annotare cosa ha funzionato.

Anomalie degli strumenti e workaround. Quando l’agente scopre qualcosa di non ovvio su uno strumento, un’API o un sistema — un limite, un workaround, una convenzione — lo salva.

Cosa viene saltato:

• Informazioni banali o ovvie
• Cose facilmente riscopribili
• Dump di dati grezzi
• Effimere specifiche della sessione
• Informazioni già presenti nei file di contesto (SOUL.md, AGENTS.md)

Trigger di lettura: Quando richiama l’agente?

La memoria non viene recuperata — è sempre lì. Ma esistono diversi livelli di accesso.

Inizio sessione (automatico). MEMORY.md e USER.md vengono iniettati nel system prompt. L’agente li ha fin dal primo token. Nessuna query necessaria, nessuna latenza, nessuna chiamata a uno strumento. Questa è la memoria core — sempre attiva.

session_search (su richiesta). Quando l’agente ha bisogno di trovare qualcosa dalle conversazioni passate che non è nella memoria core, usa lo strumento session_search. Questo interroga SQLite (~/.hermes/state.db) con ricerca full-text FTS5 e riassunto tramite Gemini Flash. Usa questo quando la domanda suona come “ne abbiamo parlato prima” piuttosto che “ricorda questo fatto per sempre”.

Esempio: chiedi “Abbiamo discusso di Docker networking la scorsa settimana?”. L’agente cerca nella cronologia della sessione e restituisce un riassunto della conversazione pertinente.

Strumenti dei provider esterni (quando configurati). Quando un provider di memoria esterno è attivo, il framework esegue anche un passaggio di prefetch automatico prima di ogni risposta (vedi Parte 2). Strumenti aggiuntivi come honcho_search, hindsight_recall o mem0_search servono per ricerche mirate quando l’agente sceglie un recupero esplicito — a seconda del recall_mode, l’iniezione automatica, gli strumenti o entrambi possono essere attivi.

L’albero delle decisioni

Ecco come l’agente valuta se “ne vale la pena ricordare?”:

È una correzione o un'istruzione esplicita?
  SÌ → Salva in memoria
  NO → È una preferenza o un pattern?
    SÌ → Salva nel profilo utente
    NO → È un fatto dell'ambiente o una convenzione?
      SÌ → Salva in memoria
      NO → È facilmente riscopribile?
        SÌ → Salta
        NO → È specifico della sessione?
          SÌ → Salta
          NO → Salva in memoria

L’agente non ci pensa troppo. Salva proattivamente, consolida quando è pieno e si affida ai limiti di caratteri per mantenere tutto compatto.

Parte 4: Memoria interna vs Knowledge Base esterne

È qui che spesso nasce la confusione. Hermes Agent ha una memoria interna (MEMORY.md, USER.md, provider esterni) e knowledge base esterne (LLM Wiki, Obsidian, Notion, ArXiv, filesystem), e servono ruoli completamente diversi. Questo è simile alla distinzione tra le pipeline di retrieval-augmented generation e la memoria di lavoro dell’agente — il recupero esterno è buono per ricerche di conoscenza profonda, non per trasportare identità e preferenze. La memoria interna è il cervello dell’agente — sempre attivo, curato, portato in ogni sessione. Le knowledge base esterne sono la sua biblioteca — vaste risorse di riferimento consultate su richiesta.

La distinzione

Memoria Interna (il cervello):

• Piccola, persistente, iniettata nel system prompt
• Contiene: preferenze utente, convenzioni dell’agente, lezioni immediate
• Sempre “in mente” durante la conversazione
• Curata, delimitata, gestita attivamente
• Esempi: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

Knowledge Base Esterne (la biblioteca):

• Vaste, solo di riferimento, accessibili su richiesta
• Contengono: documenti, paper, codice, note, database
• Accessate tramite strumenti quando necessario
• Non vengono “ricordate” — vengono consultate
• Esempi: LLM Wiki, Obsidian, Notion, ArXiv, filesystem, GitHub

Come sono correlate

L’agente accede alle basi esterne tramite strumenti quando necessario. Non le “ricorda” — le consulta.

LLM Wiki (llm-wiki): La base di conoscenza in Markdown interconnessa di Karpathy per costruire e interrogare la conoscenza di dominio. L’agente usa la skill llm-wiki per leggere, cercare e interrogare. È una risorsa di riferimento, non una memoria.

Obsidian: Vault di note personali con link bidirezionali. L’agente usa la skill obsidian per leggere, cercare e creare note. Obsidian fa parte del più ampio ecosistema di personal knowledge management in cui Hermes può attingere come risorsa libraria.

Notion/Airtable: Database strutturati e wiki accessati via API. LL’agente li interroga quando necessario.

ArXiv: Repository di paper accademici. L’agente cerca ed estrae paper quando fa ricerche su un argomento.

Filesystem: Codice del progetto, documentazione, configurazioni. L’agente legge i file quando lavora su un progetto.

Il pattern della distillazione

Ecco l’intuizione chiave: gli insight critici dalle basi esterne possono essere distillati nella memoria interna.

Esempio: l’agente legge un paper da ArXiv sulla memoria scaling per gli agenti AI. Non salva l’intero paper nella memoria. Salva l’insegnamento chiave: Memory scaling: le prestazioni dell'agente migliorano con l'esperienza accumulata attraverso l'interazione con l'utente e il contesto aziendale memorizzato.

La risorsa esterna è vasta. La memoria interna è la distillazione.

Quando usare cosa

Memoria interna per:

• “Chi sto aiutando?”
• “Cosa preferiscono?”
• “Cosa abbiamo appena imparato?”
• “Com’è configurato il progetto?”
• “Quali strumenti sono disponibili?”

Knowledge base esterne per:

• “Qual è l’ultima ricerca su X?”
• “Cosa c’è nella documentazione del mio progetto?”
• “Di cosa abbiamo discusso il mese scorso?”
• “Qual è l’API per questo servizio?”
• “Com’è la struttura del codice?”

L’agente comprende la differenza e usa ciascuna in modo appropriato — non confonde la consultazione di un documento con il ricordo di qualcosa che ha imparato su di te e sul tuo ambiente.

Parte 5: Come funziona effettivamente

Guardiamo la meccanica.

Lo strumento memory

L’agente gestisce la memoria attraverso un singolo strumento con tre azioni: add, replace, remove.

Non esiste un’azione read — il contenuto della memoria viene iniettato automaticamente nel system prompt. L’agente non ha bisogno di leggerlo perché è sempre lì.

add — Aggiunge una nuova voce.

memory(action="add", target="memory",
       content="L'utente usa macOS 14 Sonoma, usa Homebrew, ha Docker Desktop installato.")

replace — Sostituisce una voce esistente utilizzando il matching di sottostringhe.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="L'utente preferisce la light mode in VS Code, la dark mode nel terminale")

remove — Rimuove una voce utilizzando il matching di sottostringhe.

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

Matching di sottostringhe

replace e remove utilizzano brevi sottostringhe univoche tramite old_text. Non è necessario l’intero testo della voce. Questo rende possibili modifiche chirurgiche senza conoscere il contenuto esatto.

Se una sottostringa corrisponde a più voci, viene restituito un errore che richiede un match più specifico. L’agente quindi affina la sua query.

Store target: memory vs user

Il parametro target determina quale file viene aggiornato.

• memory — Note personali dell’agente. Fatti sull’ambiente, convenzioni di progetto, anomalie degli strumenti, lezioni apprese.
• user — Profilo utente. Identità, ruolo, fuso orario, preferenze di comunicazione, fastidi, abitudini di workflow.

Gestione della capacità

Quando la memoria è >80% piena, l’agente consolida. Unisce voci correlate, rimuove fatti obsoleti e comprime le informazioni.

Le buone voci di memoria sono compatte e dense di informazioni:

L'utente usa macOS 14 Sonoma, usa Homebrew, ha Docker Desktop installato. Shell: zsh con oh-my-zsh. Editor: Neovim con plugin Telescope.

Le cattive voci di memoria sono vaghe o verboragiche:

L'utente ha un progetto.
Il 5 gennaio 2026, l'utente mi ha chiesto di guardare il suo progetto che si trova in ~/code/gateway e usa Go con gRPC e PostgreSQL per lo strato del database.

La prima è densa e utile. La seconda è o troppo vaga o troppo verbosa.

Session Search vs Memoria Persistente

session_search e la memoria persistente servono a scopi diversi.

Regola generale: usa la memoria per i fatti critici che dovrebbero essere sempre nel contesto. Usa la session search per ricerche storiche.

Parte 6: La filosofia

Perché la memoria delimitata batte la memoria illimitata

L’istinto è quello di rendere la memoria il più grande possibile. Memorizzare tutto. Recuperare ciò che serve.

La memoria delimitata funziona meglio. Ecco perché.

La curatela impone la qualità. Quando hai spazio limitato, salvi solo ciò che conta. Comprimi, consolidi e dai priorità. La memoria illimitata incoraggia l’inserire tutto senza mai pulire.

La velocità conta. 1.300 token nel system prompt sono veloci. 100.000 token recuperati da un database sono lenti. La memoria dovrebbe essere istantanea, non una query.

Il rumore degrada le prestazioni. Più memoria non significa memoria migliore. Significa memoria più rumorosa. Il modello deve distinguere il segnale dal rumore, e questo richiede attenzione — un’attenzione che dovrebbe essere dedicata al compito effettivo.

Dimenticare è una funzionalità. La memoria umana dimentica. Non è un bug — è il modo in cui diamo priorità. Anche gli agenti dovrebbero dimenticare. Non tutto merita di essere ricordato.

Il problema del “Dimenticare”

Gli agenti devono disimparare. Non solo dimenticare, ma rimuovere attivamente le informazioni obsolete.

Ecco come Hermes Agent lo gestisce:

• Azione remove: Elimina le voci che non sono più rilevanti.
• Azione replace: Aggiorna le voci con nuove informazioni.
• Pressione della capacità: Quando la memoria è piena, l’agente consolida e rimuove le vecchie voci.
• Scansione di sicurezza: Blocca voci malevole o corrotte.

Dimenticare non è un fallimento — è manutenzione. Un agente che non può disimparare porterà alla fine tanto rumore quanto segnale.

Memory Scaling

Databricks ha introdotto il concetto di “memory scaling”: un agente con migliaia di utenti si comporta meglio di uno con un singolo utente?

La loro ricerca suggerisce di sì, ma con riserve. Il memory scaling richiede:

1. Estrazione di qualità: Non tutte le interazioni valgono la pena di essere ricordate. L’agente deve estrarre insight, non log.
2. Recupero efficace: Le memorie recuperate devono essere rilevanti. Il rumore degrada le prestazioni.
3. Generalizzazione: Le memorie dovrebbero essere pattern, non specificità. “L’utente preferisce Python” scala. “L’utente ha eseguito il comando X al timestamp Y” no.

La memoria delimitata di Hermes Agent supporta naturalmente il memory scaling. Forzando la curatela, assicura che le memorie siano generalizzabili, compatte e utili.

Cosa significa per il futuro

La memoria sta diventando il vantaggio competitivo nell’AI agentica — non il modello stesso, ma ciò che il modello trasporta tra le sessioni. Due agenti con modelli sottostanti identici possono comportarsi in modo molto diverso: uno ricorda le tue preferenze, il tuo ambiente e i tuoi errori passati; l’altro ricomincia da zero ogni volta.

La domanda non è più se gli agenti debbano avere una memoria persistente. È risolto: devono. La domanda aperta è come progettare bene quella memoria — cosa tenere, cosa scartare, come renderla istantanea e come evitare che diventi rumore.

La risposta di Hermes Agent è mantenere la memoria piccola, curata e sempre attiva — non un database da interrogare, ma un modello di lavoro dell’utente che l’agente porta con sé in ogni conversazione.

Conclusione

Il sistema di memoria di Hermes Agent è deliberatamente semplice: due file, limiti di caratteri rigorosi, nessuna pipeline di recupero, nessun vector database e nessuna latenza per query. Quello che sembra un limite è proprio il punto centrale.

Funziona perché tratta la memoria come funziona un cervello piuttosto che come funziona un database — piccola, curata e sempre attiva. L’agente non recupera la memoria quando ne ha bisogno; la memoria è semplicemente sempre lì, tessuta nel system prompt fin dal primo token di ogni sessione.

I provider di memoria esterni estendono questo sistema per gli utenti che necessitano di più: knowledge graph, supporto multi-agente, storage self-hosted, funzionalità enterprise. Ma il nucleo rimane lo stesso: delimitato, curato, sempre disponibile.

E le knowledge base esterne — LLM Wiki, Obsidian, Notion, ArXiv — servono un ruolo diverso. Sono la biblioteca, non il cervello. LL’agente le consulta, non le ricorda. Gli insight critici vengono distillati nella memoria interna; il resto rimane nella biblioteca.

È così che un agente AI ti ricorda. Non memorizzando tutto, ma ricordando ciò che conta.

Hermes Agent è stato rilasciato da Nous Research nel febbraio 2026 e ha raggiunto oltre 64.000 stelle su GitHub nell’aprile 2026 (v0.9.0), con oltre 242 contributori. È open-source ed è disponibile su github.com/NousResearch/hermes-agent. Per guide su installazione, configurazione e workflow, consulta la Hermes Agent overview.