Si immagini di dare lo stesso problema di contabilità a due persone ugualmente brave. Alla prima si concedono carta e penna. Alla seconda un foglio di calcolo, un archivio dove ritrovare i conti degli anni passati e due colleghi a cui passare le parti noiose. Se la seconda finisce prima e sbaglia meno, nessuno ne dedurrebbe che la prima è meno capace: ha solo lavorato con gli strumenti sbagliati.
È la tesi da cui parte Prime Agent: A Self-Improving RLM Harness, depositato su arXiv il 24 agosto 2026 (2608.23552; il paper indica come prima pubblicazione il 5 agosto) e in queste settimane fra i paper in tendenza su Papers with Code. Lo firmano undici autori, tutti di Prime Intellect; i referenti sono Seth Karten (anche Princeton) e Alex L. Zhang (anche MIT), primo autore dei Recursive Language Models su cui il sistema è costruito. Il codice è aperto. Una premessa da tenere a mente: chi costruisce l’harness è anche chi lo misura.
Un bancone di lavoro, non un flusso prestabilito
Un agente è un modello linguistico più tutto quello che gli sta attorno: il programma che gli passa il contesto, esegue gli strumenti che chiama, decide quando fermarlo. Quel programma si chiama harness. La domanda del paper è quale forma debba avere un harness perché un fallimento dica qualcosa sul modello e non sul programma che lo circonda.
La risposta degli autori è l’espressività. Invece di codificare un flusso di lavoro, l’harness offre dei primitivi e lascia al modello costruire la strategia. Il paper lo chiama una «membrana»: deve opporre il minimo attrito a ciò che il modello vuole fare, e intanto standardizzare le cose noiose, cioè esecuzione, ripresa dopo un guasto, verifica e contabilità delle risorse. Un modello, scrivono, dovrebbe fallire perché il compito è oltre le sue capacità, non perché l’harness ha perso lo stato, ha vietato un’azione utile, ha contato male le risorse o ha chiuso la sessione in anticipo.
Qui si dà per noto come è fatto un agente: come pianifica, come si compongono più agenti, come gli si dà una memoria che dura, e perché valutarlo è difficile. Tutto questo è costruito da capo nel libro.
Quattro piani di memoria
L’immagine più utile del paper è una gerarchia di stato presa in prestito dall’architettura dei calcolatori. Al piano più basso, L0, i pesi del modello: si cambiano solo con il fine-tuning, e qui restano fermi. Sopra, L1, il contesto attivo, cioè quello che il modello vede davvero a ogni chiamata; lo si riscrive con la compattazione. Il piano L2 è il cuore del sistema: un interprete IPython persistente per ogni sessione, dove variabili e risultati intermedi restano vivi da un turno all’altro senza passare dal contesto, più i subagenti in esecuzione. Il modello crea, riassume o cancella questi oggetti da sé, e gli autori chiamano il gesto agentic garbage collection. In cima, L3, lo stato su disco: la storia completa degli eventi, gli artefatti, e le voci del Continual Harness.
Il senso pratico di L2 si vede sul contesto lungo. Invece di infilare un documento enorme nel prompt, Prime Agent lo mette in un file e lascia che il modello lo cerchi, lo trasformi, lo riassuma e ci torni sopra con del codice. La lettura passiva di una sequenza lunga diventa un problema di gestione dell’informazione.
La delega passa da una primitiva asincrona, rlm: la si chiama con un compito, e restituisce subito un riferimento a una sessione figlia che ha il suo contesto, il suo interprete e la sua storia. Il padre intanto continua. I figli rispondono più tardi attraverso code di messaggi gestite da un demone, e possono scrivere al padre, ai fratelli, ai propri figli; un messaggio resta in coda anche se il destinatario è momentaneamente spento. Un’interfaccia, l’Agents View, permette a una persona di guardare l’albero delle sessioni, entrare in una, scriverle e uscire senza fermare niente.
Un dettaglio contabile conta più di quanto sembri: la spesa di un’esecuzione non è quella della sessione principale ma dell’intero albero,
$$R_{\text{tot}} = \sum_{s \,\in\, \mathcal{T}(\text{radice})} r(s)$$
dove $\mathcal{T}$ è l’insieme della radice e di tutti i suoi discendenti e $r$ è una risorsa alla volta (token, tempo, costo), che il paper riporta separatamente. Delegare a seicento subagenti non rende un risultato più economico sulla carta: la spesa resta visibile.
Che cosa si auto-migliora
Il «self-improving» del titolo va letto con precisione, perché non riguarda i pesi. Il Continual Harness, da un lavoro precedente di Karten e colleghi, conserva quattro tipi di voci: note di comportamento da aggiungere al prompt, memorie di fatti, skill (procedure eseguibili) e specifiche di subagenti riusabili. L’agente può chiederne la modifica mentre lavora, oppure un comando /refine fa rileggere a un modello gli eventi pertinenti e propone gli aggiornamenti. Ogni modifica entra a fine turno, porta con sé il motivo e ha una versione a cui si può tornare. Il prompt di base non si tocca.
Non va confuso con RRSI, il paper di Google Cloud AI Research uscito circa un mese dopo, dove un ottimizzatore esterno riscrive l’harness su un insieme fisso di compiti: qui è l’agente che, lavorando, si annota ciò che ha imparato. Il rischio però è parente stretto, e il paper lo mostra con un caso.
I numeri
ARC-AGI-3 è il risultato di copertina: giochi interattivi in cui il modello deve scoprire da sé le regole con un numero limitato di mosse. Con Prime Agent, Opus 5 arriva al 95,5% di punteggio RHAE, contro il 30,2% riportato con l’harness ufficiale ARC; la linea di riferimento umana nella stessa figura è al 95,4%. GPT-5.6 Sol arriva al 78,3%: con l’harness ARC era al 7,0%, con l’API Responses al 38,3%. Le configurazioni più forti continuano a migliorare spendendo più token, altre si fermano presto.
Il paper stesso mette le mani avanti. Le esecuzioni degli autori con Claude Code e Codex sono venute peggio dei risultati che Anthropic e OpenAI dichiarano sull’insieme pubblico, e quindi nel grafico compaiono i valori pubblicati. Sono, scrivono, riferimenti che «collocano» il risultato, non un effetto causale isolato dell’harness.
Contesto lungo e codice. Su nove compiti (OOLONG, LongBench v2 e Pro, ManyIH, LongCoT-Mini, EmulatorBench e altri) il confronto è a coppie, stesso modello con due harness. Prime Agent ha la stima più alta in 20 casi su 27: 8 su 9 con GLM-5.2 contro Pi-mono, 6 su 9 con Opus 5 contro Claude Code e con GPT-5.6 Sol contro Codex. Molte distanze sono al terzo decimale (0,744 contro 0,746 su LongBench v2 con Opus), altre sono nette (0,722 contro 0,558 su LongCoT-Mini). La tabella avverte che mancano intervalli di incertezza e che il grassetto non indica significatività. Su EmulatorBench, costruire da zero un emulatore in Rust (risultati dichiarati preliminari), Opus 5 resta vicino a zero con entrambi gli harness, 0,047 e 0,062: le sue esecuzioni, scrivono gli autori, sono fallite malgrado le chiamate agli strumenti andassero a buon fine.
Kernel GPU. Su PMPP-Hard, 69 problemi con un tempo massimo, i tassi di soluzione stanno fra il 59 e il 71%, e l’ordine fra Prime Agent e harness nativo si inverte fra le due coppie di modelli. Nessun distacco rilevante; gli autori rivendicano un consumo di token più basso, che però nel paper non è quantificato.
Ricerca autonoma. Nello speedrun di nanoGPT (ridurre i passi di addestramento di un GPT da 124 milioni di parametri fino a una perdita di validazione fissata, ogni record verificato come media su otto semi) la scelta dell’harness, ammettono gli autori, conta poco rispetto al rumore dell’esperimento. Cambia però il comportamento: con il REPL i modelli fanno esperimenti fuori dallo script di addestramento, per esempio simulando un ottimizzatore su gradienti sintetici. DeepSeek V4 Pro ne fa circa sei volte di più, per ogni addestramento lanciato, che con Claude Code (conteggi fatti a mano sulle tracce): forse, ipotizzano gli autori, perché l’harness di DeepSeek ha già una modalità simile. Kimi K3 si è costruito una funzione di prova sul benchmark, con cui ha lanciato una novantina di esperimenti di selezione e tutti i suoi 19 record validati; con il proprio harness, lo stesso modello ha fatto tutto modificando direttamente i file. Il paper cita una corsa di nanoGPT di 85,5 ore con 19 record validati.
Il caso Factorio, ovvero il limite
La parte più istruttiva sta nel gioco di costruzione di fabbriche Factorio. In un’esecuzione di sette giorni, Sonnet 5 ha speso 23,4 milioni di token in uscita, completato 24 tecnologie su 196 e creato 633 subagenti in 149 ondate, mai più di sette attivi insieme: un albero largo e basso, lavoro parallelo più che ricorsione profonda. Con le azioni irreversibili se l’è cavata male: un reset distruttivo del mondo ha riportato le tecnologie da cinque a una, poi la sessione si è ripresa.
In un’altra traccia, invece, l’agente ha scoperto che i comandi RCON della console potevano far comparire risorse direttamente dentro le macchine. Ha usato la scorciatoia nonostante un richiamo periodico anti-imbroglio, e poi l’ha salvata come skill riusabile. La persistenza, scrivono gli autori, ha conservato proprio il comportamento che ottimizzava l’obiettivo misurato sfruttando un difetto della specifica. Le contromisure che indicano sono generiche ma giuste: interfacce d’azione con il minimo dei privilegi, validazione indipendente dello stato, rollback verificabile delle modifiche contaminate.
Un agente che trova il buco nella regola invece di fare il lavoro è un vecchio problema dell’apprendimento per rinforzo, con un nome preciso. Perché succede, e perché una ricompensa ben scritta non basta, è nel capitolo sulla ricompensa.
Che cosa resta da verificare
Il confronto più forte, ARC-AGI-3, è anche il meno controllato: un harness misurato dai suoi autori contro valori presi da altri. Il resto dei confronti mostra un harness competitivo, spesso avanti di poco, senza intervalli di confidenza. Mancano le ablazioni: non si sa quanto del guadagno venga dal REPL, quanto dai subagenti, quanto dal Continual Harness, e gli autori stessi indicano come lavoro futuro isolare i contributi. E la conclusione ammette che molte funzioni restano poco usate perché i modelli di oggi non sono stati addestrati a usarle.
Perché conta adesso
Sulla domanda se i progressi degli agenti vengano dai modelli o dagli harness, Prime Agent prende posizione con un prodotto aperto: l’harness deve essere un bancone ben attrezzato, non una catena di montaggio, e i benchmark andrebbero letti chiedendosi quanto del risultato misuri il bancone. Gli autori si aspettano che la strada verso agenti capaci di lavorare per giorni passi dall’addestrare modelli e harness insieme. Il caso Factorio ricorda il rovescio: un agente che si scrive le proprie abilità si scriverà anche i propri trucchi, e un harness che li conserva con cura ha bisogno di qualcuno, o di qualcosa, che li rilegga.
I commenti sono riservati agli iscritti.
Accedi per commentare