Memoria di un agente AI: cosa ci va dentro e dove conviene tenerla
La memoria di un agente AI è l'insieme delle informazioni che l'agente ritrova all'inizio di una sessione senza che nessuno gliele riscriva. Volcengine ha rilasciato il 21 agosto 2026 la versione 0.4.16 di OpenViking, un progetto open source che il proprio README definisce "an open-source context database for AI agents" e che ha superato le 30.000 stelle su GitHub. Il rilascio in sé conta poco, conta la scelta di partenza: OpenViking mette memoria, documenti e procedure in un unico filesystem virtuale invece che dentro un database vettoriale.
Quella scelta risponde a un problema che conosce chiunque abbia portato un agente oltre la demo. Le tre cose che chiamiamo memoria hanno cicli di vita diversi, si aggiornano in momenti diversi e finiscono quasi sempre nello stesso indice, dove poi nessuno sa più cosa c'è dentro e perché.
Le tre cose che chiamiamo memoria di un agente AI
La memoria di un agente AI, nella pratica, sono tre materiali distinti che vale la pena tenere separati anche quando stanno nello stesso posto.
| Materiale | Cosa contiene | Chi lo scrive | Quando cambia |
|---|---|---|---|
| Memoria | preferenze dell'utente, cose imparate lavorando | l'agente | a ogni sessione |
| Conoscenza | documenti, contratti, documentazione di prodotto | le persone | quando cambia il documento |
| Procedure | istruzioni su come si fa una cosa in questa azienda | le persone | raramente, e con revisione |
Tenere uno stato fra un passo e l'altro è anche il punto in cui un agente smette di essere un chatbot, e su questo ho scritto un pezzo a parte sulla differenza tra chatbot e agente di intelligenza artificiale.
La distinzione non è teorica, decide chi ha il permesso di scrivere. La memoria la scrive l'agente da solo, quindi è la sola delle tre che può riempirsi di roba sbagliata senza che nessuno se ne accorga. Le procedure le scrivono le persone e vanno riviste come si rivede il codice, perché un agente che segue una procedura sbagliata la segue mille volte.
OpenViking prende posizione proprio qui: unisce i tre materiali sotto un protocollo unico, dichiarando di voler "Unify Agent Memory, Knowledge RAG and Skills". È una scommessa ragionevole, a patto di non confondere l'unificazione dell'accesso con l'unificazione delle regole di scrittura.
Cosa cambia se l'agente esplora il contesto invece di interrogarlo
Il cuore di OpenViking è che l'agente naviga la propria memoria con comandi da filesystem invece di fare una query. Il README lo dice così: il sistema "stores memories, resources, and skills as one virtual filesystem under the viking:// protocol, so an agent browses its own context with ls, tree, and find instead of querying a black-box vector store".
La differenza pratica è il debug. Con un database vettoriale, quando l'agente risponde male, si sa che ha recuperato i pezzi sbagliati ma non si vede bene perché: la somiglianza fra vettori non si legge. Con un albero di file si apre la cartella e si guarda. Chi ha passato una serata a capire perché un sistema di ricerca semantica restituiva il contratto dell'anno prima sa quanto vale poter fare ls.
Il filesystem navigabile ha però un costo che il database vettoriale non ha: si esplora bene soltanto se qualcuno lo ha organizzato bene, esattamente come una cartella condivisa in azienda. Un database vettoriale non chiede struttura e per questo è comodo il primo giorno, un albero di file chiede struttura subito e la restituisce ogni giorno dopo.
I numeri di OpenViking, e cosa il confronto non misura
Il benchmark pubblicato nel README di OpenViking misura la memoria dell'utente sul dataset LoCoMo e riporta questi risultati.
| Agente | Senza OpenViking | Con OpenViking |
|---|---|---|
| OpenClaw | 24,20% | 82,08% |
| Hermes | 33,38% | 82,86% |
| Claude Code | 57,21% | 80,32% |
Il README di OpenViking dichiara nella stessa sezione una riduzione dei token in ingresso fra il 34,3% e il 91,0% e una riduzione della latenza delle interrogazioni fra il 58,45% e il 66,10%. Su tau2-bench riporta invece un miglioramento del tasso di successo di 6,87 punti percentuali sui compiti retail e di 11,87 punti su quelli airline.
Prima di prendere quei numeri come promessa di risultato, va guardata la colonna di sinistra: il termine di paragone è la configurazione che il README chiama "native", cioè lo stesso agente senza nessuno strato di memoria. Il confronto quindi dice che avere memoria batte non averla, che è vero e poco sorprendente. Non dice che OpenViking batte il sistema di memoria che avete già. Quel numero lì il benchmark non lo misura, e quasi nessun benchmark di questa famiglia lo misura.
Come dare memoria a un agente AI senza aggiungere infrastruttura
Il primo passo concreto è misurare, e si fa senza installare niente: aprite il file di istruzioni del vostro progetto e contate quante righe di quel file servono davvero a ogni sessione. Se sono meno di metà, non avete un problema di memoria, avete un problema di organizzazione, e nessun database di contesto lo risolve al posto vostro.
Se invece il materiale è cresciuto oltre quella soglia, OpenViking si installa e si avvia con quattro comandi.
Il comando openviking-server init apre una configurazione guidata, mentre doctor verifica l'installazione prima dell'avvio. Il progetto dichiara compatibilità con Claude Code, Codex, OpenClaw, Hermes, Cursor, TRAE, OpenCode, pi, i client MCP e LangChain/LangGraph, quindi non vincola a un fornitore di modelli. Sulle licenze conviene guardare prima di scrivere codice: il README dichiara AGPLv3 per il progetto principale, Apache 2.0 per crates/ov_cli e per gli esempi. Sono due mondi diversi nel momento in cui il vostro prodotto va a un cliente, e vale la pena chiarirlo con chi vi segue sui contratti invece che dopo.
Cosa cambia per chi costruisce agenti per i clienti
La memoria di un agente AI non è per forza un database, e su questo sito è una cartella. Le regole con cui vengono scritti questi articoli stanno in .claude/skills/articolo/, divise in cinque file che vengono caricati solo quando servono invece di viaggiare tutti insieme a ogni richiesta, e alla radice del repository c'è un CLAUDE.md che descrive la struttura del progetto. Le misurazioni di ricerca stanno in data/seo/ come file JSON che si leggono e non si interrogano. È esattamente il modello del filesystem navigabile, fatto a mano, e regge finché il materiale resta leggibile da una persona. A chi chiede di addestrare un modello sui propri contenuti rispondo partendo da qui, e ho scritto a parte quando il fine tuning di un modello serve davvero.
La memoria tenuta come cartella scritta a mano si rompe a una soglia riconoscibile in anticipo. Si rompe quando il materiale cambia più in fretta di quanto qualcuno riesca a riorganizzarlo, ed è la stessa soglia oltre la quale conviene una mappa strutturale del progetto invece di lasciare che l'agente cerchi da solo, come ho descritto scrivendo di come ridurre i token di un agente di coding. Prima di quella soglia, aggiungere un database di contesto significa aggiungere una cosa da mantenere per risolvere un problema che non avete ancora.
Dove girano i dati della memoria, e perché in Italia decide tutto
Su OpenViking, in Italia, viene prima una domanda che non è tecnica. Il progetto è mantenuto da Volcengine, cioè da ByteDance, e prevede una versione gestita ospitata su Volcano Engine accanto a quella installabile in casa. Per un progetto personale è irrilevante, per lo studio di un cliente cambia tutto, ed è la stessa valutazione che consiglio sempre di fare prima di scegliere quali permessi dare agli strumenti AI in azienda e prima di decidere dove tenere i documenti che l'AI deve leggere. Se il materiale che volete dare in pasto all'agente è coperto da segreto professionale, l'edizione self-hosted non è una preferenza, è l'unica opzione.
Il contesto smette di essere una cosa che si recupera
La direzione comunque è chiara e vale al di là di questo progetto. Il contesto di un agente sta smettendo di essere una cosa che si recupera e sta diventando una cosa che si organizza, ed è lo stesso spostamento che ha portato gli strumenti di coding ad avere una memoria automatica gestita da loro e le procedure a diventare skill installabili. Chi costruisce agenti per i clienti farebbe bene a trattare quella organizzazione come parte del prodotto, perché è la parte che il cliente non può rifare da solo. Se vi serve una mano a impostarla, è esattamente il lavoro che facciamo negli agenti AI su misura.
Un agente senza memoria riparte da zero ogni mattina. Un agente con la memoria disordinata riparte da zero e ci mette pure di più, perché prima deve leggere tutto quello che avete accumulato per scoprire che non gli serviva.
Fonte primaria: il repository volcengine/OpenViking su GitHub.
Domande frequenti
Serve per forza un database vettoriale per far cercare un'intelligenza artificiale nei documenti aziendali?
No, non sempre. Un database vettoriale serve quando i documenti sono molti e la ricerca deve essere semantica, cioè per significato e non per parola. Su volumi piccoli, poche decine di documenti stabili, una cartella con nomi di file chiari e un indice scritto a mano ottiene lo stesso risultato senza infrastruttura da mantenere. La domanda da farsi prima è quanti documenti cambiano ogni settimana: è quello, non il numero totale, che decide se serve un sistema di ricerca vero.
Che differenza c'è fra dare memoria a un agente e fare il fine tuning di un modello?
La memoria è materiale che l'agente legge al momento e che si può cancellare o correggere in un secondo, il fine tuning è un addestramento che cambia i pesi del modello e va rifatto da capo per cambiare idea. Per informazioni che cambiano, come le preferenze di un cliente o le procedure di un'azienda, la memoria è quasi sempre la risposta giusta. Il fine tuning serve quando a cambiare è il modo di rispondere, non il contenuto della risposta.
La licenza AGPLv3 di OpenViking è un problema se lo uso dentro un prodotto?
Dipende da come lo distribuisci, ed è una domanda da fare a chi ti segue sui contratti prima di scrivere codice. Il README di OpenViking dichiara licenze diverse per componenti diversi: AGPLv3 per il progetto principale, Apache 2.0 per la CLI in crates/ov_cli e per gli esempi. L'AGPLv3 ha obblighi che scattano anche quando il software viene offerto come servizio via rete, quindi non è la stessa situazione di una libreria MIT.
Dove finiscono i dati se installo un database di contesto per gli agenti AI?
Dipende dalla modalità di installazione, e va deciso prima di caricarci dentro qualcosa. OpenViking prevede un'edizione open source che gira sulla propria infrastruttura, una versione gestita ospitata su Volcano Engine e una self-managed per ambienti regolamentati. Nella prima i dati restano dove è installato il server, nella seconda escono verso un fornitore cinese, e per molti settori italiani questa sola differenza chiude o apre la valutazione.
Un agente AI può ricordare cose fra una sessione e l'altra senza strumenti esterni?
Sì, e nella maggior parte dei casi è il punto di partenza corretto. Un file di istruzioni nel repository, letto a ogni avvio, è già memoria persistente: costa zero, sta sotto controllo di versione e si legge a occhio nudo. Il limite arriva quando quel file cresce oltre quello che ha senso caricare a ogni sessione, ed è il momento in cui conviene separare quello che serve sempre da quello che serve ogni tanto.