Il problema che si vede dopo la decima chiamata

Hai mai visto un agente che per le prime tre azioni fa quello che serve, poi alla sesta dimentica un vincolo che gli avevi dato all’inizio e sbaglia? Succede quando il compito è lungo: i requisiti iniziali, i tentativi falliti, i sotto-obiettivi aperti finiscono sepolti nella cronologia o oltre il limite della finestra di contesto. L’agente agisce solo su quello che vede nelle ultime righe, e perde lo stato decisionale che conta.

Il paper chiama questo problema behavioral state decay, il degrado dello stato comportamentale: le informazioni rilevanti ci sono da qualche parte nella traiettoria, ma l’agente non le riporta in superficie quando deve decidere.

Perché conta per te

Se stai costruendo un agente per compiti che durano più di qualche chiamata, il problema lo incontri subito. Un debug di sistema che richiede dieci comandi, un’analisi che passa per più file, una configurazione con dipendenze da rispettare: ogni volta che la traiettoria si allunga, lo stato rilevante si disperde. Oggi la soluzione più comune è spingerlo tutto nel prompt di sistema o riassumere periodicamente a mano, ma nessuna delle due scala bene.

Il paper propone una memoria attiva che non aspetta di essere interrogata: un agente separato che osserva la traiettoria recente, aggiorna una memoria strutturata e decide autonomamente se iniettare un promemoria all’agente d’azione o restare in silenzio. Il modulo si attacca a un agente esistente senza modificarlo, e funziona con i framework già in uso.

Se hai un agente che perde pezzi su compiti lunghi, questa architettura ti dà un punto di partenza concreto.

Cosa dice il paper

Gli autori hanno costruito un memory agent che gira in parallelo all’action agent (l’agente che decide le azioni). A ogni passo:

1. Riceve la traiettoria recente (ultime azioni, osservazioni, output)
2. Decide se aggiornare la memoria strutturata (un dizionario con chiavi come task_requirements, environment_facts, failed_attempts, diagnoses, open_subgoals)
3. Decide se iniettare un promemoria testuale all’action agent o lasciarlo lavorare senza intervento

La memoria non è un database passivo da interrogare: l’agente di memoria sceglie quando intervenire, e lo fa solo se ritiene che lo stato rilevante non sia già visibile all’action agent.

Lo hanno testato su due benchmark:

• Terminal-Bench 2.0: compiti da terminale Linux che richiedono sequenze lunghe (configurazioni di sistema, debug multi-passo)
• τ²-Bench: compiti su interfacce web e applicazioni desktop, dove l’agente deve ricordare obiettivi attraverso più pagine

Risultati su pass@1 (percentuale di compiti completati al primo tentativo):

• Terminal-Bench: +8.3 punti percentuali con l’agente di memoria rispetto all’action agent da solo (sia per agenti più deboli che più forti)
• τ²-Bench: +6.8 punti percentuali

Gli autori hanno confrontato cinque varianti:

1. Memory agent proattivo (quello proposto): inietta promemoria solo quando decide che serve
2. Bank esposto passivamente: l’action agent vede sempre l’intero stato della memoria
3. Iniezione continua: ogni aggiornamento viene iniettato, sempre
4. Advisor-only: l’agente di memoria propone azioni, non gestisce lo stato
5. Retrieval generico: recupera informazioni su richiesta, come un RAG

L’intervento selettivo batte tutte le alternative. Iniettare sempre crea rumore, esporre tutto passivamente non garantisce che l’action agent lo usi al momento giusto, e il retrieval su richiesta richiede che l’agente sappia cosa cercare.

Come prova di concetto per una policy di memoria open-weight, hanno addestrato Qwen3.5-27B su un dataset chiamato SETA con supervised fine-tuning e GRPO (un algoritmo di reinforcement learning). Il modello migliora sulla validation e mostra trasferimento parziale su Terminal-Bench, ma resta un esperimento preliminare.

Quanto fidarsi

Questo paper lavora su abstract e sulle informazioni della pagina arXiv: il PDF completo non era accessibile. Quello che sappiamo:

• I miglioramenti sono misurati su due benchmark specifici (Terminal-Bench 2.0 e τ²-Bench), che coprono compiti da terminale e interfacce grafiche, ma non rappresentano tutti i compiti lunghi possibili. I guadagni su altri domini restano da verificare.
• L’architettura è plug-and-play con agenti esistenti, ma richiede un secondo agente LLM che gira in parallelo: c’è un costo computazionale e di latenza. Il paper non riporta quante chiamate aggiuntive servono per compito, né il tempo totale di esecuzione.
• L’addestramento di una policy di memoria open-weight (Qwen3.5-27B) è descritto come passo preliminare con trasferimento parziale, non come soluzione pronta.
• Gli ablation mostrano che l’intervento selettivo batte le alternative testate, ma non sappiamo quanto dipenda dalla qualità del prompting dell’agente di memoria: una policy più semplice potrebbe funzionare quasi altrettanto bene.
• Non è chiaro come scala il bank di memoria quando i compiti durano decine o centinaia di passi: a un certo punto anche la memoria strutturata si riempie.

In sintesi: i risultati sui benchmark sono solidi, l’idea è chiara e testabile, ma i dettagli di implementazione e i limiti pratici richiedono il paper completo per essere valutati fino in fondo.

Cosa farne

Se stai costruendo un agente su compiti che durano più di cinque-dieci passi e vedi che perde informazioni rilevanti, prova questa architettura:

1. Aggiungi un secondo agente che osserva la traiettoria recente e mantiene un dizionario di stato (requisiti del task, fatti sull’ambiente, tentativi falliti, sotto-obiettivi aperti).
2. Dagli una policy di intervento semplice: inietta un promemoria solo se vede che l’action agent sta per violare un vincolo o ripetere un errore, altrimenti resta in silenzio.
3. Testa con e senza: misura il pass@1 sui tuoi compiti. Se non migliora, il problema non è la memoria distribuita, è altro (prompt iniziale poco chiaro, osservazioni ambigue, environment troppo instabile).

L’errore da evitare: pensare che basti esporre un log completo all’action agent. Il paper mostra che l’intervento attivo selettivo batte l’esposizione passiva della memoria, perché riduce il carico cognitivo e inietta le informazioni solo quando contano.

Un’altra implicazione: se il tuo agente usa retrieval (tipo RAG su documentazione), la memoria proattiva è complementare, non alternativa: il retrieval recupera conoscenza statica su richiesta, la memoria tiene lo stato decisionale del compito in corso e lo inietta senza aspettare che venga cercato.

Dove approfondire

Sul sito:

• Lezione “Stato e memoria negli agenti” (non ancora pubblicata, in roadmap builder): come gli agenti tengono traccia del contesto nei compiti multi-passo
• Scaffolding “Architettura a due agenti” (da creare): schema base per separare l’agente d’azione dall’agente di supervisione

Fuori dal sito:

• Paper su arXiv
• Terminal-Bench e τ²-Bench (cerca i repo ufficiali per i task di riferimento)