Gli agenti AI stanno passando dal completamento di codice supervisionato all’esplorazione autonoma 24/7. Il problema: ogni interazione costa token, e quando un agente lavora per ore su task complessi, la bolletta API diventa seria. NVIDIA e MIT hanno provato un approccio diverso: invece di ottimizzare il modello, hanno fatto ottimizzare il modo in cui l’agente interagisce con l’ambiente. Da solo.
Il risultato si chiama SoL-Pi — Scaling Auto-Research Loops — un sistema che usa l’AI per migliorare l’AI. Non a livello di pesi neurali, ma a livello di ‘harness’: quella struttura software che fa da tramite tra il modello e gli strumenti che usa. Pensatelo come un maggiordomo — può essere efficiente o può farvi ripetere le cose dieci volte.
Come funziona il loop di auto-ricerca
Il concetto è semplice sulla carta, meno nella pratica. Un agente AI gira su un harness di base ed esegue centinaia di task. Un secondo agente — il ‘ricercatore’ — osserva le tracce di esecuzione, identifica gli sprechi ricorrenti e propone modifiche al codice dell’harness. Ogni candidato passa attraverso due filtri sequenziali: deve mantenere le performance entro tolleranze predefinite e migliorare almeno una metrica di efficienza.
Niente overfitting sui task di sviluppo. Le modifiche vengono testate su un set di ambienti isolati (~500 configurazioni eseguibili, tra repository GitHub e task sintetici), ma la validazione finale avviene su EdgeBench, un benchmark pubblico che non ha mai visto il processo di ricerca. Se un candidato fallisce sul dataset held-out, viene scartato. Nessun aggiustamento post-validazione.
Il processo ha generato circa 150 direzioni proposte, oltre 3.000 run e più di 60.000 interazioni agente-ambiente. Alla fine, quattro meccanismi sono sopravvissuti alla selezione.
I quattro meccanismi che compongono SoL-Pi
Action Fusion. L’agente modifica spesso un file e poi lancia subito un comando di test o build. Action Fusion combina entrambe le azioni in una sola richiesta API, restituendo entrambi i risultati in un’unica osservazione. Meno round trip, meno latenza, meno token sprecati.
Online Context Compact. Invece di compattare il contesto solo quando si avvicina al limite della finestra, questo meccanismo valuta se conviene farlo alla fine di ogni sottotask completato. Stima il numero di richieste rimanenti in base al piano ancora da eseguire e confronta il risparmio proiettato con il costo di riscrivere la cache del prompt. Se il gate passa, compatta. Altrimenti aspetta. È un bilancio economico, non una soglia fissa.
ObservationPack. I tool restituiscono spesso output enormi: log di build, risultati di ricerca, dump di file. ObservationPack archivia localmente tutto ciò che supera i 10 KiB e invia il contenuto completo solo per le prime due richieste successive. Dalla terza in poi, sostituisce l’output con un handle stabile, dimensione originale e un estratto di poche righe (testa e coda complete). L’agente può recuperare pagine esatte quando serve, ma non si trascina dietro megabyte di log a ogni turno.
Evidence-Preserving Reducer. Prende i log di build e test lunghi almeno 4 KiB e li comprime usando un modello più economico (GPT-5.6 Luna), che estrae solo l’evidenza chiave in una ‘ricevuta’ verificabile. Un controllo deterministico valida schema, hash, codice di uscita, citazioni esatte e dimensione. Se qualcosa non torna, o se il risparmio è marginale, il sistema cade sull’output originale. Il modello ausiliario estrae evidenza; l’agente principale mantiene la responsabilità delle decisioni.
Ognuno di questi meccanismi agisce su uno stadio diverso del workflow: esecuzione delle azioni, gestione del contesto, archiviazione delle osservazioni, lettura delegata. Complementari, non ridondanti.
I numeri su EdgeBench
EdgeBench è il benchmark pubblico usato per la validazione finale: 51 task open source su 134 totali. SoL-Pi è stato testato in due configurazioni: ‘Efficiency’ (tutti e quattro i meccanismi attivi) e ‘Performance’ (solo il meccanismo col punteggio più alto per quel backend).
Con GPT-5.6 Sol, la configurazione Efficiency usa 1,10 miliardi di token — il 49,0% in meno rispetto a Pi, l’harness di riferimento — mantenendo il 93,7% del punteggio medio (42,0 vs 44,8). Il costo API scende del 33,2%, pari a circa 8,75–13,50 dollari risparmiati all’ora rispetto agli harness nativi e 4,36–5,71 dollari rispetto a Pi.
La configurazione Performance alza il punteggio medio da 44,8 a 47,2 (+5,3%), riduce il traffico token del 6,1% e migliora l’efficienza token del 9,8%. Non male per un sistema che si è ottimizzato da solo.
Trasferimento cross-model senza modifiche
SoL-Pi è stato sviluppato interamente su GPT-5.6 Sol. Poi è stato applicato a Opus 5 (Claude) senza ulteriori ricerche o adattamenti. Risultato: mantiene il 94,3% del punteggio medio di Pi su Opus 5, riducendo il traffico token del 44,7% e il costo del 29,5%. I meccanismi si attivano meno frequentemente su Opus 5 — probabilmente perché il sistema non ha mai visto tracce di esecuzione Claude durante la ricerca — ma quando si attivano, funzionano.
Questa generalizzazione cross-backend senza fine-tuning è rara. Suggerisce che i miglioramenti scoperti non sono artefatti del comportamento specifico di GPT-5.6 Sol, ma pattern di inefficienza più generali.
Altri benchmark: Terminal-Bench 4, IMO 2026, kernel swarm
Su Terminal-Bench 4 (63 task CPU-only), SoL-Pi risolve 15 task contro i 18 di Codex e Pi. Ma il costo totale scende del 26,3% rispetto a Pi (211 dollari vs 286), e il costo per task risolto cala dell’11,6% (14,07 vs 15,91 dollari). Meno task completati, spesa più contenuta.
Su IMO 2026 — sei problemi di matematica olimpica formalizzati e verificati in Lean 4 — SoL-Pi passa tre problemi con un costo totale di 62,69 dollari. Costo per problema passato: 20,90 dollari, il più basso tra Codex (22,89) e Pi (25,32).
Il test più interessante è sul kernel swarm: un coordinatore Codex gestisce 20 worker che cercano di ottimizzare un kernel in cicli macchina simulati, con budget di due ore. Configurazioni testate: un singolo agente Codex, 20 worker Pi baseline, 20 worker SoL-Pi. Lo swarm SoL-Pi raggiunge 1.127 cicli a 60,11 dollari. Lo swarm Pi baseline arriva a 1.366 cicli ma spende 82,12 dollari. Il singolo agente resta il più economico (39,20 dollari) ma si ferma a 1.333 cicli.
Lo swarm SoL-Pi risparmia il 26,8% di costo API rispetto allo swarm baseline, pur rimanendo più costoso del singolo agente. Un harness più efficiente può aiutare sistemi multi-agente a esplorare meglio entro budget fissi, ma non sostituisce la semplicità di un agente singolo quando il parallelismo non serve.
Attivazione dei meccanismi: non tutti si accendono sempre
Ogni meccanismo ha un trigger rate (percentuale di task su cui si attiva) e una trigger intensity (numero medio di attivazioni per task innescato). Su GPT-5.6 Sol, ObservationPack ottiene il punteggio medio più alto; su Opus 5, è Action Fusion. Ma ogni componente riduce il traffico token totale su entrambi i backend.
Quando tutti e quattro i meccanismi girano insieme, ObservationPack diventa più selettivo — probabilmente per sovrapposizione con Evidence-Preserving Reducer sulle tracce ricche di osservazioni. Ogni meccanismo ottiene però un guadagno di efficienza token maggiore nello stack completo rispetto alla configurazione standalone: non si pestano i piedi a vicenda, si dividono il lavoro.
Cache reuse e costo totale
Accorciare il contesto può ridurre il riutilizzo della cache prompt quando cambia un prefisso precedentemente cachato. Ma conservare un prefisso lungo non è sempre la scelta più economica su un task intero. Online Context Compact e ObservationPack scambiano un po’ di reuse per meno input ripetuto.
Con GPT-5.6 Sol, lo stack completo riduce il traffico cache-read da 2,13 a 1,06 miliardi di token, mentre il traffico cache-write sale da 0,014 a 0,032 miliardi. Nonostante l’aumento di cache-write, il costo totale scende da 1.339 a 894 dollari. Ogni configurazione a meccanismo singolo abbassa il costo per punto di punteggio rispetto a Pi, su entrambi i backend. Il reuse della cache da solo non racconta tutta la storia: conta il costo pieno del task.
Case study: come è nato Action Fusion
Il paper documenta il percorso di Action Fusion dall’osservazione iniziale alla retention finale: 27 iterazioni su quattro stadi — analisi oracle, costruzione baseline, ottimizzazione prompt e schema tool, validazione held-out.
L’analisi oracle identifica azioni adiacenti ripetute e proietta una riduzione dell’11,5% di token se Action Fusion si attivasse sempre, giustificando una linea di ricerca dedicata. Durante la costruzione della baseline, l’attivazione via prompt si dimostra inaffidabile, così l’agente estende lo schema tool per esporre direttamente l’azione fusa, stabilendo una baseline stabile senza chiamate invalide.
Poi affina prompt e schema su task di sviluppo, introducendo il trigger rate come metrica di accettazione intermedia accanto al punteggio task. La configurazione finale viene selezionata usando entrambe le metriche, congelata e mantenuta dopo la validazione held-out.
Questo caso mostra come un loop di auto-ricerca locale possa stabilizzare l’interfaccia e il comportamento di trigger di un meccanismo, e come l’auto-ricerca possa sviluppare metriche intermedie specifiche per meccanismo per guidare l’ottimizzazione accanto alle performance end-task.
Limitazioni e direzioni future
Generalizzare gli artefatti harness scoperti tramite RSI resta una sfida aperta. I risultati forniscono evidenza preliminare che scalare i loop di auto-ricerca può mitigare il problema. L’analogia con il pretraining regge: l’harness è esposto a molti task e aggiornato dalle tracce risultanti. L’ipotesi è che scalare sia gli ambienti eseguibili sia la diversità delle idee di ricerca possa produrre guadagni sostenuti. Gli autori chiamano questa direzione ‘pretraining the harness’.
Multi-Backend Training. L’harness attuale è stato aggiornato da tracce generate da un singolo LLM. Su Opus 5, i meccanismi si attivano meno spesso e meno intensamente, ma migliorano comunque l’efficienza token quando innescati. Allenare e validare l’harness su più backend potrebbe migliorarne la robustezza preservando qualità ed efficienza.
Recursive Efficient Improvement. Un harness più efficiente abbassa il costo dell’auto-ricerca usata per costruire il successore. Il piano è usare SoL-Pi come harness di partenza per il prossimo ciclo di ricerca, dove costi per-run più bassi potrebbero far coprire a un budget fisso più ambienti, tracce e idee di ricerca. L’efficienza diventa sia risultato della ricerca harness sia risorsa per espandere la ricerca successiva. Gli autori chiamano questa possibilità ‘recursive efficient improvement’: è una visione a lungo termine, non un effetto composto dimostrato dallo studio attuale.
Search Coverage and Cost. Eseguire loop di auto-ricerca completi è computazionalmente costoso, il che rende difficili i confronti controllati di ampiezza e profondità di ricerca sotto budget fisso. Gli autori vedono le scaling law lungo queste dimensioni come una direzione promettente e lasciano l’indagine sistematica a lavori futuri.
Cosa significa per il futuro degli agenti autonomi
SoL-Pi non è il primo tentativo di far auto-ottimizzare un harness AI. Meta-Harness cerca su programmi harness eseguibili e ne valuta il trasferimento su dataset e modelli held-out. Recursive Harness Self-Improvement (RHI) affina specifiche a livello prompt del loop agente per singoli task. AHE evolve componenti harness modulari da evidenza di traiettoria e ne valuta il trasferimento cross-task e cross-model.
Il problema noto è l’overfitting: harness evoluti possono adattarsi troppo ai task usati durante la ricerca e fornire guadagni marginali su task non visti. Wang et al. hanno documentato guadagni limitati su task held-out per i metodi valutati e sottolineato il rischio di sovrastimare i miglioramenti quando i task di ricerca e valutazione si sovrappongono.
SoL-Pi affronta questo rischio scalando attraverso ambienti eseguibili diversi e usando un funnel ampio-profondo per affinare cambiamenti promettenti, mantenendo la valutazione finale held-out separata dallo sviluppo candidati. La ricerca punta all’efficienza token controllando che i candidati mantengano le performance task. La valutazione held-out fornisce evidenza preliminare che la ricerca ispirata a RSI a livello harness può scoprire meccanismi che generalizzano oltre i loro ambienti di sviluppo.
Se l’efficienza diventa ricorsiva — se un harness più economico permette di esplorare più candidati nel ciclo successivo — ogni generazione di harness potrebbe scoprire la prossima spendendo meno. Ancora da dimostrare su scala: il costo della ricerca diventa parte del guadagno.
