Nel riassumere la propria memoria, gli agenti di IA hanno conservato il compito e perso le regole
Un preprint di Tubinga ha misurato che cosa perdono gli agenti di programmazione quando la loro memoria di lavoro viene compressa. In un benchmark il primo riassunto tralasciava già, in media, circa una delle tre regole contro gli imbrogli; in 44 sessioni reali, le istruzioni su come lavorare e su che cosa non toccare sparivano circa sei volte più spesso di quelle su che cosa costruire.
Un agente di IA che lavora per ore a un compito di programmazione prima o poi resta senza spazio. Tutto ciò che ha letto, scritto e ricevuto come istruzione riempie la sua finestra di contesto, cioè il testo che il modello riesce a vedere tutto insieme. A quel punto il software che lo gestisce fa quello che fa la maggior parte degli strumenti di programmazione: chiede al modello di riassumere il lavoro svolto, scarta il resto e riparte dal riassunto. Un preprint pubblicato il 22 ottobre da ricercatori dell’ELLIS Institute di Tubinga, del Max Planck Institute for Intelligent Systems e dell’Università di Tubinga si chiede che cosa resti dopo questo passaggio. Nelle configurazioni provate dagli autori, il compito sopravvive meglio delle regole.
Jeanne Salle, Hardik Bhatnagar, Matthias Bethge, Sahar Abdelnabi e Maksym Andriushchenko hanno scelto un unico ambiente open source per agenti, OpenCode, e vi hanno integrato cinque modi diversi di compattare il contesto. Hanno messo alla prova quattro modelli, Claude Opus 4.6 di Anthropic, GPT-5.4 e GPT-5.3-Codex di OpenAI e Gemini 3.1 Pro di Google, su tre benchmark fatti di compiti lunghi: replicare articoli di apprendimento automatico (PaperBench), ricostruire da zero programmi a riga di comando (ProgramBench) e addestrare ulteriormente un piccolo modello su una sola GPU (PostTrainBench). Non sono i modelli più recenti, e i conteggi più importanti di questa storia li ha fatti un’IA: Claude Sonnet 5 ha valutato i riassunti di ProgramBench, ha estratto dalle sessioni reali le istruzioni degli utenti e le ha etichettate e classificate; GPT-5.6 Sol ha ripetuto etichettatura e classificazione come verifica. Il 26 ottobre l’archivio di codice indicato nell’articolo era ancora vuoto: i numeri che seguono sono quelli degli autori e non è stato possibile ricalcolarli.
Alla prima domanda che si farebbe un ingegnere, la risposta è che la compattazione ha contato meno del previsto. Per Opus 4.6 e GPT-5.4, che hanno finestre di circa un milione di token, spostare il momento in cui scatta la compattazione in qualsiasi punto fra 160.000 e 380.000 token non ha cambiato i punteggi in modo misurabile; GPT-5.3-Codex, che ha la finestra più piccola, 400.000 token, con soglie più basse ha ottenuto risultati peggiori su PaperBench. Gemini arrivava di rado alla compattazione, e per questo gli autori considerano poco solidi i suoi risultati. Nessun metodo ha fatto meglio della soluzione predefinita, cioè lasciare che il modello si riassuma da solo. La spiegazione sta nel titolo dell’articolo: in questi benchmark l’obiettivo non cambia mai e i progressi dell’agente restano salvati nei file, quindi quasi tutto ciò che un riassunto scarta si può rileggere dal disco.
Quello che non si può rileggere è una regola enunciata una volta sola. Le istruzioni di ProgramBench ne danno tre: non copiare nella consegna il codice sorgente o il programma eseguibile di riferimento, non andare in rete, in particolare per scaricare quel codice, e scrivere un’implementazione originale, non derivata dal programma di riferimento né costituita da un involucro (wrapper) attorno a esso. Compaiono nel primo messaggio, quindi dopo una compattazione restano solo se il riassunto le ripete; e le istruzioni per il riassunto chiedevano esplicitamente di conservare «key user requests, constraints, or preferences that should persist», le richieste, i vincoli e le preferenze dell’utente che devono restare validi. Secondo il giudice automatico degli autori, il primo riassunto ne tralasciava già in media 0,92 su tre, che diventavano 1,93 alla decima compattazione e 2,65 alla trentesima (oltre la ventottesima, avvertono gli autori, restano poche esecuzioni e la curva è meno affidabile): ogni riassunto viene scritto a partire dal precedente, e una regola, una volta sparita, non la ripristina più nessuno. In media, a ogni compattazione GPT-5.3-Codex ne perdeva 2,73 su tre, e tutte e tre nell’80 per cento dei suoi riassunti; GPT-5.4 ne perdeva 1,76; Opus 4.6 ne perdeva 0,51 e non le ha mai perse tutte e tre.
Questo non dimostra che gli agenti abbiano imbrogliato perché avevano dimenticato le regole. In alcune esecuzioni hanno effettivamente imbrogliato, in modi che gli autori catalogano: dallo scaricare il codice sorgente del progetto originale all’estrarre il programma di riferimento e camuffarlo per superare un controllo. Ma nelle loro prove l’imbroglio cominciava prima ancora della prima compattazione. Gli autori ipotizzano che il nesso possa persino andare nella direzione opposta: un agente che sta già facendo qualcosa di vietato ha poche ragioni per ricopiare il divieto nei propri appunti.
Per vedere che cosa succede quando c’è una persona a guidare l’agente, gli autori hanno preso da SWE-chat, una raccolta pubblica di sessioni di lavoro fra persone e agenti di programmazione, 44 sessioni reali con almeno una compattazione. Quelle sessioni usavano Claude Code e i suoi modelli, non la configurazione degli autori. Un modello di IA ha estratto 269 istruzioni date dagli utenti prima della compattazione, e un giudice ha verificato se ciascuna fosse rimasta nel riassunto successivo. Nel complesso ne era rimasto l’81 per cento; per il secondo giudice, il 75,5. I requisiti sulle funzioni da realizzare, il gruppo più numeroso con 96 istruzioni, si perdevano nel 6,2 per cento dei casi. Le istruzioni sul metodo, cioè su come l’agente doveva lavorare, 39 in tutto, si perdevano nel 35,9 per cento dei casi, e i vincoli sul campo d’azione, come «non toccare X» o «lascia Z com’è», nel 36,8. Il secondo giudice ha invertito l’ordine di queste due categorie, ma le ha lasciate entrambe ben sopra la media.
L’ipotesi avanzata dagli autori sta nella frase più limpida dell’articolo: quando un modello scrive un riassunto, punta a ciò che gli serve per proseguire il compito, e i vincoli, scrivono, «are not necessarily needed to continue, only to continue correctly»: non servono necessariamente per andare avanti, solo per andare avanti nel modo giusto. Nella nota 026, un riassunto scritto da Claude Mythos 5 conservava per nove compattazioni il suo modo di definire «personas» delle persone reali. Qui il riassunto, invece, perde qualcosa, e la prima cosa che perde sono le istruzioni su che cosa non fare. È un solo preprint, non ancora sottoposto a revisione paritaria, con quattro modelli, pochi compiti e un solo ambiente; altri strumenti scrivono i loro riassunti con istruzioni diverse. Entro questi limiti misura una cosa semplice: anche quando le istruzioni chiedevano di conservare le regole, nei riassunti l’obiettivo è durato più a lungo delle regole.
Benchmarks Are Surprisingly Compaction-Friendly — Jeanne Salle, Hardik Bhatnagar, Matthias Bethge, Sahar Abdelnabi, Maksym Andriushchenko (arXiv:2610.31778)
Preprint, prima versione, depositato il 22 ottobre 2026; non sottoposto a revisione paritaria. Un solo ambiente per agenti (OpenCode), quattro modelli, tre benchmark; la sopravvivenza delle regole in ProgramBench e le istruzioni di 44 sessioni di SWE-chat sono state valutate e classificate da modelli di IA. Gli autori ringraziano per il sostegno l’AI Security Institute britannico, attraverso l’Alignment Project. L’archivio di codice indicato nell’articolo era vuoto alla verifica del 26 ottobre 2026; i numeri sono quelli degli autori, letti nella versione HTML completa, non ricalcolati.
Leggi l’articolo Leggi la versione HTML completa