Perché ho costruito Verimem — un memory layer con un notaio alla porta

Quando ho iniziato a costruire agenti che lavorano per giorni attraverso più sessioni, ho sbattuto contro il muro contro cui sbattono tutti: gli LLM non hanno memoria. La risposta dell’ecosistema è una famiglia di “memory layer” — mem0, Zep, Letta, Cognee, MemOS. Li ho studiati, eseguiti, smontati nelle scelte di design. Differiscono nella strategia di retrieval, nella struttura a grafo, nel pricing. Condividono una cosa: salvano qualunque cosa il loro estrattore produca.

Non è un dettaglio. La memoria di un agente sta a monte di tutto ciò che l’agente fa. Se un “fatto” falso entra nello store, ogni retrieval futuro è avvelenato, e l’agente non si limita a ripetere l’errore — ci costruisce sopra, con la calma sicurezza di chi sta citando i propri appunti. In psicologia si chiama confabulazione. In produzione si chiama incidente.

La scommessa

Verimem è la mia scommessa che il posto giusto per combattere tutto questo sia il momento della scrittura. Ogni add() passa da un gate di ammissione che fa una sola domanda: la fonte citata implica davvero questo fatto? I fatti ammessi vengono salvati con provenienza e grounding score. I claim non supportati — i «funziona», i «task completato», i numeri che nessuno ha misurato — vengono declassati. Quelli contraddetti, rifiutati.

Su SNLI, il controllo di entailment fonte⊢fatto raggiunge AUROC 0.971, ed è un numero indipendente dal giudice — nessun LLM che si corregge i compiti da solo.

La seconda metà della scommessa: provenienza a ogni lettura. Un retrieval non restituisce testo nudo; restituisce lo status del fatto e il grounding score del momento della scrittura, così il codice a valle può condizionare sulla fiducia invece di fidarsi e basta. update() non distrugge mai il fatto vecchio — lo soppianta, lasciando una catena history() verificabile. E i fatti portano una validità bitemporale: una memoria che sa quando ha smesso di essere vera.

Quanto vale il gate, onestamente

In un test avversariale a valle, il gate ha tagliato le risposte allucinate dal 95,9% al 12,2% (replicato su due seed, McNemar pooled p≈6e-44). Il meccanismo onesto: non rende l’agente più spesso corretto — converte la confabulazione in astensione (omissione 3%→85%). «Non lo so» al posto di un’invenzione sicura di sé. Per un agente che agisce su infrastruttura vera, quello scambio è il prodotto.

Il costo onesto: il gate di prima generazione rifiutava in eccesso il 30–39% dei fatti puliti alla soglia stretta. Un gate locale distillato (v2) oggi ammette il 92,4% dei fatti puliti a zero costi API — ma con quella bolletta ci ho convissuto per mesi, e la documento, perché ogni meccanismo anti-allucinazione ha una bolletta in recall.

Cosa Verimem non è

È nuovissimo e ha zero adozione oltre il mio uso quotidiano. È un sistema SQLite single-node, non uno store distribuito. I suoi benchmark sono self-run e riproducibili dal repo, non auditati da terzi. Sull’accuratezza grezza di extraction/QA contro sistemi maturi oggi è indietro — il suo asse è la fiducia, non la posizione in classifica. Tutto questo è scritto sul sito e nel repo, perché l’intera tesi del prodotto è che i claim non supportati non debbano sopravvivere — a partire dai miei.

È open source (MIT), gira in locale, e si aggancia a Claude Code, Cursor, Cline o Zed via MCP in due minuti: verimem.com.

I numeri: github.com/aureliocpr-ctrl/verimem, STATE.md e BENCHMARKS.md.