La maggior parte delle interfacce chat IA che hai usato non hanno davvero una memoria. Hanno una finestra di contesto, che è una cosa molto diversa. Quello che hai detto prima nella stessa conversazione è ancora davanti al modello. Quello che hai detto nella conversazione di ieri è sparito. Il giorno dopo ricominci da zero, e l'assistente si ripresenta come uno sconosciuto.
Hermes Agent è diverso. Ha un vero layer di memoria — separato dal contesto della conversazione — che impara cose su di te nel tempo, le porta attraverso sessioni e piattaforme, e fa sì che il bot si comporti come la stessa entità ogni volta che ci parli. Questo post spiega come funziona davvero, quali decisioni contano, e cosa ha cambiato l'interfaccia di memoria pluggabile della v0.7.0.
Memoria a breve termine vs a lungo termine
Per prima cosa, la distinzione che conta.
La memoria a breve termine in Hermes è la finestra di contesto della sessione. È una fetta della cronologia della conversazione in corso, gestita con una strategia di compressione proattiva: quando il contesto si avvicina al limite del modello, Hermes esegue un passo di riassunto che comprime i turni più vecchi in un sommario strutturato mantenendo gli scambi più recenti intatti. La compressione è stata raffinata in diverse release — riassunti strutturati con aggiornamenti iterativi nella v0.4.0, protezione della coda del budget token, endpoint di riassunto configurabile, e supporto per modelli di fallback. Nelle conversazioni lunghe, questo tiene l'agente veloce ed economico senza perdere contesto importante.
La memoria a lungo termine è la parte interessante. È un archivio di fatti, preferenze, correzioni e modelli utente che vive fuori dalla conversazione. Quando oggi dici al bot su Telegram "mi chiamo Alice," quel fatto viene scritto nella memoria a lungo termine. Domani, quando gli chiedi qualcosa su Slack, quel fatto viene recuperato e iniettato nel contesto prima che l'agente veda il tuo messaggio. Il modello continua a ricevere solo ciò che entra nella finestra, ma la finestra è preparata con le cose che dovrebbe sapere su di te.
La memoria a breve termine è un buffer. La memoria a lungo termine è una persona.
Honcho: cos'è e perché conta
Il provider di memoria a lungo termine di default in Hermes è Honcho, una libreria costruita apposta per la memoria IA-nativa. Il lavoro di Honcho è girare dietro l'agente e fare tre cose specifiche:
- 1.Osservare. Ogni messaggio utente e ogni risposta dell'agente alimentano Honcho come flusso di eventi. Honcho costruisce un modello utente interno da quel flusso — non cronologia di chat grezza, ma fatti e preferenze strutturate inferite dalla conversazione.
- 2.Ragionare sull'utente. Honcho esegue un piccolo layer "dialettico" che prova a costruire un'immagine coerente di chi sei, cosa vuoi e cosa hai corretto. Non è solo estrazione di parole chiave — è un modello mentale dell'utente in continua evoluzione.
- 3.Iniettare. Ad ogni nuovo turno, Honcho produce un breve snippet di contesto che riassume ciò che ritiene importi dell'utente, che Hermes premette al system prompt. Lo snippet cambia man mano che Honcho impara di più.
Due dettagli meritano attenzione perché sono facili da perdere.
Primo, le scritture di Honcho sono asincrone. L'agente non si blocca su una scrittura in memoria. Risponde, e il layer di memoria processa lo scambio in background. Questo significa che le conversazioni lunghe non pagano una tassa di latenza per gli aggiornamenti di memoria, e un'interruzione del backend di memoria non ferma il bot — perdi gli aggiornamenti durante l'interruzione, ma l'assistente continua a parlare.
Secondo, il recall di Honcho è tenuto fuori dal prefisso di sistema in cache. La funzionalità di prompt caching di Anthropic (usata pesantemente su modelli come Claude Sonnet 4.6) vuole che il system prompt sia stabile tra i turni così la cache colpisce. Lo snippet iniettato da Honcho cambia turno per turno, quindi Hermes lo appende deliberatamente dopo la sezione di sistema in cache. La cache funziona ancora per le parti statiche; il layer di memoria dinamico funziona ancora per le parti che cambiano. Questo è il tipo di compromesso meccanico che non finisce nelle note di rilascio ma decide se la tua bolletta mensile è 50$ o 500$.
Isolamento multi-utente in modalità gateway
Il gateway Hermes di default fa girare più utenti attraverso lo stesso processo agente. La memoria a lungo termine deve essere per utente, altrimenti le allergie di Alice finiscono nei suggerimenti culinari di Bob. La release v0.3.0 ha aggiunto un isolamento multi-utente adeguato per Honcho dentro il gateway, che in pratica significa:
- •Ogni ID utente del gateway mappa a un peer Honcho distinto, e le scritture di memoria sono circoscritte per peer.
- •Le sessioni in chat di gruppo ereditano sessioni per utente di default, quindi un canale condiviso scrive comunque flussi di memoria separati per ogni partecipante.
- •L'isolamento della memoria per profilo (v0.5.0/v0.6.0) significa che se esegui più profili Hermes sulla stessa macchina, la memoria di ogni profilo è un universo separato. Cambiare profilo non fa trapelare una persona nell'altra.
Niente di questo è visibile agli utenti. Tutto questo è il motivo per cui il bot non ricorda accidentalmente la persona sbagliata.
L'interfaccia di memoria pluggabile (v0.7.0)
Per le prime cinque release di Hermes, Honcho era cablato dentro. Nella v0.7.0 il layer di memoria è stato rifattorizzato in un'interfaccia provider adeguata — un piccolo ABC Python che qualsiasi backend di memoria può implementare. Il cambiamento è architetturalmente modesto e praticamente enorme.
L'interfaccia ti permette di scambiare backend di memoria senza toccare il core di Hermes:
- •Honcho è il provider di riferimento (e ancora il default). È completo, esegue un vero modello utente e gestisce correttamente l'isolamento multi-utente.
- •Supermemory è stato aggiunto nella v0.8.0 come secondo provider di prima classe, con supporto multi-container, modalità di ricerca configurabili e templating di identità.
- •mem0, OpenViking, RetainDB, Hindsight e ByteRover hanno tutti plugin di memoria della community nel sistema plugin di Hermes, con gradi variabili di profondità di integrazione.
- •Puoi anche scriverne uno tuo. L'ABC è piccolo: implementa
write(),recall(), qualche hook del ciclo di vita, e registralo come plugin.
Il provider di memoria integrato — il default senza dipendenze se non hai configurato nient'altro — è un fact store basato su SQLite che gestisce le basi: scrivi fatti, recuperali per rilevanza, circoscrivi per utente. Non è intelligente come Honcho, ma non ha bisogno di servizi esterni, e per un assistente personale su una VPS da 5$ è spesso tutto ciò che serve.
La cosa silenziosa che questo sblocca
La memoria pluggabile è il tipo di cambiamento architetturale che nelle note di rilascio sembra lavoro da custode. "Rifattorizzata la memoria in un'interfaccia provider" non è un titolone. Quello che fa in realtà è disaccoppiare la domanda "cosa dovrebbe ricordare un assistente IA su di te" dalla domanda "come funziona Hermes."
Ora puoi sostituire Honcho con un backend di memoria sintonizzato sul tuo caso d'uso — un vector store per chi vuole ricerca semantica su una knowledge base personale, un graph database per chi vuole relazioni esplicite tra entità, un puro store SQLite locale per chi non vuole che nessun dato di memoria lasci la propria macchina, un servizio di memoria aziendale per i team. L'agente non cambia. Cambia solo la cosa dietro l'interfaccia memory.
Questa è l'astrazione giusta per un progetto che vuole esserci ancora tra qualche anno. La memoria è personale, e il backend di memoria giusto per te non è necessariamente quello giusto per chiunque altro. Il lavoro di Hermes è essere un buon cittadino verso qualsiasi layer di memoria tu colleghi, e togliersi di mezzo.