Databricks ha presentato Agent Memory, una funzione pensata per permettere agli agenti AI di conservare il contesto utile tra una conversazione e l'altra, invece di richiederlo da capo ogni volta. L'obiettivo è evitare che una regola di business spiegata oggi debba essere rispiegata la settimana successiva, mantenendo però sicurezza e correttezza dei dati.
In breve
- Agent Memory permette a un agente AI di riutilizzare informazioni fornite in conversazioni precedenti, senza richiederle di nuovo.
- L'esempio discusso riguarda una regola di calcolo del fatturato (escludere resi e ordini cancellati) che l'agente dovrebbe ricordare anche nelle richieste successive.
- La community tecnica sottolinea tre requisiti: la memoria deve essere pertinente, sicura e facile da correggere.
- Le regole di business stabili andrebbero mantenute in uno strato governato e separato, mentre la memoria dovrebbe custodire preferenze e approcci già testati.
- Un errore di assegnazione dello scope della memoria può far sì che le informazioni di un utente finiscano nelle risposte date a un altro utente: un rischio concreto da presidiare.
Perché un agente che "dimentica tutto" è un problema
Un agente AI che riparte da zero a ogni conversazione si comporta come un collega che, ogni volta che gli si chiede qualcosa, deve ripartire da un foglio bianco. Nella discussione della community Databricks, l'analogia usata è proprio questa: quando si chiede aiuto a una persona con cui si lavora abitualmente, non le si rispiega l'intero contesto aziendale a ogni interazione, perché quella persona lo ha già acquisito lavorando a fianco nel tempo. Molti agenti conversazionali, invece, non mantengono questa continuità: una richiesta formulata oggi produce una risposta corretta, ma la stessa richiesta ripetuta una settimana dopo può richiedere di nuovo tutte le premesse.
Questo comportamento non è solo scomodo per chi usa l'agente: è un limite reale all'utilità pratica dello strumento in contesti aziendali, dove le stesse regole, gli stessi criteri e gli stessi dati vengono interrogati più volte nel tempo da persone diverse.
Come funziona in pratica l'esempio del calcolo del fatturato
L'esempio discusso nella community riguarda un agente AI incaricato di calcolare il fatturato di un'azienda. Nella prima conversazione, all'agente viene spiegato che il calcolo deve escludere resi e ordini cancellati. L'agente applica correttamente la regola e restituisce il risultato atteso.
La settimana successiva, viene chiesto all'agente di calcolare il fatturato suddiviso per area geografica. Idealmente, l'agente non dovrebbe richiedere di nuovo la spiegazione della regola sui resi e sulle cancellazioni: dovrebbe poter riutilizzare quel contesto, applicandolo insieme alle regole di business più aggiornate e nel rispetto dei permessi sui dati validi in quel momento. È proprio questo il problema che Agent Memory intende affrontare: non limitarsi a far rispondere l'agente a una singola domanda, ma permettergli di costruire sulle informazioni già acquisite.
Perché la memoria da sola non basta: pertinenza, sicurezza, correggibilità
Una memoria che conserva informazioni sbagliate può essere più dannosa di nessuna memoria. La discussione nella community Databricks individua tre caratteristiche che un sistema di memoria per agenti dovrebbe avere: essere pertinente, essere sicura e poter essere corretta facilmente. Una regola di business diventata obsoleta, un'assunzione errata o un'informazione proveniente da un altro utente non dovrebbero influenzare silenziosamente le risposte future.
Un punto tecnico emerso nel confronto riguarda proprio la separazione dei ruoli: le definizioni di business stabili e verificate (come la regola sul calcolo del fatturato) dovrebbero restare in uno strato governato, distinto dalla memoria dell'agente, mentre la memoria dovrebbe custodire soprattutto preferenze dell'utente e approcci già sperimentati per risolvere problemi simili. In questo modo, una regola aziendale modificata non rischia di essere "sovrascritta" da qualcosa che l'agente ha semplicemente ricordato da un'interazione precedente, magari ormai superata.
Qual è il rischio concreto legato allo scope della memoria?
Il rischio concreto è che le informazioni associate a un utente finiscano per influenzare le risposte fornite a un altro utente, a causa di un errore nell'assegnazione dello scope della memoria. Nella discussione tecnica viene chiarito che lo scope — cioè il perimetro a cui una determinata porzione di memoria è associata — dovrebbe essere impostato a partire dall'identità verificata dell'utente finale, gestita da codice applicativo affidabile, e mai lasciato scegliere al modello stesso. Le richieste prive di un'identità utente chiara dovrebbero essere respinte, invece di ricadere su uno scope condiviso per difetto.
Va inoltre osservato che lo scope non equivale a un controllo di accesso: se il componente applicativo che gestisce l'agente ha la possibilità tecnica di leggere qualsiasi scope, un errore nel codice dell'applicazione è sufficiente perché la memoria di un utente compaia nella risposta data a un altro. È un aspetto che chiunque valuti o implementi sistemi di memoria per agenti dovrebbe tenere presente fin dalla progettazione, non come rifinitura successiva.
Cosa significa questo per chi valuta un assistente AI aziendale?
Per chi valuta l'adozione di un assistente conversazionale o di un agente che gestisce dati aziendali, la capacità di mantenere il contesto tra conversazioni successive è un criterio di valutazione concreto, non un dettaglio tecnico secondario. Alcuni elementi utili da verificare quando si confrontano soluzioni diverse:
- Separazione tra regole di business e memoria: le regole stabili (es. criteri di calcolo, politiche aziendali) dovrebbero risiedere in uno strato distinto, verificabile e aggiornabile centralmente.
- Possibilità di correggere o cancellare singole informazioni memorizzate: un sistema di memoria dovrebbe permettere di intervenire su un singolo elemento errato, senza dover ripristinare l'intera configurazione.
- Gestione dello scope per utente: le informazioni memorizzate per un utente non dovrebbero poter comparire nelle risposte fornite ad altri utenti, nemmeno per errore applicativo.
- Continuità senza rigidità: l'agente dovrebbe poter riutilizzare il contesto pregresso restando comunque allineato alle regole e ai permessi più aggiornati, non a una fotografia statica del passato.
Questi criteri valgono sia per un assistente che risponde ai clienti sui contenuti di un sito, sia per un agente che analizza documenti o estrae dati da sistemi gestionali: in entrambi i casi, la qualità del contesto che l'agente conserva incide direttamente sulla sua utilità quotidiana.
Domande frequenti
Cos'è Agent Memory? È una funzione presentata da Databricks che permette agli agenti AI di conservare e riutilizzare il contesto delle conversazioni precedenti, invece di richiederlo da capo ogni volta.
Perché un agente AI "senza memoria" è meno utile in azienda? Perché costringe a ripetere ogni volta le stesse premesse e regole di business già spiegate, rendendo l'interazione più lenta e meno naturale rispetto a lavorare con un collega che conosce già il contesto.
La memoria di un agente può propagare errori? Sì: una regola di business obsoleta, un'assunzione sbagliata o informazioni di un altro utente possono influenzare le risposte future se la memoria non è gestita con criteri di pertinenza, sicurezza e correggibilità.
Le regole di business dovrebbero stare nella memoria dell'agente? Secondo la discussione tecnica di riferimento, è preferibile mantenere le definizioni di business stabili in uno strato governato separato, lasciando alla memoria il compito di custodire preferenze e approcci già sperimentati.
Se il tema della memoria applicata agli agenti AI ti interessa perché stai valutando un assistente per la tua azienda, puoi approfondire cosa significa in pratica progettare un sistema che ricordi il contesto del cliente nella pagina dei servizi di iNexus, oppure raccontare la tua esigenza attraverso la pagina contatti.