Stesso modello, tre agenti: cosa ci dice davvero il confronto IBM su CUGA

Lo stesso modello linguistico può ottenere risultati molto diversi quando cambia il software che lo collega agli strumenti? Un confronto pubblicato da IBM Research mette sul tavolo proprio questa domanda: CUGA, Hermes e Deep Agents hanno affrontato 90 task del benchmark AppWorld usando tutti GLM-5.3-Flash. I risultati dichiarati dagli autori sono 73 task completati per CUGA, 42 per Hermes e 27 per Deep Agents. La differenza è notevole, ma leggere quei numeri come una classifica definitiva sarebbe un errore.

In questo approfondimento ricostruiamo che cosa è stato misurato, che cosa significa la parola harness, quali dettagli del setup rendono il confronto interessante e quali limiti IBM stessa segnala. Non abbiamo eseguito noi quei 90 task: i punteggi sono attribuiti all’esperimento descritto da IBM Research, non a una prova GeekAndHack.

Fonte: Guarda il video breve su YouTube — Il video è programmato per l’11 novembre 2026 alle 10:00, ora di Roma.

La risposta breve: modello uguale, contesto diverso

Un modello fornisce capacità linguistiche e di ragionamento, ma un agente operativo è anche il ciclo che decide quali strumenti mostrare, come suddividere il lavoro, quando eseguire un’azione e come controllare il risultato. Questo strato viene spesso chiamato harness. È una cornice software: organizza l’interazione fra modello, istruzioni, strumenti, ambiente e controlli.

La formula ‘stesso modello, harness diverso’ è utile perché sposta l’attenzione dalla sola scelta del modello. Non significa però che il benchmark abbia isolato ogni variabile come in un esperimento perfettamente identico. L’articolo IBM dichiara che le configurazioni non erano uguali: CUGA usava una configurazione dedicata ad AppWorld; Hermes usava la configurazione predefinita di Harbor con strumenti AppWorld via MCP; Deep Agents usava strumenti via MCP e middleware LangChain, con due correzioni per gestire risposte GLM malformate.

Che cosa hanno confrontato gli autori

Secondo IBM Research, i tre harness sono stati valutati sul benchmark AppWorld: 90 task distribuiti in 30 scenari, con un tentativo per task. Tutti i run dichiarati impiegavano il modello open-weight GLM-5.3-Flash e il framework di valutazione Harbor. Il codice e le configurazioni del confronto sono indicati nel repository harbor-eval del progetto CUGA.

AppWorld simula attività articolate attraverso applicazioni e API. Non è un test generale di ogni lavoro d’ufficio, né una prova automatica della qualità di un agente in qualsiasi CRM, IDE o ambiente aziendale. Il suo valore è più circoscritto: permette di osservare come un sistema affronta una serie definita di compiti multi-step in un ambiente riproducibile.

• Modello dichiarato per tutti: GLM-5.3-Flash.
• Campione dichiarato: 90 task, organizzati in 30 scenari.
• Tentativi: uno per task.
• Valutazione: task completati e scenari in cui tutte le varianti previste risultano completate.
• Risultati e interpretazione provengono dall’articolo IBM Research; non sono misure indipendenti di GeekAndHack.

I risultati: 73, 42 e 27 task completati

La metrica chiamata Task Goal Completion (TGC) conta quanti task sono stati superati. Nella tabella pubblicata, CUGA raggiunge 73 su 90, pari all’81,1%; Hermes 42 su 90, pari al 46,7%; Deep Agents 27 su 90, pari al 30,0%. Questi sono conteggi riportati dall’articolo del team CUGA su Hugging Face, non risultati ricalcolati da noi sui log grezzi.

IBM riporta anche la Scenario Goal Completion (SGC): uno scenario viene contato come riuscito quando tutte e tre le varianti di task associate risultano completate. In questa lettura, CUGA ottiene 20 scenari su 30, Hermes 8 e Deep Agents 2. SGC premia quindi la costanza all’interno dello scenario più di un singolo successo isolato. Non va confusa con il numero totale dei task completati.

