Sistema di Memoria dell'Agente Hermes: Come Funziona Veramente la Memoria AI Persistente

Conosci bene la routine. Apri una chat con un agente AI, spieghi il tuo progetto, condividi le tue preferenze, fai svolgere un po’ di lavoro e chiudi la scheda. Torni la settimana successiva ed è come parlare con uno sconosciuto: tutto il contesto è sparito, ogni preferenza dimenticata, il progetto da spiegare di nuovo da zero.

Non è un bug. È il modo in cui i Large Language Model (LLM) funzionano per progettazione. Sono stateless: ogni richiesta è indipendente, ogni risposta viene generata in base al prompt che invii in quel preciso momento, senza memoria, senza storia e senza continuità al di fuori dei token presenti nella finestra di contesto corrente.

Per interazioni a turno singolo, va bene così. Fai una domanda, ottieni una risposta, passi oltre. Ma per gli agenti — sistemi che dovrebbero fare cose tra una sessione e l’altra, imparare dagli errori ed evolversi con te — l’assenza di stato è un limite architetturale duro. È uno dei problemi centrali ancora irrisolti nei sistemi AI self-hosted.

Il settore ha provato a risolvere questo problema. LangChain ha aggiunto moduli di memoria. OpenAI ha introdotto assistenti con thread. Framework come Letta, Zep e Cognee hanno costruito intere architetture attorno alla memoria persistente. Databricks ha pubblicato ricerche sullo “scaling della memoria” — l’idea che le prestazioni dell’agente migliorino con l’esperienza accumulata. Dal 2024 sono emersi paper di benchmark dedicati, 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 nell’AI agentic.

La maggior parte di questi approcci condivide un problema comune: trattano la memoria come un afterthought — 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. È sufficientemente piccola per essere veloce, sufficientemente strutturata per essere utile e sufficientemente disciplinata per sapere cosa dimenticare.

Questo articolo spiega esattamente come funziona — lo strato specifico di Hermes all’interno del modello cross-framework in Sistemi di memoria negli assistenti AI e lo stack più ampio in Architettura degli assistenti AI. Per i comandi di attivazione e ispezione (hermes memory, hermes dump, log tailing), abbinateli alla scheda di riferimento CLI di Hermes Agent. Per il lato complementare della “conoscenza a lungo termine” di Hermes — procedure riutilizzabili in SKILL.md piuttosto che file di memoria curati — consulta Autore di Skill Hermes Agent — Struttura di SKILL.md e Best Practices.

Parte 1: Il problema della memoria degli agenti AI

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

La soluzione ovvia all’AI stateless è aggiungere contesto. Allega la conversazione precedente. Includi la documentazione del progetto. Invia l’intera cronologia.

Per un po’, funziona. Hai una finestra di contesto da 128K. Puoi infarci molto testo.

Ma il contesto non è 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 mantieni attivamente e porti con te.

Il contesto non ha curation. È un dump: man mano che cresce, il modello deve elaborare migliaia di token di cronologia irrilevante per trovare l’unico fatto di cui ha bisogno. Questo costa token e soldi, aumenta la latenza e alla fine tocca il soffitto.

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

La memoria umana funziona allo stesso modo. Non ricordi ogni conversazione che hai mai avuto. Ricordi le parti che contano: con chi stai parlando, cosa gli importa, su cosa siete d’accordo, cosa hai imparato. Il resto viene dimenticato o è ricercabile quando ne hai bisogno.

Il panorama della ricerca

Lo spazio della memoria degli agenti AI è esploso dal 2024, con suite di benchmark dedicate, una letteratura di ricerca in crescita e un divario prestazionale misurabile tra diversi approcci architetturali. Ecco dove siamo arrivati.

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

Zep / Graphiti si concentra sulla memoria conversazionale con il tracciamento delle entità temporali — i fatti hanno finestre di validità in modo che il grafo sappia quando qualcosa era vero. È forte per i chatbot che necessitano di grafi relazionali, meno adatto per agenti autonomi che tracciano fatti ambientali 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 a grafo di conoscenza. Eccelle nella conoscenza istituzionale e nelle pipeline RAG ma è meno focalizzato sulla memoria personale dell’agente. Consulta Self-hosting di Cognee con LLM locali per una guida pratica alla configurazione.

Hindsight effettua il richiamo basato su grafi di conoscenza con relazioni tra entità e uno strumento di sintesi reflect unico che esegue la sintesi cross-memoria — combinando più memorie in nuove intuizioni. Si posiziona tra i migliori nelle benchmark di 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 a ECAI 2025 (arXiv:2504.19413), ha benchmarkato dieci approcci distinti alla memoria AI e ha validato l’approccio di estrazione selettiva — memorizzare fatti discreti, deduplicare e recuperare solo ciò che è rilevante. Mem0 è cresciuto fino a circa 48K stelle su GitHub e supporta 21 integrazioni con framework. Il compromesso è la dipendenza dal cloud e il costo.

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

