Sistema di Memoria per Agenti Hermes: Come Funziona Effettivamente la Memoria Persistente dell'IA

Lo sai come funziona. 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 è svanito, ogni preferenza è stata dimenticata, il progetto deve essere spiegato da zero.

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

Per interazioni singole (single-turn), va bene così. Fai una domanda, ottieni una risposta, passi oltre. Ma per gli agenti — sistemi che dovrebbero eseguire azioni tra diverse sessioni, imparare dagli errori ed evolversi con te — l’assenza di stato è un limite architetturale insormontabile. È uno dei problemi centrali ancora irrisolti nei sistemi AI auto-ospitati.

Il settore ha cercato di 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 sul “memory scaling” — l’idea che le prestazioni degli agenti migliorino con l’esperienza accumulata. Dal 2024 sono emersi paper dedicati ai benchmark, survey sulla memoria episodica e un ecosistema di strumenti in rapida crescita per affrontare quello 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 ripensamento — un database da interrogare, una finestra di contesto da intasare, un sistema di recupero che aggiunge latenza e rumore anziché 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 prompt di sistema, 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 degli agenti AI

Perché “aggiungere solo contesto” non è scalabile 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 inserirci 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 cura. È un dump: man mano che cresce, il modello deve elaborare migliaia di token di storia irrilevante per trovare l’unico fatto di cui ha bisogno. Questo costa token e denaro, 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 importanti: con chi stai parlando, cosa gli interessa, su cosa siete d’accordo, cosa hai imparato. Il resto è o dimenticato o ricercabile quando ne hai bisogno.

Il panorama della ricerca

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