Per capire il significato pratico, immagina un flusso composto da più passaggi collegati. Un agente può riuscire in alcuni passaggi e fallire nel complesso; una metrica che guarda solo i singoli task e una che richiede la riuscita di tutte le varianti raccontano aspetti diversi. Nessuna delle due, presa da sola, descrive affidabilità, costo, latenza, sicurezza o facilità d’integrazione in produzione.

Perché il termine harness conta nello sviluppo degli agenti

Nell’uso comune, ‘framework’ può indicare librerie e strumenti per costruire applicazioni. ‘Harness’ qui descrive l’ambiente operativo che avvolge il modello e ne orchestra il lavoro: pianificazione, accesso ai tool, memoria o contesto, esecuzione e verifiche. Le caratteristiche esatte dipendono dal prodotto e dalla configurazione, quindi il nome da solo non basta a prevedere il risultato.

Nella configurazione descritta da IBM, CUGA suddivide il task, restringe gli strumenti disponibili per ciascun passaggio, consente al modello di generare codice per agire sulle API, verifica il codice prima dell’esecuzione e riflette sui risultati. IBM attribuisce a queste scelte il comportamento osservato nel proprio setup. Il punto interessante per chi sviluppa agenti è progettuale: non basta chiedersi quale modello usare; bisogna specificare strumenti, orchestrazione, controlli e ambiente.

La distinzione non implica che Hermes o Deep Agents siano inferiori in ogni uso. Lo stesso articolo IBM presenta Hermes come orientato ad assistenti personali sempre disponibili e Deep Agents come soluzione per lavori lunghi e articolati. Se il benchmark premia attività multi-app via API, la configurazione più adatta a quel compito può ottenere un vantaggio che non si trasferisce automaticamente alla programmazione da terminale, alla ricerca sul web o a un assistente personale.

Un limite decisivo: il test non ha misurato le policy

CUGA viene associato anche a controlli e policy di esecuzione. È importante non attribuire a questi meccanismi il risultato 73 su 90: gli autori dichiarano esplicitamente che le policy non erano attive nei run del confronto. Quel benchmark, così com’è stato descritto, non dimostra che le policy abbiano aumentato il punteggio o che blocchino ogni azione non consentita.

Questa precisazione aiuta a separare due domande. La prima è quanto spesso l’agente completa i task in uno specifico benchmark. La seconda è se il sistema rispetta regole operative quando deve usare strumenti reali. Per affrontare la seconda servono test specifici: regole applicabili, tentativi di elusione, verifiche delle chiamate ai tool e log che dimostrino cosa è stato effettivamente bloccato. Un punteggio di completamento non sostituisce un audit di sicurezza.

Tre cautele prima di usare i numeri

• Campione limitato: sono 90 task su un singolo benchmark; IBM avverte che i risultati potrebbero non generalizzarsi ad altri compiti.
• Configurazioni non identiche: CUGA aveva una configurazione AppWorld dedicata; per Deep Agents sono state applicate due correzioni ai messaggi GLM malformati.
• Nessuna misura delle policy: gli autori specificano che i run non le usavano, quindi il confronto non misura il loro enforcement.
• Un modello e un tentativo: la valutazione riportata riguarda GLM-5.3-Flash e un solo tentativo per task; non descrive ogni modello, temperatura o strategia di retry.
• Risultato dichiarato dal team: il confronto è pubblicato dagli autori del progetto CUGA. La presenza di una configurazione pubblica rende possibile approfondire o replicare il lavoro, ma non trasforma automaticamente il post in una valutazione indipendente.

Come interpretare il confronto se stai scegliendo un agente