Il filo conduttore tra la maggior parte dei framework è che trattano la memoria come un problema di recupero: memorizzarla da qualche parte, interrogarla quando necessario, iniettarla 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 — strati e richiamo/archiviazione per turno prima, poi cosa risiede in MEMORY.md e USER.md, infine come collegare un provider esterno.

Due strati

Hermes impila la memoria in due strati:

1. Integrato — MEMORY.md e USER.md, supportati da file, sempre attivi. Limiti rigidi 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 altri che abiliti tramite configurazione. Solo uno backend esterno è attivo alla volta. Aggiunge recupero e retention accanto ai file; non li sostituisce.

Il modello mentale è additivo — file di base congelati più al massimo un plugin. I ganci di prefetch e sync orchestnano lo strato esterno; i due file restano iniettati separatamente come parte del system prompt congelato.

Flusso di runtime (prefetch e sync)

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

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

I file integrati MEMORY.md e USER.md non vengono recuperati tramite prefetch_all — sono già parte del system prompt congelato. I backend esterni si collegano a prefetch_all / sync_all; queue_prefetch permette a un provider di preriscaldare 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 dicono che qualcosa deve persistere — fatti duraturi, preferenze, correzioni, note sull’ambiente. target='user' mantiene USER.md; target='memory' mantiene MEMORY.md. Forma di esempio: memory(action='add', target='user', content='…').

2. Retention passiva sui provider esterni. Ad ogni turno il framework invoca il percorso di sync del provider in modo che la conversazione possa essere chunkata, riassunta o estratta senza che il modello nomini ogni fatto. Il comportamento varia per backend — ad esempio Hindsight raggruppa i turni ed esegue la retention strutturata con entità e relazioni; Honcho invia il dialogo attraverso la sua pipeline dialettica; stack stile Mem0 e Supermemory estraggono fatti passivamente dai turni.

3. Strumenti specifici del provider. Quando il plugin li espone, scritture esplicite come honcho_conclude, hindsight_retain o honcho_profile archiviano slice duraturi su richiesta.

Richiamo automatico versus strumenti del provider

La memoria principale non ha bisogno di uno strumento di lettura — è già nel prompt. I backend esterni aggiungono o l’iniezione automatica dal prefetch (nessuna chiamata di strumento di richiamo separata per quella porzione 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 nella configurazione) 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 di memoria persistente: due file, meno di 3.600 caratteri totali, meno di 1.300 token. Sembra deliberatamente piccola perché lo è — e questa è esattamente l’intenzione di design.

MEMORY.md: Le note dell’agente

Questo è dove l’agente memorizza tutto ciò che impara sul suo 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 installati Docker e kubectl
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase

Questi non sono log. Sono fatti. Densi, dichiarativi, ricchi di informazioni. Nessuna data, nessun riempitivo, nessun “il 5 gennaio l’utente mi ha chiesto di…”

USER.md: Il profilo utente

Questo è dove l’agente memorizza tutto ciò che sa di te.

L'utente è uno sviluppatore full-stack a suo agio con TypeScript, Go e Python.
L'utente preferisce snake_case per i nomi delle variabili ed evita camelCase.
L'utente utilizza principalmente Linux Ubuntu 22.04.
L'utente deploya su AWS usando Terraform.

Identità, ruolo, preferenze, competenze tecniche, stile di comunicazione, fissazioni. Le cose che fanno sì che l’agente risponda diversamente a te rispetto a qualsiasi altra persona.

Il pattern dello snapshot congelato

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

