Nel 2026 il modello che scegli conta meno del codice che ci metti intorno. Stesso LLM, stessi tool, stessi task: venti punti di differenza. Ecco cosa cambia davvero — e come sceglierlo.
Il rumore e il segnale
Se negli ultimi tre anni hai seguito l’intelligenza artificiale con anche solo un occhio, hai visto le classifiche. GPT contro Claude contro Gemini contro Kimi. I punteggi che si spostano di due decimali e diventano un annuncio. Le tabelle comparative su LinkedIn. La domanda ricorrente in ogni riunione: quale modello usiamo?
È uno spettacolo rumoroso, colorato, pieno di grafici a barre. Ed è il posto sbagliato dove guardare se vuoi capire perché il tuo agente funziona o no.
Nel luglio 2026 Composio ha fatto un esperimento fastidiosamente semplice. Un solo modello: Kimi K3, reasoning al massimo. Gli stessi identici strumenti per tutti: un set di tool MCP ospitati su nove applicazioni aziendali — Gmail, Calendar, Sheets, Airtable, GitHub, Slack, Notion, Linear, PagerDuty. Gli stessi identici 25 task agentici reali.
Poi hanno cambiato una sola variabile: il codice che sta intorno al modello.
- Oh My Pi: 22/25 — 88%
- Kimi Code: 21/25 — 84%
- Hermes Agent: 20/25 — 80%
- Claude Code: 19/25 — 76%
- Pi Agent / OpenCode / Grok Build: 18/25 — 72%
- Codex: 17/25 — 68%
Venti punti di scarto. Stesso cervello, stesse mani, stessi compiti. Tutta la differenza sta nel software di contorno.
Quel software ha un nome: harness. Ed è la cosa di cui non parla nessuno.
La corsa ai parametri e i finimenti
Harness, in inglese, è l’imbracatura. I finimenti del cavallo.
Chiunque abbia avuto a che fare con animali da tiro sa una cosa che nel machine learning stiamo riscoprendo adesso: un purosangue con i finimenti sbagliati tira meno di un mezzosangue attaccato bene. Il collare che comprime la trachea invece di scaricare sulle spalle. Le tirelle di lunghezza sbagliata che sprecano metà della forza. Il cavallo è fortissimo. Il carro non si muove.
Per un decennio abbiamo comprato cavalli sempre più grossi. Da GPT-3.5 a GPT-4 il salto di qualità era reale, e cambiare modello era la mossa giusta. Oggi i modelli di frontiera sono già abbastanza intelligenti per la stragrande maggioranza dei compiti aziendali. Il collo di bottiglia si è spostato.
Si è spostato sui finimenti.
1. Cos’è un harness — e perché nessuno te lo spiega
L’harness è tutto ciò che non sono i pesi del modello.
È il codice che decide cosa entra nel prompt e in che ordine. Quali tool sono disponibili e come vengono descritti. Cosa succede quando il modello sbaglia. Quando fermarsi. Dove salvare il file finale. Quanta cronologia trascinarsi dietro e quando comprimerla.
L’equazione che circola oggi tra chi costruisce agenti è questa:
Agente = Modello + Harness
Per anni la parte destra è stata considerata idraulica. Il valore stava nei pesi, l’harness era il tubo. Oggi sappiamo che è falso, e c’è un’ipotesi con un nome quasi comico che lo dice: l’ipotesi dei geni misgestiti. Le capacità dei modelli di frontiera sono largamente sprecate perché li avvolgiamo in strutture rigide e mal progettate.
Molti fallimenti sui benchmark non sono fallimenti di ragionamento. Sono errori di interfaccia. Il contesto che si satura. Lo storico dei messaggi che si gonfia di scarti. Il file finale salvato nella sottocartella temporanea invece che nel percorso che il valutatore si aspettava — dopo che il lavoro intellettuale era stato fatto correttamente.
Il cavallo aveva tirato. Il carro era attaccato male.
2. Il vero collo di bottiglia: non è la finestra di contesto
Qui c’è il trabocchetto che pochissimi spiegano chiaramente.
Le schede tecniche dichiarano finestre di contesto da centinaia di migliaia di token. Un milione. Due milioni. Il numero è vero nel senso che l’input viene accettato senza errori. È ingannevole nel senso che le prestazioni non reggono.
Si chiama context rot, degradamento del contesto. Man mano che l’input cresce, la capacità del modello di ritrovare un dettaglio preciso e di ragionare in modo aggregato cala nettamente — molto prima che la finestra sia piena.
Non è un bug da correggere nella prossima release. È struttura. Tutti i token dentro la stessa finestra competono per la stessa quantità finita di attenzione. Se ci infili 200.000 token perché tanto ci stanno, stai chiedendo al modello di distribuire la sua attenzione su milioni di relazioni irrilevanti per trovare l’unica che conta.
L’ago non diventa più difficile da trovare perché cambia l’ago. Diventa difficile perché cresce il pagliaio.
E qui arriva la domanda che ha aperto tutto il filone: e se smettessimo di mettere il contesto dentro il modello?
3. Il contesto come variabile: il paradigma RLM
La risposta si chiama Recursive Language Models (RLM), nata al MIT CSAIL con Alex L. Zhang, Tim Kraska e Omar Khattab. In forma divulgativa gira come Context as a Variable.
Il meccanismo, senza fronzoli:
1. Il documento non entra nel prompt. Viene caricato in una variabile Python dentro una sessione REPL viva. Un file, mille file, un’intera codebase.
2. Il modello parte cieco. Riceve solo la domanda dell’utente e i metadati della variabile: quanto è lunga, che struttura ha, quali chiavi contiene. Non ha letto niente.
3. Invece di leggere, scrive codice. Fa uno slicing, una regex, un filtro, un conteggio. Python esegue e restituisce solo il risultato — poche righe invece di cinquantamila token.
4. Quando serve un giudizio semantico, delega. Se il codice non basta (“questo paragrafo contraddice quello?”), il modello lancia una chiamata ricorsiva: nasce un agente figlio con un kernel isolato e un contesto vuoto, che lavora solo sullo snippet ricevuto, restituisce la risposta e sparisce. Il padre incassa la conclusione senza essersi mai sporcato la finestra con i passaggi intermedi.
L’esempio pratico chiarisce tutto meglio di qualunque schema. Invece di leggere 50 file di codice, l’agente scrive:
[f for f in repo.files if 'auth' in f.content]Python gli restituisce tre nomi di file e le righe rilevanti. Duecento token invece di cinquantamila. L’agente li legge, decide il passo successivo, ricomincia.
È esattamente quello che fai tu. Nessuno sviluppatore legge una codebase riga per riga prima di modificarla: usa grep, find, git log. L’RLM trasferisce quel flusso di lavoro al modello — gli dà strumenti di calcolo invece di chiedergli di ingoiare tutto.
Perché funziona (la parte teorica, in due minuti)
Ogni chiamata che l’harness manda al modello deve avere formato, lunghezza e densità che ricadono dentro la distribuzione su cui il modello è stato addestrato. Si chiama osservazione localmente in-distribuzione.
Un modello che in addestramento ha visto milioni di prompt da duemila token ragiona benissimo su duemila token. Lo stesso modello su duecentomila token è fuori dal proprio regime operativo — come un motore fuori giri.
Il compito dell’harness è spezzare un problema globalmente fuori distribuzione in una sequenza di sotto-problemi che, presi uno alla volta, sono perfettamente familiari. I dati di Zhang sugli harness come generalizzatori composizionali indicano che un harness costruito così permette a modelli addestrati solo su compiti brevi di affrontare compiti da 8 a 32 volte più lunghi, con incrementi di accuratezza di circa un ordine di grandezza rispetto all’addestramento diretto su sequenze estese.
4. Non è RAG. Non è una wiki. È un’altra categoria
Questa confusione è frequente e vale la pena chiuderla con una tabella.
| RAG tradizionale | Wiki / memoria strutturata | Context as a Variable | |
|---|---|---|---|
| Dove sta l’informazione | Vector database esterno | File Markdown che l’agente aggiorna | Variabile Python in un kernel vivo |
| Come cerca l’agente | Similarità vettoriale | Letture mirate di pagine e indici | Codice Python arbitrario: grep, regex, parsing |
| Cosa entra nell’LLM | I chunk recuperati | Le sezioni di note caricate | Solo il risultato dell’esecuzione |
| Rischio context rot | Medio-alto | Medio | Basso |
RAG e wiki risolvono un problema di recupero: dove trovo l’informazione giusta. Ma finiscono comunque per incollare testo nel prompt. Il ciclo resta sempre lo stesso:
trova → incolla → ragiona
L’RLM cambia il ciclo:
carica in variabile → scrivi codice per interrogarla → ricevi solo la risposta
L’informazione grezza non entra mai nel contesto del modello principale. È una differenza di categoria, non di grado.
5. Le harness che puoi usare oggi
L’ecosistema è passato da blog post a mercato in pochi mesi. Ecco cosa c’è, e a chi serve.
Le consolidate — quelle che troverai installate sulle macchine altrui
| Harness | Chi la fa | Cosa la distingue | Progetto |
|---|---|---|---|
| Claude Code | Anthropic | Lo stesso agente su terminale, IDE, desktop, web e CI, con controlli di team. Tool su file e shell, MCP, subagenti, skill. La più completa e la più cara: nel test Composio chiude a $1,96 per task riuscito, con il runtime mediano più lento. | github.com/anthropics/claude-code |
| Codex | OpenAI | Costruita intorno al contenimento: tre livelli di sandbox (sola lettura, scrittura nel workspace, accesso pieno) e tre politiche di approvazione, con esecuzione sia locale sia in sandbox cloud isolata per task paralleli. Ultima nel test Composio con 17/25. | github.com/openai/codex |
| OpenClaw | OpenClaw Foundation | Harness personale general-purpose, self-hosted: runtime con agent loop, assemblaggio del prompt e wiring dei tool, un workspace e uno store di sessioni per ogni agente, skill, memoria, subagenti con stato iniettato nel prompt del padre, server MCP, provider di modelli intercambiabili e loop agentici svegliati da cron. I canali di messaggistica sono una delle superfici d’ingresso, non il prodotto. MIT, una delle repo più stellate di sempre. | github.com/openclaw/openclaw |
| Hermes Agent | Nous Research | Assistente persistente e multicanale più che coding agent: memoria, tool, skill, task schedulati. Nel test Composio è la lezione sul costo per successo — 20/25 a $0,46 per task riuscito, un quarto di Claude Code a parità di modello. | github.com/NousResearch/hermes-agent |
| Pi | Earendil Works (Mario Zechner) | Harness minimale e leggibile, pensata per essere riscritta: agent loop, API unificata su più provider, TUI. La più veloce del test e quella che consuma meno token. Il fork oh-my-pi — edit ancorati per hash, LSP, subagenti — è la stessa base che segna il 22/25 in cima alla classifica di apertura. | github.com/earendil-works/pi · oh-my-pi |
Il dato che va letto in questa tabella non è chi vince. È che Pi e oh-my-pi sono lo stesso progetto a venti punti di distanza: 18/25 la base, 22/25 il fork. Non è cambiato il modello. È cambiato il loop.
Le emergenti — quelle che stanno spostando l’architettura
| Harness | Chi la fa | Cosa la distingue | Progetto |
|---|---|---|---|
| Qwen Code | Alibaba / QwenLM | Stessa harness su terminale, IDE, desktop, modalità demone, SDK e bot di messaggistica. Deliberatamente senza lock-in: parla con OpenAI, Anthropic, Gemini, Qwen e modelli locali via Ollama o vLLM, con switch a runtime. Framework e modelli evolvono insieme. | github.com/QwenLM/qwen-code |
DeepSeek Harness (dsh) | DeepSeek | Tutto è un plugin: il core non ha tool cablati, ogni capacità è un modulo caricabile sul kernel di composizione Cordis. Web UI, CLI, SDK Python, client MCP, Agent Client Protocol; legge AGENTS.md e CLAUDE.md. MIT, ma developer preview con breaking change dichiarate. | github.com/deepseek-ai/deepseek-harness |
| Prime Agent | Prime Intellect | L’unica RLM-native della lista: nessun tool separato, solo un kernel IPython persistente, e un harness che riscrive sé stesso via /refine. 95,5% su ARC-AGI-3, sopra il baseline umano esperto. Dettagli qui sotto. | github.com/PrimeIntellect-ai/prime-agent |
Le prime due dicono la stessa cosa da due direzioni: chi produce i modelli ha smesso di considerare l’harness un accessorio e ha iniziato a spedirla come prodotto. La terza dice che si può andare oltre — e come.
Le implementazioni RLM — per costruirtene una tua
alexzhang13/rlm — la libreria di riferimento
Il pacchetto ufficiale del laboratorio OASYS del MIT, installabile via pip install rlms. Sostituisce la classica llm.completion() con rlm.completion(). Deliberatamente task-agnostico: ti dà il paradigma, non l’applicazione. Per chi: sviluppatori che costruiscono un agente su misura.
fullstackwebdev/rlm_repl — quello che ti dice quanto spendi
Più minimale, con un merito specifico: separa la contabilità dei costi tra chiamate radice e sotto-chiamate ricorsive. In un sistema ricorsivo è il primo strumento diagnostico che ti serve. Se non converge entro max_iterations restituisce None invece di inventarsi una risposta — scelta di design da non sottovalutare. Per chi: chi deve giustificare la bolletta API.
grishahq/recursive-llm — quello prudente
Usa LiteLLM per parlare con qualunque provider (OpenAI, Anthropic, DeepSeek, Ollama, llama.cpp) ed esegue il codice generato dentro RestrictedPython invece che nell’interprete nudo. Esiste anche un porting in Go, rlm-go. Per chi: ambienti dove l’esecuzione di codice arbitrario è un problema di compliance.
PrimeIntellect-ai/prime-agent — quello completo
Il più ambizioso. Open source, si usa da terminale come alternativa a Claude Code, Codex o pi.
La scelta architetturale distintiva: non espone tool separati. Niente lettore di file, niente esecutore bash, niente editor. Espone una sola interfaccia — un kernel IPython persistente gestito da un demone in background. Qualsiasi azione, modificare un file o lanciare un test, è una chiamata a funzione Python dentro quel kernel. Anche gli agenti figli: await rlm("sub-task") avvia una sessione completa con il proprio modello e il proprio kernel, e padre e figlio si parlano in modo asincrono.
L’elemento davvero nuovo è il Continual Harness. Prime Agent tratta lo stato del proprio harness come un oggetto su cui il modello ha diritto di scrittura: prompt di sistema, specifiche dei sotto-agenti, pacchetti di skill, memoria su disco. Il comando /refine rilegge la traiettoria di esecuzione — cosa è stato tentato e cosa è successo — e applica la più piccola modifica utile.
La differenza con le wiki di memoria è netta. Una wiki conserva fatti (“il servizio X fa Y”). Il Continual Harness conserva metodologie (“per testare questo modulo serve questo flag”). Non è memoria: è apprendimento procedurale che sopravvive alla sessione. Il prompt base resta immutabile per sicurezza, le modifiche sono tracciate con ID e reversibili.
Il risultato: su ARC-AGI-3, il benchmark di ragionamento astratto, Prime Agent con Opus 5 ha riportato 95,5% RHAE Best@1 — sopra il baseline umano esperto del 95,4% — con 99,97% Best@3 e tutti i 183 livelli completati.
Per chi: chi vuole sostituire il proprio strumento CLI quotidiano su codebase grandi.
6. I numeri che pesano l’harness
| Prova | Cosa è stato tenuto costante | Effetto del solo harness |
|---|---|---|
| Composio (25 task agentici) | Modello (Kimi K3) e tool MCP | Pass rate da 88% a 68% — 20 punti |
| OOLONG, 132k token | — | RLM su GPT-5-mini batte GPT-5 nativo di +34 punti (~114%), a costo per query equivalente |
| OOLONG, 263k token | — | Vantaggio a +15 punti (~49%), ancora più economico in media |
| ARC-AGI-3 | Modello (Opus 5) | 95,5% con Prime Agent, sopra il baseline umano esperto |
| TerminalBench 2.1 | Modello (Gemini 3 Pro) | Punteggio oscilla dal 65,8% al 73,9% solo cambiando harness |
Due letture obbligatorie di questa tabella.
La prima: su OOLONG un modello piccolo, economico e cieco batte un modello di punta che ha letto tutto. Non di poco: più del doppio. Se stai valutando un upgrade di modello per gestire documenti lunghi, questo è il dato che dovresti guardare per primo.
La seconda, più scomoda: ogni punteggio pubblicato su qualsiasi leaderboard è il punteggio di una coppia modello-harness. Quando leggi che il modello X fa 73,9% su TerminalBench, stai leggendo un numero che vale otto punti in meno con un harness diverso. La domanda giusta davanti a una classifica non è più “quale modello”. È “con cosa intorno”.
E poi c’è la domanda successiva
Se l’harness conta così tanto, e oggi la scriviamo a mano, possiamo addestrare un modello a ripararla?
Il paper Harness-R1 risponde di sì, con un risultato che vale la pena raccontare per intero. Un modello da 9 miliardi di parametri, addestrato con reinforcement learning specificamente su questo compito, produce patch all’harness che portano il tasso di successo dal 44,3% al 53,6% su WebShop, ALFWorld e DBBench.
Gli stessi identici patch, prodotti da modelli di frontiera, fanno peggio:
- Harness-R1 (9B): 53,6%
- GLM-5.2: 48,8%
- GPT-5.5: 47,9%
- DeepSeek-V4-Pro: 45,9%
- Qwen3.5-397B: 45,8%
Un modello 44 volte più piccolo li supera tutti. E il motivo del fallimento dei grandi è il dettaglio più interessante di tutta la vicenda: generano modifiche plausibili sulla carta ma non testate. Ottimizzano per la verosimiglianza invece che per il risultato misurato. Su task mai visti, le patch di Qwen3.5-397B peggiorano le prestazioni di 4,3 punti. Quelle di Harness-R1, addestrato con ricompensa basata sulla riesecuzione effettiva dei task, le migliorano di 8,9.
Le patch intervengono su quattro momenti del ciclo dell’agente: inizializzazione, pre-decisione, pre-azione — il guardrail che può riscrivere o bocciare una mossa prima che venga eseguita, il più efficace dei quattro — e post-feedback per il recupero dagli errori.
Tradotto: bloccare il clic su “Acquista” prima che l’agente lo faccia senza aver selezionato la taglia vale più di dieci miliardi di parametri in più.
7. Il trabocchetto: quando l’harness peggiora le cose
Qui va detta la parte che gli slogan omettono, perché è quella che ti fa perdere soldi.
Il benchmark DeonticBench, sul ragionamento normativo, ha applicato un harness agentico strutturato a nove modelli diversi.
Sui modelli di frontiera funziona benissimo. Su SARA-Numeric i guadagni vanno da 15 a 30 punti percentuali: GPT-5.2 passa dal 30% al 60%, Claude Sonnet 4.5 dal 36% al 54%.
Sugli stessi identici test, con la stessa identica harness, i modelli più deboli crollano. Qwen3.5-35B scende dal 34% all’11%. Qwen3.5-122B dal 37% al 20%. E lo fa consumando fino a quattro volte più token.
La spiegazione degli autori è chirurgica: senza sufficiente capacità di giudizio nei pesi, lo scaffolding agentico funziona da amplificatore di sicurezza. Trasforma un ragionamento già traballante in una risposta sbagliata più lunga e più convinta. Il modello debole spende budget in cicli inutili nel terminale invece di fermarsi presto.
Torniamo ai finimenti. Un’imbracatura da corsa su un cavallo che non è pronto non lo rende veloce. Lo fa zoppicare.
La regola operativa: l’harness non crea capacità. La converte in risultato. Se non c’è niente da convertire, amplifica il rumore — e ti manda la fattura.
8. La matrice decisionale
| Se il tuo problema è… | La leva giusta | Cosa NON fare |
|---|---|---|
| Documenti o codebase enormi, il modello “perde il filo” | Harness RLM: contesto in variabile + sotto-agenti | Comprare la finestra di contesto più grande |
| L’agente sbaglia sempre nello stesso punto | Guardrail pre-azione (Harness-R1 style) | Cambiare modello |
| Costi API fuori controllo | Contabilità radice/sub, ridurre le tool call | Aumentare il budget di token |
| Modello piccolo o open source su task complessi | Semplificare l’harness, ridurre i turni | Aggiungere scaffolding agentico |
| Devi scegliere un CLI per lavorare su codebase grandi | Prime Agent o equivalente RLM | Fidarti della leaderboard del modello |
Tre regole da tenere in tasca:
1. Più chiamate non è più intelligenza. Nel test Composio, Grok Build ha fatto 402 tool call e Pi Agent 223. Stesso identico punteggio: 18/25. Un harness verboso genera fatture, non accuratezza.
2. Guarda il costo per successo, non il costo per token. Sempre nel test Composio: Hermes chiude a $0,46 per task riuscito, Claude Code a $1,96. Quattro volte tanto, stesso modello, stesso listino.
3. Prima di cambiare modello, guarda il loop. L’istinto è passare al modello più grande. Sopra una certa soglia di capacità il ritorno marginale sta nel migliorare il ciclo di controllo — gestione del contesto, recupero dagli errori, guardrail. Ed è molto più economico.
9. Quello che non c’è scritto nel README
Sicurezza. È il punto meno discusso e il più serio. Questi sistemi eseguono codice Python generato dal modello con i permessi dell’utente corrente. Non sempre in una sandbox reale. Prima di lanciare un agente RLM sulla macchina dove tieni i dati dei clienti, isolalo: container, VM o VPS dedicata. recursive-llm con RestrictedPython è l’eccezione, non la regola.
Accesso ai modelli. Questi harness parlano via API a consumo, non tramite gli abbonamenti flat delle app web. Servono chiavi API, provider alternativi tipo OpenRouter, oppure modelli locali via Ollama o vLLM. Se il tuo piano era usare l’abbonamento da 20 euro al mese che hai già, non funziona così.
Integrazione. Quasi tutte espongono modalità headless o RPC. Metterle dietro un’interfaccia diversa — un bot Telegram, un altro orchestratore da riga di comando — è lavoro di poche decine di righe, non un porting. Con un’avvertenza: se l’orchestratore esterno prova anche lui a gestire contesto ed esecuzione, i due si pestano i piedi. Lascia che quello esterno faccia solo da passacarte.
10. Conclusione
Per un decennio la strategia dominante è stata scalare i pesi. Continuerà a contare. Ma non è più l’unica leva, e in molti scenari operativi non è nemmeno la più conveniente.
Un modello grande che annega in duecentomila token perde contro un modello piccolo che sa scrivere una regex. Un modello da 397 miliardi di parametri perde contro uno da 9 miliardi che è stato addestrato a testare le proprie modifiche invece che a renderle plausibili.
Le due regole semplici: guarda l’harness, non i parametri. E guarda il costo per successo, non il costo per token.
Le classifiche dei modelli continueranno a fare rumore. Ma i venti punti che separano il tuo agente che funziona da quello che non funziona non sono nei pesi. Sono nei finimenti.
📌 Vuoi capire quale harness ha senso per la tua azienda? Entra nella community BRIX-IA: t.me/brixia_intelligenza_artificiale
Dati aggiornati ad agosto 2026.