La prima domanda utile è quale lavoro vuoi automatizzare. Una sequenza di chiamate a più API aziendali richiede strumenti, permessi e verifiche diversi da un agente che scrive codice in un repository. Per un assistente personale possono contare continuità e integrazione con chat; per ricerca e analisi, gestione del contesto e pianificazione; per operazioni con effetti reali, autorizzazioni, tracciabilità e possibilità di fermare l’esecuzione.

Poi serve un test vicino al tuo caso d’uso. Definisci input realistici ma non sensibili, criteri di successo verificabili, un numero adeguato di ripetizioni e condizioni uguali per gli strumenti che vuoi confrontare. Registra fallimenti, chiamate inutili, tempo e interventi umani, non soltanto la risposta finale. Se il sistema può modificare dati, inizia con strumenti mock o in sola lettura e aggiungi una revisione umana prima di abilitare azioni reali.

• Scrivi una lista di task rappresentativi del tuo flusso, includendo casi normali e casi ambigui.
• Mantieni invariati modello, versione, prompt di base, tool e ambiente quando vuoi isolare una variabile.
• Ripeti i task: una singola esecuzione non misura la stabilità.
• Registra passaggi completati, errori, recuperi, tempo, uso dei tool e correzioni umane.
• Separa la qualità della risposta dall’autorizzazione ad agire: una risposta corretta non garantisce un’azione sicura.
• Prova prima in sandbox o con dati fittizi; aumenta i permessi solo dopo aver verificato i controlli.

Questa procedura non replica AppWorld e non produce un punteggio confrontabile con il 73/90 IBM. È un modo per valutare i tuoi requisiti con i tuoi strumenti. Se vuoi replicare il benchmark originale, parti dalle configurazioni e dalle istruzioni pubblicate nel repository di valutazione e controlla le versioni effettive prima di lanciare i run.

Il verdetto: un segnale utile, non una classifica universale

Il dato più interessante del confronto è che il contesto software attorno al modello può accompagnarsi a differenze ampie su uno specifico insieme di task. Il risultato riportato da IBM è un invito a misurare l’intero sistema, non soltanto il modello. Ma campione, obiettivo e configurazioni delimitano ciò che possiamo concludere.

CUGA risulta primo nei numeri presentati per questo test AppWorld; questo non basta a dire che sia il miglior agente per ogni sviluppatore, impresa o attività. Hermes e Deep Agents possono essere più adatti ad altri lavori. E i punteggi del benchmark non dimostrano da soli la sicurezza o il rispetto delle policy. La scelta corretta parte dai task reali, da misure ripetibili e dai controlli che non vuoi delegare al modello.

Nel video breve confrontiamo i numeri e spieghiamo perché ‘stesso modello’ non significa ‘stesso esperimento in ogni dettaglio’. Se hai un caso d’uso concreto, scrivi quale attività vuoi affidare a un agente e quali strumenti dovrebbe poter usare: è da lì che parte un confronto serio.

Fonti e approfondimenti

Fonte dei punteggi e dei caveat: articolo di IBM Research pubblicato su Hugging Face il 3 novembre 2026. Le descrizioni dei prodotti sono ricondotte ai repository o alla documentazione ufficiale dei rispettivi progetti.

Fonte: IBM Research — Same Model, Different Harness: CUGA, Hermes, and Deep Agents — Fonte primaria dei risultati 73/90, 42/90 e 27/90, del metodo dichiarato e dei limiti esplicitati dagli autori.

Fonte: Repository CUGA Agent — Codice, documentazione e configurazioni del progetto CUGA.

Fonte: Repository CUGA Harbor Eval — Repository indicato dagli autori per le configurazioni del confronto su AppWorld.

Fonte: AppWorld — Pagina ufficiale del benchmark citato nell’articolo IBM.

Fonte: Documentazione ufficiale Deep Agents — Panoramica delle funzionalità e dell’architettura Deep Agents.

Fonte: Hermes Agent — documentazione ufficiale — Documentazione del progetto Hermes Agent.