══════════════════════════════════════════════
MEMORIA (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 installati Docker e kubectl
§
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 a suo agio con 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 multilinea. È progettato per essere parsabile dal modello rimanendo leggibile dall’uomo.

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ò cacheare il calcolo del prefisso ed elaborare solo le parti variabili — la conversazione. Questa è un’ottimizzazione prestazionale significativa. Non stai ricalcolando l’attenzione sugli stessi token di memoria ad ogni turno.

Le modifiche effettuate durante una sessione persistono sul disco immediatamente, 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. Questo impedisce al modello di inseguire la propria coda — aggiornare la memoria e poi reagire al proprio aggiornamento nella stessa conversazione.

Limiti di caratteri come funzionalità

2.200 caratteri. 1.375 caratteri. Non sono limiti arbitrari. Sono vincoli di design che impongono la curation.

La memoria illimitata è un passivo. Incoraggia a scaricare tutto, a non consolidare mai e, alla fine, a diventare rumore. La memoria delimitata costringe l’agente a essere selettivo. Cosa è davvero importante? Cosa avrò bisogno di nuovo? Cosa può essere compresso senza perdere significato?

Quando la memoria è piena, l’agente non fallisce silenziosamente. Riceve un errore con le voci correnti e l’utilizzo, poi segue un workflow:

1. Leggere le voci correnti dalla risposta di errore
2. Identificare le voci rimovibili o consolidabili
3. Usare replace per unire voci correlate in versioni più brevi
4. Aggiungere la nuova voce

È così che la memoria rimane utile. Non è un database. È una collezione curata di fatti importanti.

Sicurezza: Scansione per iniezioni di prompt

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

La memoria è anche deduplicata. Le voci duplicate esatte vengono rifiutate automaticamente. Questo impedisce agli avversari di provare a iniettare contenuti maligni attraverso submissions ripetute.

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 conoscenza persistente tra le sessioni. Solo un provider esterno è attivo alla volta; i due file di base rimangono caricati accanto ad esso (additivo, non sostituzione).

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 cablaggio interattivo.

Forma YAML minima solo integrata:

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 di confronto completa, note sulle dipendenze LLM e di embedding, dettagli per provider e come questi backend si relazionano con OpenClaw e altri stack, consulta Provider di memoria per agenti confrontati.

Per il cablaggio specifico del profilo e i workflow di produzione, consulta Configurazione di produzione di Hermes Agent. Il Hub di memoria dei sistemi AI elenca questa guida insieme agli articoli correlati su Cognee e strati di conoscenza.

Parte 3: Quando la memoria si attiva — Trigger e decisioni

La domanda più comune sulla memoria di Hermes Agent è quando salva 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 innesca.

Correzioni dell’utente. Quando correggi l’agente, è un segnale per ricordare. “Non farlo di nuovo.” “Usa questo invece.” “Ricorda questo.” 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 utilizzare il gestore pacchetti 'poetry' per tutti i progetti Python.

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

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

Fatti ambientali. Cose sulla macchina, sul progetto, sugli strumenti installati. Questi vengono scoperti attraverso l’esplorazione e salvati come fatti.

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

Convenzioni del progetto. Come è strutturato il progetto, quali strumenti usa, quali pattern segue. Questi vengono scoperti attraverso l’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 5+ chiamate agli strumenti, l’agente considera salvare l’approccio come skill o almeno annotare cosa ha funzionato.

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

Cosa viene saltato:

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

Trigger di lettura: Quando l’agente richiama?

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

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

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

Esempio: chiedi “Abbiamo discusso della rete Docker la scorsa settimana?” L’agente cerca nella cronologia delle sessioni e restituisce un riassunto della conversazione rilevante.

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

L’albero decisionale

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

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

L’agente non ci pensa troppo. Salva in modo proattivo, consolida quando è pieno e si fida dei limiti di caratteri per mantenere le cose strette.

Parte 4: Memoria interna versus basi di conoscenza esterne

Qui spesso nasce la confusione. Hermes Agent ha memoria interna (MEMORY.md, USER.md, provider esterni) e basi di conoscenza esterne (LLM Wiki, Obsidian, Notion, ArXiv, filesystem) e servono ruoli completamente diversi. È simile alla distinzione tra pipeline retrieval-augmented generation e memoria di lavoro dell’agente — il recupero esterno è buono per ricerche di conoscenza profonda, non per portare identità e preferenze. La memoria interna è il cervello dell’agente — sempre attiva, curata, portata in ogni sessione. Le basi di conoscenza 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

Basi di Conoscenza Esterne (la biblioteca):

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

Come si relazionano

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

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

Obsidian: Vault di note personali con link bidirezionali. L’agente usa la skill obsidian per leggere, cercare e creare note. Obsidian fa parte dell’ecosistema più ampio di gestione della conoscenza personale che Hermes può sfruttare come risorsa di biblioteca.

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

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

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

Il pattern di distillazione

Ecco l’intuizione chiave: le intuizioni critiche dalle basi esterne possono essere distillate nella memoria interna.

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

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

Quando usare cosa

Memoria interna per:

• “Chi sto aiutando?”
• “Cosa preferiscono?”
• “Cosa abbiamo appena imparato?”
• “Qual è la configurazione del progetto?”
• “Quali strumenti sono disponibili?”

Basi di conoscenza esterne per:

• “Quali sono le ultime ricerche su X?”
• “Cosa c’è nella documentazione del mio progetto?”
• “Di cosa abbiamo discusso il mese scorso?”
• “Qual è l’API per questo servizio?”
• “Qual è la struttura del codice?”

L’agente capisce la differenza e usa ciascuno appropriatamente — non confonde cercare un documento con ricordare qualcosa che ha imparato su di te e sul tuo ambiente.

Parte 5: Come funziona realmente

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 auto-iniettato 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 esegue macOS 14 Sonoma, usa Homebrew, ha Docker Desktop installato.")

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

memory(action="replace", target="memory",
       old_text="modalità scura",
       content="L'utente preferisce la modalità chiara in VS Code, modalità scura nel terminale")

remove — Rimuove una voce usando il matching di sottostringhe.

memory(action="remove", target="memory",
       old_text="fatto temporaneo del progetto")

Matching di sottostringhe

replace e remove usano sottostringhe brevi e uniche tramite old_text. Non hai bisogno del testo completo 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 raffina quindi la sua query.

Archivi Target: memory versus user

Il parametro target determina quale file viene aggiornato.

• memory — Note personali dell’agente. Fatti ambientali, convenzioni del progetto, particolarità degli strumenti, lezioni apprese.
• user — Profilo utente. Identità, ruolo, fuso orario, preferenze di comunicazione, fissazioni, abitudini di workflow.

Gestione della capacità

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

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

L'utente esegue 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 verbose:

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 database.

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

Ricerca di sessione versus memoria persistente

session_search e memoria persistente servono scopi diversi.

Regola pratica: usa la memoria per fatti critici che dovrebbero essere sempre nel contesto. Usa la ricerca di sessione per lookup storici.

Parte 6: La filosofia

Perché la memoria delimitata batte la memoria illimitata

L’istinto è rendere la memoria il più grande possibile. Memorizzare tutto. Recuperare ciò di cui hai bisogno.

La memoria delimitata funziona meglio. Ecco perché.

La curation forza la qualità. Quando hai spazio limitato, salvi solo ciò che conta. Comprimi, consolidi e dai priorità. La memoria illimitata incoraggia a scaricare tutto e a non pulire mai.

La velocità conta. 1.300 token nel system prompt è veloce. 100.000 token recuperati da un database è lento. La memoria dovrebbe essere istantanea, non una query.

Il rumore degrada le prestazioni. Più memoria non è memoria migliore. È memoria più rumorosa. Il modello deve distinguere il segnale dal rumore, e questo richiede attenzione — attenzione che dovrebbe essere spesa sul compito reale.

Dimenticare è una funzionalità. La memoria umana dimentica. Non è un bug — è come prioritizziamo. Gli agenti dovrebbero dimenticare anche loro. Non tutto merita di essere ricordato.

Il problema del “dimenticare”

Gli agenti hanno bisogno di disimparare. Non solo dimenticare, ma rimuovere attivamente informazioni obsolete.

Ecco come Hermes Agent lo gestisce:

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

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

Scaling della memoria

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

La loro ricerca suggerisce di sì, ma con caveat. Lo scaling della memoria richiede:

1. Estrazione di qualità: Non tutte le interazioni valgono la pena di essere ricordate. L’agente deve estrarre intuizioni, 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 lo scaling della memoria. Forzando la curation, assicura che le memorie siano generalizzabili, compatte e utili.

Cosa significa per il futuro

La memoria sta diventando il fossato competitivo nell’AI agentic — non il modello stesso, ma cosa il modello porta tra una sessione e l’altra. Due agenti con modelli sottostanti identici possono performare molto diversamente: uno ricorda le tue preferenze, il tuo ambiente e i tuoi errori passati; l’altro parte freddo ogni volta.

La domanda non è più se gli agenti dovrebbero avere memoria persistente. È risolta: devono. La domanda aperta è come progettare quella memoria bene — cosa tenere, cosa scartare, come renderla istantanea e come impedire 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 rigidi, nessuna pipeline di recupero, nessun vector database e nessuna latenza per query. Ciò che suona come un vincolo è il punto principale.

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ì, intrecciata nel system prompt dal primo token di ogni sessione.

I provider di memoria esterni estendono questo sistema per gli utenti che ne hanno bisogno: grafi di conoscenza, supporto multi-agente, archiviazione self-hosted, funzionalità enterprise. Ma il nucleo rimane lo stesso: delimitato, curato, sempre disponibile.

E le basi di conoscenza esterne — LLM Wiki, Obsidian, Notion, ArXiv — servono un ruolo diverso. Sono la biblioteca, non il cervello. L’agente le cerca, non le ricorda. Le intuizioni critiche vengono distillate nella memoria interna; il resto rimane nella biblioteca.

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

Hermes Agent è stato rilasciato da Nous Research a febbraio 2026 e ha superato le 64.000 stelle su GitHub ad aprile 2026 (v0.9.0), con oltre 242 contributori. È open-source e disponibile su github.com/NousResearch/hermes-agent. Per installazione, configurazione e guide ai workflow, consulta l’overview di Hermes Agent.