Memoria degli AI Agent: Build vs Buy

Costruite la memoria dell'agent in casa quando il pattern di recupero è semplice e stabile: una tabella Postgres con poche colonne tipizzate e un filtro sulla recenza supererà l'integrazione con una piattaforma sia in termini di costo che di debuggabilità. Acquistate un layer di memoria gestita solo quando avete molti utenti, ciascuno con il proprio grafo di memoria a lungo termine, e non disponete del tempo ingegneristico per gestire autonomamente decay, summarization e logiche di ranking.

La "memoria degli agent" è diventata una categoria affollatissima quasi dall'oggi al domani: ogni vendor di AI agent propone ormai un prodotto "memory", e ogni founder che costruisce un agent si chiede se ne abbia bisogno. La risposta onesta è che la maggior parte dei team confonde tre problemi molto diversi tra loro e finisce per acquistare una piattaforma per un problema che una singola tabella SQL avrebbe risolto.

Cosa significa davvero "memoria" per un agent

Tolto il marketing, la memoria di un agent è una di queste tre cose:

• Stato di sessione: ciò che è avvenuto in questa conversazione. Si tratta di gestione della finestra di contesto, non di memoria. Non acquistate nulla per questo.
• Fatti strutturati: il piano tariffario di un utente, i suoi ultimi cinque ordini, una preferenza espressa una volta sola. È un problema di database con una chiave di lookup.
• Richiamo emergente: l'agent porta in superficie qualcosa di rilevante che nessuno ha indicizzato esplicitamente, settimane dopo che era stato menzionato, classificato per rilevanza e recenza. Questo è l'unico aspetto genuinamente complesso.

La maggior parte dei prodotti che si chiedono "ci serve la memoria dell'agent?" sta in realtà parlando del secondo punto, e il secondo punto è una tabella facts con le colonne user_id, type, value e updated_at. Nessuna piattaforma necessaria.

Il caso per il build

Se i vostri lookup di memoria sono prevedibili, costruite la soluzione in casa. Uno schema tipico prevede una tabella Postgres con chiave per utente o tenant, un enum type per la tipologia di fatto, una colonna JSON value e pgvector su un campo di riepilogo per i casi in cui serve davvero la ricerca semantica anziché una lookup esatta. Consultate la documentazione di PostgreSQL su JSONB e pgvector per i primitivi.

Il vantaggio non è solo il costo, è il controllo. Quando la memoria si comporta in modo anomalo — l'agent porta in superficie un fatto obsoleto, o dimentica qualcosa che avrebbe dovuto conservare — dovete poter eseguire SELECT * FROM facts WHERE user_id = ... e vedere esattamente cosa è memorizzato e perché è stato o non è stato recuperato. Con una piattaforma gestita, questo si traduce in un ticket di supporto. Abbiamo riscontrato lo stesso principio nel nostro lavoro su single-call vs agent chains: meno livelli di indirezione ci sono tra il vostro codice e lo store sottostante, più velocemente potete diagnosticare perché un agent ha fatto qualcosa di inatteso.

Il build vince anche quando:

• Avete un pattern di recupero primario (per utente, per conversazione, per entità) anziché un "trova qualsiasi cosa rilevante" aperto.
• Il volume di dati per utente è ridotto (decine o poche centinaia di fatti), così il filtraggio brute-force supera un motore di ranking specializzato.
• Utilizzate già Postgres e non volete un altro vendor nella vostra lista di valutazione dei vendor di AI agent.

Il caso per il buy

Le piattaforme di memoria gestita guadagnano il loro posto quando il problema di recupero diventa genuinamente aperto: molti utenti, ciascuno con un grafo di memoria ampio e in crescita, dove l'agent deve decidere quali ricordi siano rilevanti per il turno corrente senza che dobbiate scrivere voi quella logica di ranking. È un problema ingegneristico reale che coinvolge funzioni di decay, risoluzione delle contraddizioni (la preferenza dell'utente è cambiata: quale fatto prevale?) e summarization dei ricordi più vecchi in versioni compresse, per evitare che il grafo cresca senza limiti.

Acquistate quando:

• Gestite agent multi-tenant su scala consumer, dove il volume di memoria per utente crescerà indefinitamente.
• Avete bisogno di summarization o forgetting automatici, e costruirli bene è un progetto di settimane che non avete il tempo di affrontare.
• La differenziazione del vostro team è nell'esperienza prodotto, non nell'infrastruttura di memoria, e il pricing della piattaforma è genuinamente più conveniente del tempo ingegneristico necessario a replicarla.

Il rischio sul fronte buy rispecchia quanto abbiamo scritto sul self-hosting di LLM vs costo API e compliance: state scambiando un costo di build una tantum con una fee continuativa per chiamata o per utente, più una dipendenza il cui roadmap non controllate. Leggete il comportamento effettivo di recupero e ranking del vendor prima di impegnarvi, allo stesso modo in cui leggereste le eval in un contratto con vendor AI prima di firmare.

Un pattern generalizzabile: adattate lo strumento alla forma del recupero

Abbiamo affrontato una versione di questo stesso problema build-vs-buy nel nostro agent di outreach, che analizza il sito di ogni prospect e redige un'email personalizzata. Inizialmente avevamo valutato una pipeline multi-step con uno step dedicato alla memoria per tracciare ciò che aveva già appreso su un'azienda tra un'esecuzione e l'altra. Si è rivelato che un pattern single-call con i fatti estratti passati direttamente nel contesto superava la versione multi-step sia per costo che per qualità, perché la "memoria" di cui avevamo bisogno era semplicemente "il risultato dell'ultima analisi", non un grafo in evoluzione. La lezione si applica direttamente: non ricorrete a un'infrastruttura pensata per il richiamo aperto quando il vostro pattern di recupero è in realtà una lookup.

Un test decisionale semplice

Prima di scegliere un lato, ponetevi tre domande:

1. Riuscite a formulare la query in anticipo? Se potete scrivere la clausola WHERE oggi, costruitela.
2. La memoria per utente crescerà senza limite? Se sì e non avete un piano per potarla, acquistare la logica di decay/summarization fa risparmiare tempo reale.
3. C'è qualcuno che se ne occuperà per il prossimo anno? I sistemi costruiti in casa hanno bisogno di un owner. Se nessuno ha la disponibilità, acquistare trasferisce quella responsabilità al vendor, a un certo costo.

La maggior parte dei prodotti agent — specialmente i tool B2B con qualche centinaio di fatti strutturati per account — propende per il build. I prodotti di personalizzazione su scala consumer propendono per il buy. Chiarite quale dei due state costruendo prima di cercare una piattaforma.

Se state definendo il perimetro di un agent e volete un secondo parere su se la memoria sia davvero il layer giusto su cui investire, contattateci.