TURING

evoluzioni-per-hermes-memoria

5 min read

Sistema di memoria Hermes

Stato attuale (giugno 2026)

L’assetto oggi e’ piu’ semplice e piu’ controllabile rispetto alle fasi iniziali. Hermes usa come provider di memoria holographic, con backend locale su SQLite e senza dipendenze da servizi esterni per il salvataggio dei fatti.

La configurazione attiva e’ questa:

  • memory.provider = holographic
  • memory.memory_enabled = true
  • memory.memory_char_limit = 2200
  • memory.user_profile_enabled = true
  • memory.user_char_limit = 1800
  • memory.nudge_interval = 10
  • memory.flush_min_turns = 6

Il plugin hermes-memory-store usa questi parametri:

  • auto_extract = false
  • default_trust = 0.5
  • min_trust_threshold = 0.3
  • hrr_dim = 1024
  • database SQLite in $HERMES_HOME/memory_store.db

Honcho non fa piu’ parte del flusso standard: la sezione honcho: {} e’ vuota e il backend non e’ piu’ considerato la scelta di default.

Sul lato modelli, l’ambiente lavora di base con deepseek-v4-flash; quando serve puo’ appoggiarsi anche ai modelli OpenAI disponibili per AGO, in particolare gpt-5.4 e le sue varianti principali, oltre a provider gia’ collegati come OpenRouter e Novita.

Come e’ organizzata la memoria

La memoria non e’ un blocco unico. Funziona meglio se viene distribuita su livelli diversi, ciascuno con un ruolo preciso.

1. Memoria persistente sempre in contesto

A ogni turno Hermes porta con se’ due blocchi di contesto persistente:

  • User profile: contiene cio’ che definisce AGO in modo stabile — preferenze di comunicazione, regole operative, vincoli ricorrenti.
  • Agent memory: raccoglie note di lavoro durevoli di IPAZIA — convenzioni di progetto, configurazioni dell’ambiente, percorsi, scoperte utili, lezioni gia’ verificate.

Questo livello serve per cio’ che deve essere immediatamente disponibile senza bisogno di ricerca.

La regola pratica e’ semplice:

  • si salvano fatti durevoli;
  • non si salvano progressi temporanei, numeri di issue o task conclusi;
  • le memory vanno scritte come fatti dichiarativi;
  • una procedura complessa e ripetibile va trasformata in skill, non compressa nella memoria breve.

2. Holographic memory e fact store

Qui entra in gioco il livello piu’ interessante dell’assetto attuale. holographic non e’ soltanto una memoria testuale: e’ un archivio locale interrogabile, con trust scoring, ricerca semantica ed entity resolution.

In pratica consente di lavorare con fatti strutturati su progetti, strumenti, preferenze, relazioni e decisioni ricorrenti, senza appesantire il contesto sempre iniettato.

Gli strumenti operativi sono due:

  • fact_store per aggiungere, aggiornare, cercare, collegare e interrogare i fatti
  • fact_feedback per alzare o abbassare il trust dei fatti in base alla loro utilita’ reale

Poiche’ auto_extract e’ disattivato, i facts non entrano da soli: vengono salvati solo quando IPAZIA decide che valgono davvero come conoscenza riutilizzabile.

Questo rende il sistema meno automatico, ma anche piu’ pulito. Si evita di trasformare ogni conversazione in rumore persistente.

Il fact store ha senso soprattutto per:

  • configurazioni e stati durevoli dell’ambiente;
  • preferenze ricorrenti di AGO;
  • relazioni tra persona, progetto, provider e infrastruttura;
  • informazioni che devono essere recuperabili, ma non necessariamente sempre presenti nel prompt.

3. Vault Markdown: Obsidian e Quartz

Il vault in /store/hermes/vault resta il livello principale per la conoscenza strutturata e leggibile. Qui finiscono la documentazione Calaido, le note di ricerca, le biografie, gli articoli, le guide e in generale tutto cio’ che deve diventare testo stabile, consultabile e spesso anche pubblicabile.

Questo materiale viene poi servito tramite Quartz su note.croswil.com.

A differenza della memoria conversazionale, il vault non si aggiorna da solo: richiede una scelta esplicita su cosa merita di diventare nota.

Infine c’e’ session_search, che lavora sulle sessioni passate tramite SQLite FTS5. E’ il livello piu’ adatto quando non serve una conoscenza stabilizzata, ma occorre recuperare una discussione precedente, una decisione presa in passato o il contesto di un lavoro gia’ fatto.

Non ha costi aggiuntivi e non richiede servizi esterni.

Come si ripartiscono i contenuti

Il criterio corretto non e’ accumulare tutto nella stessa memoria, ma assegnare ogni informazione al livello giusto.

  • User profile: preferenze stabili, stile, vincoli, modalita’ operative ricorrenti.
  • Agent memory: note durevoli sull’ambiente e sulle convenzioni di lavoro.
  • Holographic fact store: fatti strutturati su tool, provider, progetti, relazioni, stati e criteri decisionali.
  • Skill: procedure riproducibili e workflow consolidati.
  • Vault Markdown: documentazione, articoli, note, materiali pubblicabili.
  • session_search: recupero del contesto storico delle conversazioni.

Questa separazione e’ la vera ottimizzazione del sistema: non dipende solo dal provider scelto, ma dal fatto che ogni tipo di informazione finisca nel posto corretto.

Perche’ holographic e non Honcho

Il passaggio da Honcho a holographic ha tre vantaggi chiari.

  1. Costo: viene eliminato il consumo passivo legato a funzioni automatiche basate su API esterne.
  2. Controllo: il backend resta locale, leggibile e prevedibile.
  3. Pulizia operativa: i fatti vengono salvati in modo piu’ intenzionale, con meno rumore e meno dipendenza da automazioni opache.

Holographic non promette una memoria “piu’ intelligente” in senso generico. Il suo valore, qui, e’ diverso: e’ abbastanza ricco da supportare retrieval strutturato e abbastanza leggero da restare economico, trasparente e gestibile.

Per l’uso quotidiano questo compromesso e’ migliore.

Note operative finali

  • auto_extract = false: niente facts automatici.
  • min_trust_threshold = 0.3: i facts sotto soglia non vengono restituiti.
  • fact_feedback: serve a mantenere il retrieval pulito, premiando i facts utili e abbassando quelli superati.
  • hrr_dim = 1024: valore adeguato per l’uso attuale, senza necessita’ di tuning immediato.
  • memoria persistente e fact store restano due piani distinti: un fact in fact_store non entra automaticamente nella memoria sempre in contesto, e viceversa.

In sintesi, la soluzione attuale non punta ad avere “piu’ memoria” in astratto. Punta ad avere una memoria piu’ selettiva, locale, economica e leggibile: abbastanza stabile per sostenere il lavoro quotidiano, ma abbastanza disciplinata da non trasformarsi in accumulo indistinto.

Backlinks