Letta (ex 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 di base (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 tracking 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 relazionali, meno adatto per agenti autonomi che tracciano fatti ambientali e convenzioni di progetto.

Cognee è progettato 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. Vedi auto-ospitare 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-memory — combinando più memorie in nuove intuizioni. È uno dei migliori performer nei 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 — memorizzando fatti discreti, deduplicando e recuperando 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 di Databricks sul memory scaling ha introdotto il concetto che le prestazioni degli agenti migliorano con l’esperienza accumulata. La loro architettura mantiene prompt di sistema, asset aziendali e memorie episodiche/semantiche scopeate a livello di organizzazione e utente, validando l’idea che la qualità della memoria sia importante quanto le capacità del modello.

Il filo conduttore attraverso 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 on-demand, viene iniettata all’inizio della sessione ed è sempre presente. Sempre attiva, sempre disponibile, curata abbastanza da rimanere utile.

Parte 2: Architettura — Due file, un cervello

Il sistema di memoria integrato di Hermes Agent vive 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 in totale, meno di 1.300 token. Sembra deliberatamente piccola perché lo è — ed è esattamente l’intento progettuale.

MEMORY.md: Le note dell’agente

Qui è 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 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. Nessuna marca temporale, nessun superfluo, niente “il 5 gennaio l’utente mi ha chiesto di…”

USER.md: Il profilo utente

Qui è dove l’agente memorizza tutto ciò che sa 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 utilizza principalmente Linux Ubuntu 22.04.
L'utente effettua il deploy su AWS usando Terraform.

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

Il pattern del snapshot congelato

All’inizio della sessione, entrambi i file vengono caricati dal disco e iniettati come un blocco congelato nel prompt di sistema. 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 multilinea. È progettato per essere analizzabile dal modello rimanendo leggibile dall'uomo.

Perché congelato? [Caching dei prefissi](https://www.glukhov.org/it/llm-performance/). Il prompt di sistema è 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 apportate durante una sessione persistono sul disco immediatamente, ma appaiono nel prompt di sistema 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 — aggiornando la memoria e reagendo al proprio aggiornamento nella stessa conversazione.

### Limiti di caratteri come funzionalità

2.200 caratteri. 1.375 caratteri. Questi non sono limiti arbitrari. Sono vincoli progettuali che impongono la cura.

La memoria illimitata è un passivo. Incoraggia a scaricarsi tutto, a non consolidare mai e a diventare infine 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 flusso di lavoro:

1. Leggi le voci correnti dalla risposta di errore
2. Identifica le voci rimuovibili o consolidabili
3. Usa `replace` per unire voci correlate in versioni più brevi
4. Aggiungi 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 i tentativi di iniezione di prompt, l'estrazione di credenziali, le backdoor SSH e i caratteri Unicode invisibili.

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

---

## 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 l'agente decide di salvare?

L'agente salva la memoria proattivamente. Non aspetta che tu glielo chieda. Ecco cosa lo attiva.

**Correzioni dell'utente.** Quando correggi l'agente, è un segnale per 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 gestore pacchetti 'poetry' per tutti i progetti Python.`

**Preferenze scoperte.** L'agente osserva i pattern e inferisce le preferenze. Se utilizzi costantemente un certo strumento, framework o flusso di lavoro, viene salvato.

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

**Fatti ambientali.** Cose sulla macchina, il progetto, gli 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 Docker e kubectl installati.`

**Convenzioni di 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.`

**Flussi di lavoro complessi completati.** Dopo aver completato un compito che ha richiesto 5+ chiamate agli strumenti, l'agente considera salvare l'approccio come abilità 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
- Effimera specifica 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 prompt di sistema. L'agente li ha dal primo token. Nessuna query necessaria, nessuna latenza, nessuna chiamata allo strumento. Questa è la memoria di base — sempre attiva.

**`session_search` (on-demand).** Quando l'agente ha bisogno di trovare qualcosa dalle conversazioni passate che non è nella memoria di base, usa lo strumento `session_search`. Questo interroga SQLite (`~/.hermes/state.db`) con ricerca full-text FTS5 e riassunto Gemini Flash.

Esempio: chiedi "Abbiamo discusso del networking Docker la scorsa settimana?" L'agente cerca nella cronologia delle sessioni e restituisce un riassunto della conversazione rilevante.

**Strumenti dei provider esterni (quando configurati).** Quando un provider di memoria esterno è attivo, l'agente ha strumenti aggiuntivi disponibili: `honcho_search`, `hindsight_recall`, `mem0_search`, ecc. Questi vengono usati quando l'agente determina che è necessario un contesto esterno.

### 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 proattivamente, consolida quando è pieno e si affida ai limiti di caratteri per mantenere le cose strette.

---

## Parte 4: Memoria interna vs. 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. Questo è simile alla distinzione tra pipeline di [generazione potenziata dal recupero](https://www.glukhov.org/it/rag/) e memoria di lavoro dell'agente — il recupero esterno è buono per ricerche di conoscenza approfondite, non per trasportare 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 on-demand.

### La distinzione

**Memoria interna (il cervello):**

- Piccola, persistente, iniettata nel prompt di sistema
- 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 on-demand
- Contengono: documenti, paper, codice, note, database
- Accessibili tramite strumenti quando necessario
- Non "ricordate" — cercate
- 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):** La base di conoscenza Markdown interconnessa di Karpathy per costruire e interrogare conoscenza di dominio. L'agente usa l'abilità `llm-wiki` per leggere, cercare e interrogarla. È una risorsa di riferimento, non memoria.

**[Obsidian](https://www.glukhov.org/it/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Vault di note personali con link bidirezionali. L'agente usa l'abilità `obsidian` per leggere, cercare e creare note. Obsidian fa parte del più ampio ecosistema di [gestione della conoscenza personale](https://www.glukhov.org/it/knowledge-management/) che Hermes può utilizzare come risorsa bibliotecaria.

**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 sul memory scaling per agenti AI. Non salva l'intero paper nella memoria. Salva il takeaway chiave: `Memory scaling: le prestazioni degli agenti migliorano con l'esperienza accumulata attraverso l'interazione utente e il contesto aziendale memorizzato.`

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

### Quando usare quale

**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?"
- "Cosa abbiamo discusso il mese scorso?"
- "Qual è l'API per questo servizio?"
- "Qual è la struttura del codice?"

L'agente comprende la differenza e usa ciascuno appropriatamente — non confonde il cercare un documento con il 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 prompt di sistema. L'agente non ha bisogno di leggerla perché è sempre lì.

**`add`** — Aggiunge una nuova voce.

```python
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="dark mode",
       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 brevi sottostringhe 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 affina poi la sua query.

Archivi target: memory vs user

Il parametro target determina quale file viene aggiornato.

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

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 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 verbos:

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 di 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 scopi diversi.

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

Parte 6: Provider di memoria esterni — Tutti gli 8 opzioni confrontati

Oltre ai built-in MEMORY.md e USER.md, Hermes Agent supporta 8 plugin provider di memoria esterna per conoscenza persistente cross-session.

Solo un provider esterno può essere attivo alla volta. I file built-in sono sempre attivi insieme al provider esterno — additivi, non di sostituzione.

Attivazione

hermes memory setup   # Selettore interattivo + configurazione
hermes memory status  # Controlla cosa è attivo
hermes memory off     # Disabilita provider esterno

O manualmente in ~/.hermes/config.yaml:

memory:
  provider: openviking  # o honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Confronto dei provider

Analisi dettagliata

Honcho

Ideale per: sistemi multi-agente, contesto cross-session, allineamento utente-agente.

Honcho gira accanto alla memoria esistente — USER.md rimane così com’è, e Honcho aggiunge un ulteriore strato di contesto. Modella le conversazioni come pari che scambiano messaggi — un peer utente più un peer AI per profilo Hermes, tutti condividono un workspace.

Strumenti: honcho_profile (leggi/aggiorna scheda peer), honcho_search (ricerca semantica), honcho_context (contesto sessione — riassunto, rappresentazione, scheda, messaggi), honcho_reasoning (sintetizzato da LLM), honcho_conclude (crea/elimina conclusioni).

Knob di configurazione chiave:

• contextCadence (default 1): Turni minimi tra refresh dello strato base
• dialecticCadence (default 2): Turni minimi tra chiamate LLM peer.chat() (raccomandati 1-5)
• dialecticDepth (default 1): Passaggi .chat() per invocazione (limitati 1-3)
• recallMode (default ‘hybrid’): hybrid (auto+strumenti), context (solo iniezione), tools (solo strumenti)
• writeFrequency (default ‘async’): Timing del flush: async, turn, session, o intero N
• observationMode (default ‘directional’): directional (tutto acceso) o unified (pool condiviso)

Architettura: Iniezione di contesto a due livelli — strato base (riassunto sessione + rappresentazione + scheda peer) + supplemento dialettico (ragionamento LLM). Seleziona automaticamente prompt cold-start vs warm.

Mappatura multi-peer: Il workspace è un ambiente condiviso tra profili. Il peer utente (peerName) è un’identità umana globale. Il peer AI (aiPeer) è uno per profilo Hermes (hermes default, hermes.<profile> per altri).

Setup:

hermes memory setup  # seleziona "honcho"
# o legacy: hermes honcho setup

Config: $HERMES_HOME/honcho.json (locale al profilo) o ~/.honcho/config.json (globale).

Gestione profili:

hermes profile create coder --clone  # Crea hermes.coder con workspace condiviso
hermes honcho sync                   # Backfill peer AI per profili esistenti

OpenViking

Ideale per: gestione della conoscenza self-hosted con browsing strutturato.

OpenViking fornisce una gerarchia di filesystem con caricamento a livelli. È gratuito, self-hosted, e ti dà il controllo completo sulla tua archiviazione della memoria.

Strumenti: viking_search, viking_read (a livelli), viking_browse, viking_remember, viking_add_resource.

Setup:

pip install openviking
openviking-server
hermes memory setup  # seleziona "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Ideale per: gestione della memoria hands-off con estrazione automatica.

Mem0 gestisce l’estrazione della memoria lato server. Non devi configurare nulla — funziona semplicemente. Compromesso: dipendenza dal cloud e costo.

Strumenti: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # seleziona "mem0"
echo "MEM0_API_KEY=la-tua-key" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Ideale per: richiamo basato su grafi di conoscenza con relazioni tra entità.

Hindsight costruisce un grafo di conoscenza della tua memoria, estraendo entità e relazioni. Il suo strumento reflect unico esegue la sintesi cross-memory — combinando più memorie in nuove intuizioni.

Strumenti: hindsight_retain, hindsight_recall, hindsight_reflect (sintesi cross-memory unica).

Setup:

hermes memory setup  # seleziona "hindsight"
echo "HINDSIGHT_API_KEY=la-tua-key" >> ~/.hermes/.env

Auto-installazione hindsight-client (cloud) o hindsight-all (locale). Richiede >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud o local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (default)

UI Locale: hindsight-embed -p hermes ui start

Holographic

Ideale per: setup focalizzati sulla privacy con archiviazione solo locale.

Holographic usa l’algebra HRR (Holographic Reduced Representation) per l’encoding della memoria, con punteggio di fiducia per l’affidabilità della memoria. Nessuna dipendenza dal cloud — tutto gira localmente sul tuo hardware.

Strumenti: 2 strumenti per operazioni di memoria tramite algebra HRR.

Setup:

hermes memory setup  # seleziona "holographic"

Nessuna dipendenza. Tutto gira localmente.

RetainDB

Ideale per: aggiornamenti ad alta frequenza con compressione delta.

RetainDB usa la compressione delta per memorizzare efficientemente gli aggiornamenti della memoria. È basato su cloud con un costo di $20/mese, ma la compressione significa meno trasferimento dati e aggiornamenti più veloci.

Strumenti: retaindb_profile (profilo utente), retaindb_search (ricerca semantica), retaindb_context (contesto rilevante per il compito), retaindb_remember (memorizza con tipo + importanza), retaindb_forget (elimina memorie).

Setup:

hermes memory setup  # seleziona "retaindb"

ByteRover

Ideale per: ambienti con larghezza di banda limitata con estrazione pre-compressione.

ByteRover comprime la memoria prima dell’estrazione, riducendo l’utilizzo della larghezza di banda. Disponibile in modalità locale o cloud.

Strumenti: 3 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "byterover"

Supermemory

Ideale per: flussi di lavoro enterprise con fencing contestuale e ingestione grafo di sessione.

Supermemory fornisce fencing contestuale (isolamento della memoria per contesto) e ingestione grafo di sessione (importazione di intere cronologie delle conversazioni). È basato su cloud e a pagamento, ma progettato per la gestione della memoria su scala enterprise.

Strumenti: 4 strumenti per operazioni di memoria.

Setup:

hermes memory setup  # seleziona "supermemory"

Come scegliere

• Hai bisogno di supporto multi-agente? Honcho
• Vuoi self-hosted e gratuito? OpenViking o Holographic
• Vuoi zero-config? Mem0
• Vuoi grafi di conoscenza? Hindsight
• Vuoi compressione delta? RetainDB
• Vuoi efficienza della larghezza di banda? ByteRover
• Vuoi funzionalità enterprise? Supermemory
• Vuoi privacy (solo locale)? Holographic

Per configurazioni dei provider profilo-per-profilo complete e pattern di flusso di lavoro reali, vedi configurazione di produzione Hermes Agent.

Parte 7: La filosofia

Perché la memoria delimitata batte la memoria illimitata

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

La memoria delimitata funziona meglio. Ecco perché.

La cura impone qualità. Quando hai spazio limitato, salvi solo ciò che importa. Comprimi, consolida e priorizzi. La memoria illimitata incoraggia a scaricare tutto e a non ripulire mai.

La velocità conta. 1.300 token nel prompt di sistema è 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 per il compito effettivo.

Dimenticare è una funzionalità. La memoria umana dimentica. Non è un bug — è come priorizziamo. 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 maliziose o corrotte.

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

Memory Scaling

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. Il memory scaling 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” non scala.

La memoria delimitata di Hermes Agent supporta naturalmente il memory scaling. Imponendo la cura, 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 ciò che il modello porta tra le sessioni. 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 bene quella memoria — 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 database vettoriale e nessuna latenza per query. Ciò che sembra un vincolo è l’intero punto.

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 prompt di sistema dal primo token di ogni sessione.

I provider di memoria esterna estendono questo sistema per utenti che ne hanno bisogno di più: 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 install, configurazione e guide ai flussi di lavoro, vedi la panoramica di Hermes Agent.