Uno dei limiti più frustranti degli agenti basati su LLM è la loro amnesia radicale: ogni sessione ricomincia da zero, ignara di ciò che è stato tentato, scartato o compreso in precedenza. Non è solo un problema di efficienza. Quando più persone o più agenti collaborano su progetti di ricerca, sviluppo software o analisi complesse, l’assenza di una memoria condivisa produce uno spreco sistematico: si ripetono errori già commessi, si riesplorano strade già percorse e si perdono le ragioni dietro certe decisioni.

Il gruppo di lavoro dietro il paper Beyond Memory: A Templated Substrate for Heterogeneous Collaborative Knowledge Work with LLM Agents propone una soluzione architetturale a questo problema. Il cuore del loro contributo è un template chiamato llm-wiki-memory-template, un’istanza concreta di un pattern più ampio – il llm-wiki – che inserisce una wiki gestita e collegata dall’LLM tra le fonti grezze e l’agente. L’idea non è nuova in senso assoluto (Karpathy l’ha descritta nel 2026, altri l’hanno sperimentata), ma questa implementazione portabile e riutilizzabile la rende un substrato per il lavoro collaborativo eterogeneo su tre assi: multi-umano, multi-agente e multi-dominio.

Perché dovrebbe interessare a chi progetta stack on-premise per l’AI? Perché la natura stessa del wiki è append-only per convenzione. Ciò significa che il sistema non sovrascrive né cancella: ogni tentativo fallito, ogni ipotesi scartata, ogni conclusione poi rivista restano registrati insieme a quelli riusciti. È un approccio che le pubblicazioni scientifiche o la condivisione di codice non possono replicare: lì i vicoli ciechi scompaiono per sempre, e con loro l’opportunità di non ripeterli. Qui invece diventano parte del patrimonio conoscitivo dell’organizzazione. In contesti regolamentati o dove serve auditabilità – si pensi a banche, farmaceutica, difesa – la persistenza del percorso decisionale ha un valore enorme e si sposa con i requisiti di sovranità del dato: niente cloud, nessuna fuoriuscita di informazioni.

I casi di studio illustrati nel paper danno corpo a queste potenzialità. Il primo è una linea di ricerca individuale che preserva le iterazioni abbandonate, creando una traccia continua del ragionamento. Il secondo è un progetto a due autori in cui un audit retroattivo ha permesso di correggere due esperimenti precedenti: la copertura dichiarata di 20 su 20 si è rivelata in realtà di 14 e 12 risposte basate su evidenze, poi portate a 18 e 18 dopo una correzione, con l’intero percorso di fallimento rimasto documentato. Il terzo è un deployment multi-agente ancora in corso, descritto come design report, e il quarto è una variante educativa cross-dominio.

Dal punto di vista infrastrutturale, una wiki mantenuta da LLM agenti sposta l’attenzione dall’elaborazione effimera dei token a uno storage incrementale e indicizzato localmente. In un deployment on-premise o air-gapped, questo significa che l’investimento in storage veloce e capacità di retrieval (spesso integrata nei framework RAG o in vettoriali locali come Qdrant, Milvus o LanceDB) diventa parte del TCO, accanto a GPU e RAM. Non si tratta solo di un costo: è un asset che cresce con l’uso e può diventare un vantaggio competitivo per l’organizzazione che impara dai propri fallimenti più di quanto facciano i concorrenti che li gettano via.

Le proprietà sociotecniche identificate dagli autori – failure-path preservation, agent honesty, appropriation – meritano attenzione. La prima è la capacità di conservare il sentiero degli errori. La seconda è l’onestà dell’agente, favorita dal fatto che il wiki append-only riduce la tentazione di cancellare i propri passi falsi. La terza è l’appropriazione: team diversi possono adattare il template a domini specifici senza riscriverlo da zero. Insieme, descrivono un artefatto che sposta la qualità del lavoro con LLM da una questione puramente tecnica a una pratica socio-organizzativa.

L’impatto di questo pattern, se adottato su scala più ampia, potrebbe modificare la progettazione stessa degli strumenti di AI collaborativa. Invece di assistere a una successione di chatbot senza stato, vedremmo emergere knowledge base vive, alimentate da agenti multipli, interrogabili e verificabili. Per chi gestisce infrastrutture AI on-premise, la domanda non è più solo “quanto velocemente genera risposte” ma anche “quanto bene ricorda e traccia la conoscenza collettiva”. È un cambio di prospettiva che avvicina le pipeline di LLM ai sistemi di gestione documentale di livello enterprise, con tutte le implicazioni di conformità e sicurezza che ne derivano. E poiché la wiki accumula dati nel tempo, la scelta di dove e come conservarli diventa strategica: on-premise, per chi non può delegare a terzi la propria storia decisionale.