La memoria degli agenti va dosata

La memoria persistente seduce perché sembra intelligenza che si accumula. Un agente sbaglia, salvi la lezione. Si confonde, conservi la correzione. Gestisce un caso limite, aggiungi quel pattern alla prossima esecuzione. Dopo qualche iterazione il sistema sembra più sicuro perché porta con sé più storia.

Ma questo è il default sbagliato. La memoria degli agenti va trattata come una dose, non come un interruttore. Prima di estendere la memoria persistente, serve un dose test: baseline senza memoria, retrieval curato, memoria completa, overhead di token, saturazione e analisi delle classi di errore. L’obiettivo non è dimostrare che la memoria aiuta. L’obiettivo è trovare la strategia minima che migliora l’affidabilità senza sommergere il modello o nascondere il prossimo collo di bottiglia.

Il riferimento utile arriva dall’articolo di Hugging Face e IBM Research How Much Memory Does Your Agent Actually Need?. La loro valutazione confronta baseline, iniezione completa di guideline e retrieval curato su più modelli. La lezione operativa è netta: la dose giusta dipende da capacità del modello, distribuzione dei task, spazio di contesto e failure mode ancora aperti.

La memoria non è un interruttore

Molti team introducono la memoria come una feature. L’agente ricorderà le preferenze dell’utente. L’agente riuserà le lezioni delle trace passate. L’agente recupererà note pertinenti. Il linguaggio è sicuro, ma la domanda di release resta spesso vaga: quanta memoria deve avere l’agente, e in quale punto del loop deve entrare?

Dietro la parola memoria ci sono almeno tre oggetti diversi. Il primo è la storia grezza: transcript, tool call, osservazioni, esiti intermedi. Il secondo è una guida distillata: regole riusabili estratte da run precedenti. Il terzo è il retrieval specifico per task, dove solo poche lezioni pertinenti vengono inserite nel contesto corrente. Non sono equivalenti. La storia grezza può essere rumorosa. Le guideline complete possono appesantire ogni step. Il retrieval può non recuperare proprio la lezione decisiva. L’architettura sembra più intelligente, ma diventa meno prevedibile.

Per questo la memoria va messa accanto ai budget di contesto e agli eval, non accanto ai toggle di prodotto. Se l’agente fatica già a tenere insieme istruzioni, tool, prove recuperate e contesto utente, altra memoria è solo un nuovo concorrente per una risorsa scarsa. Vale la stessa disciplina di gli agenti locali vogliono budget di contesto: il contesto non è un magazzino. È una superficie operativa.

Un dose test sulla memoria rifiuta il confronto generico tra memoria attiva e memoria spenta. Chiede una scala. Cosa succede senza memoria? Cosa succede con un set curato e compatto? Cosa succede quando inserisci tutte le guideline? Qual è l’overhead di token per task? Quali errori spariscono, e quali restano identici? Se la versione con memoria completa vince di poco ma raddoppia i token in input, il team non ha trovato una best practice. Ha trovato un trade-off da decidere.

Quanta memoria è abbastanza?

Abbastanza memoria significa la quantità minima che cambia il profilo di errore dell’agente nei task che davvero mandi in produzione. La definizione è stretta di proposito. Evita l’errore più comune: misurare la memoria in base a quanto testo pertinente il sistema riesce a recuperare, invece di misurarla in base al lavoro completato correttamente.

Si parte da un set fisso di task. Dentro devono esserci percorsi ordinari, richieste ambigue, errori dei tool, dati mancanti, confini di permesso e casi in cui l’agente deve fermarsi. Se l’agente opera su più step, misura il completamento dell’intero task, non solo la plausibilità del ragionamento intermedio. Un sistema di memoria che migliora il secondo step ma induce una tool call sbagliata al quinto non ha migliorato il prodotto.

Poi esegui almeno quattro configurazioni. Prima, la baseline: l’agente come viene rilasciato, senza memoria aggiunta. Seconda, retrieval curato: un nucleo stabile di lezioni ad alta fiducia più pochi elementi pertinenti al task. Terza, memoria completa: tutte le guideline approvate inserite dove l’architettura prevede. Quarta, revisione di saturazione: un’analisi dei casi in cui la memoria non migliora il risultato, perché anche l’assenza di guadagno è un risultato.

