Il modello migliore non esiste: negli agenti AI conta la coppia con l’harness

Quando si confrontano agenti AI, la tentazione è quasi sempre la stessa: prendere il modello con il punteggio più alto, mettergli intorno qualche tool e considerare il problema risolto. È una scorciatoia comoda. Ed è anche il modo più rapido per misurare la cosa sbagliata.

Un nuovo lavoro, Finding the Right Fit: Model-Harness Interactions across Agent Tasks, mette numeri dietro a un sospetto che chi costruisce sistemi agentici incontra presto: la prestazione non appartiene soltanto al modello. Appartiene alla combinazione tra modello, harness e tipo di compito.

Gli autori hanno valutato 66 configurazioni: quattro harness configurabili — OpenHands, DeepSeek Harness, PI e openJiuwen — combinati con cinque modelli su TUA-Bench, ALE-CLI e Terminal-Bench 4, più le coppie native Codex-GPT e Claude Code-Claude. Il risultato più utile non è una classifica. È proprio il fatto che la classifica cambia quando cambia ciò che sta attorno al modello.

Il benchmark non sta misurando un cervello isolato

Un agente non riceve semplicemente una domanda e restituisce testo. Riceve contesto, vede una certa rappresentazione dei tool, esegue azioni, ottiene errori, conserva o perde stato, decide se ritentare e infine deve produrre qualcosa che il sistema possa verificare. Tutto questo è harness.

Nel paper l’interazione è abbastanza forte da invertire il confronto tra modelli. Su Terminal-Bench 4, Claude supera GPT di 7,94 punti dentro OpenHands; dentro PI, invece, resta indietro di 30,16 punti. Stessi nomi sulle scatole, risultato completamente diverso quando cambia il sistema che li fa lavorare.

La domanda utile non è “qual è il modello migliore?”, ma “quale combinazione modello, harness e task produce il comportamento che posso verificare?”.

È una differenza meno cosmetica di quanto sembri. Se il benchmark valuta un agente operativo, attribuire tutto il risultato al modello equivale a valutare un pilota ignorando macchina, gomme, telemetria e circuito. Il logo del modello è solo una parte del sistema.

L’harness modifica il problema che il modello vede

La parte più interessante dello studio arriva dalle traiettorie. Gli autori osservano che i modelli avviano quasi sempre autonomamente i tentativi di riparazione; ciò che cambia è quanto bene l’harness restituisce il fallimento in una forma che il modello riesce a usare. GPT rende meglio con lo scaffold più snello di PI, mentre Kimi — che nelle traiettorie produce più spesso tool call malformate — ottiene i suoi risultati migliori con openJiuwen.

Questo si collega direttamente a un problema che avevo già affrontato parlando di errori e action space negli agenti: un errore non è soltanto una stringa da stampare in console. È informazione operativa. Se l’harness la comprime male, la nasconde, la restituisce fuori contesto o rende ambiguo il prossimo passo, un modello capace può sembrare improvvisamente mediocre.

Lo stesso vale per la selezione degli strumenti. Dare a un agente tutto ciò che potrebbe teoricamente usare non significa aiutarlo. Come nel problema del tool retrieval sotto vincoli di budget, la qualità dipende anche da come restringiamo lo spazio delle azioni e da quale informazione rendiamo disponibile nel momento giusto.

Il vendor harness non è automaticamente il posto migliore

C’è poi un risultato che dovrebbe rendere un po’ più prudenti nelle decisioni di acquisto: nello studio, l’harness fornito dal vendor del modello non è sistematicamente quello che produce il risultato migliore. E nemmeno spendere di più garantisce un punteggio superiore.

Su Terminal-Bench 4, per esempio, GPT sotto PI ottiene un risultato migliore rispetto a DeepSeek Harness con un costo per task inferiore a un quarto. Non significa che PI sia “il migliore”: sarebbe esattamente la conclusione che il paper invita a non trarre. Per quattro dei cinque modelli considerati, infatti, l’harness migliore cambia passando da un benchmark all’altro.

Esistono anche accoppiamenti più stabili: openJiuwen dà a Kimi il suo punteggio più alto su tutti e tre i benchmark, con vantaggi tra 5,61 e 11,11 punti. Ma questa è una proprietà osservata di quella coppia su quei task, non una legge generale.

Un benchmark serio deve diventare una matrice

Da qui deriva una conseguenza pratica. Se stiamo scegliendo la tecnologia per un sistema agentico reale, confrontare soltanto i modelli è insufficiente. Dovremmo costruire una matrice almeno su tre assi: modello, harness e famiglia di task.

• Modello: capacità di ragionamento, tool use, gestione del contesto, costo e latenza.
• Harness: prompt di sistema, rappresentazione dei tool, gestione degli errori, memoria, retry, permission boundary e checkpoint.
• Task: durata, numero di strumenti, necessità di stato, verificabilità dell’output e costo del fallimento.

La metrica finale, poi, non dovrebbe essere solo “task completato”. Servono almeno costo per risultato verificato, numero di tentativi, failure mode e qualità dell’artefatto. Un agente che dichiara di aver finito non è necessariamente un agente che ha finito: è il motivo per cui considero centrale verificare ciò che consegna, non ciò che racconta di aver fatto.

Perché questo cambia anche come si progetta un orchestratore

Se il comportamento emerge dalla coppia modello-harness, allora l’harness non può essere trattato come plumbing neutro. È parte dell’architettura cognitiva del sistema. La forma degli errori, il numero di tool esposti, l’ordine del contesto, i checkpoint e persino il modo in cui una run viene ripresa dopo un’interruzione possono spostare il risultato.

Questo non significa costruire uno scaffold enorme. Anzi, il paper mostra proprio che più infrastruttura non equivale automaticamente a più qualità. Significa progettare l’harness come progetteremmo qualsiasi altro componente critico: con ipotesi esplicite, telemetria, test ripetibili e possibilità di sostituire una parte senza riscrivere tutto.

Un harness è buono quando rende il modello più verificabile e adatto al compito, non quando contiene più automazioni.

È anche il motivo per cui le architetture agentiche dovrebbero evitare di fondere identità del modello e logica di orchestrazione. Se domani un modello diverso funziona meglio con lo stesso workflow, oppure lo stesso modello migliora cambiando il modo in cui riceve feedback dai tool, dobbiamo poterlo misurare senza rifare il sistema da zero.

La scelta pratica: testare coppie, non tifare per modelli

Il lavoro rilascia anche adapter, codice di valutazione e 6.204 traiettorie valutate. È importante perché consente di guardare oltre il numero finale e capire dove le coppie divergono. Ma per un’azienda il benchmark più utile resta quello costruito sui propri task.

Prenderei dieci o venti attività ripetitive con un criterio di successo verificabile, sceglierei due o tre modelli e due configurazioni di harness realmente plausibili, poi misurerei le combinazioni. Stesso input, stesso ambiente, stesso limite di costo, stesso verificatore. Solo così il confronto smette di essere marketing travestito da ingegneria.

Il punto non è smettere di valutare i modelli. È smettere di fingere che lavorino nel vuoto. Quando un agente deve davvero leggere, decidere, chiamare strumenti, recuperare da un errore e lasciare un risultato verificabile, il sistema che gli sta attorno entra nella misura. E a quel punto comprare “il modello migliore” senza testare l’harness giusto rischia di essere una costosa forma di superstizione tecnica.