Ogni configurazione dovrebbe riportare completamento del task, completamento di scenario quando disponibile, token medi in input, token medi in output, numero di tool call, numero di step e movimento delle classi di errore. Il retrieval riduce gli errori da passaggio mancante? La memoria completa riduce gli errori di policy ma aumenta i conflitti tra istruzioni? L’overhead cresce perché l’agente fa più step o perché ogni step porta un prompt più pesante? Sono diagnosi diverse.

Qui il legame con gli eval è essenziale. Un dose test senza classi di errore nominate diventa una leaderboard. Dice quale variante ha segnato di più, ma non spiega perché. Il pattern più robusto è quello di gli eval AI vogliono budget di errore: definisci prima gli errori che contano, poi osserva quale dose di memoria muove quale classe.

Quando il retrieval curato batte la memoria piena

L’articolo di Hugging Face e IBM Research è interessante perché non trasforma la memoria in una ricetta unica. Nei risultati riportati, alcuni modelli forti con margine migliorano con il set completo di guideline, mentre modelli più deboli ottengono risultati migliori con un nucleo compatto e retrieval specifico per task. Compare anche un pattern di saturazione, dove la memoria aggiunta non produce miglioramenti misurabili. Questo caso conta quanto i successi, perché ricorda che più contesto non significa automaticamente più capacità.

Il retrieval curato può vincere per un motivo semplice: un modello più debole potrebbe non saper usare bene una pila grande di istruzioni. Il set completo può contenere la lezione giusta, ma il modello deve comunque darle priorità rispetto a richiesta utente, istruzioni di sviluppo, schema dei tool, prove recuperate e stato intermedio. Se il modello è già fragile, la memoria diventa rumore. Un set più piccolo può migliorare il rapporto segnale-rumore.

La memoria completa può comunque essere la scelta corretta. Se il modello ha capacità sufficiente e spazio di contesto, la guideline rara sul caso limite può essere ciò che evita un errore costoso. Ma è una condizione, non uno slogan. La memoria completa deve meritare il suo posto migliorando le classi di errore rilevanti a un costo accettabile.

La saturazione è il pattern più facile da ignorare. Un modello forte può mostrare poco guadagno perché risolve già i task valutati, perché la memoria non intercetta gli errori residui o perché l’eval è troppo stretto per esporre il beneficio. La risposta non dovrebbe essere espandere la memoria in automatico. Dovrebbe essere analisi degli errori: raccogli i fallimenti, leggi le trace e decidi se il prossimo intervento è memoria migliore, tool migliori, permessi migliori o un task design diverso.

Costruisci il dose test prima della release

Un dose test pratico può stare dentro un ciclo di release. Scegli un solo loop che conta già: un agente di support triage, un agente di ricerca interna, un agente di sales operations o un assistente di coding con accesso ai tool. Non partire da tutti gli agenti. I problemi di memoria si vedono meglio quando il confine del task è concreto.

Crea un piccolo ledger con una riga per configurazione. Le colonne dovrebbero includere fonte della memoria, metodo di iniezione, regola di retrieval, overhead di token, cacheability, score di completamento, principale classe di errore migliorata, principale classe di errore peggiorata e decisione di release. La decisione deve essere una tra quattro opzioni: tenere la baseline, rilasciare retrieval curato, rilasciare guideline complete o investigare saturazione. Se il team non riesce a scegliere una di queste, il test non è finito.

Verifica anche la leggibilità delle trace. La memoria può far sembrare l’agente più capace rendendo però più difficile capire perché ha deciso. Se l’agente recupera cinque lezioni e chiama tre tool, la trace deve mostrare quale lezione è stata usata, dove è entrata nel prompt e se l’azione finale dipendeva da quella lezione. Qui il test di memoria incontra la governance di release. Gli agenti in release vogliono trajectory gate perché un pass rate senza percorso ispezionabile non basta per l’autonomia in produzione.

La regola finale è semplice: estendi la memoria persistente solo dopo che un loop ha superato il dose test. Se il retrieval curato dà quasi tutto il guadagno con poco aumento di token, rilascia quello. Se le guideline complete migliorano chiaramente scenari difficili e restano sostenibili, rilascia quelle. Se nessuna dose muove gli errori importanti, smetti di aggiungere memoria e studia il collo di bottiglia. Il team disciplinato non chiede quanta memoria può contenere un agente. Chiede quanta memoria l’agente sa usare.