Negli ultimi anni gli agenti basati su grandi modelli di linguaggio (LLM) sono sempre più impiegati come sistemi multi‑agente anziché come modelli autonomi operanti in un singolo contesto. Le recenti piattaforme per agenti consentono al modello di istanziare agenti “lavoratori” e di scrivere un flusso di lavoro eseguibile che li coordina, spostando la progettazione della struttura del sistema dal programmatore al modello al momento dell’esecuzione.

Definizione di workflow orchestration e obiettivi di WorkflowArena

Questa capacità di organizzare il lavoro è stata formalizzata come workflow orchestration. A differenza dei benchmark tradizionali, che misurano solo il completamento finale del compito o valutano la coordinazione su strutture predefinite, WorkflowArena registra sia la qualità del risultato finale sia l’intera organizzazione sottostante.

Il benchmark comprende 145 compiti a lungo termine distribuiti su otto domini professionali (ingegneria del software, matematica formale, analisi legale, produzione 3D e altri) e 17 forme di task, come modifiche software, analisi di contratti, prove formali e progetti di modellazione tridimensionale.

Ogni task fornisce uno spazio di lavoro iniziale e richiede un consegna integrata composta da componenti interdipendenti. La validità della consegna è verificata da un verificatore nascosto specifico per ciascun compito, che controlla anche l’integrazione delle parti.

Meccanismo di delega e registrazione del workflow

Gli agenti possono operare da soli oppure utilizzare uno strumento di workflow per lanciare fino a 16 lavoratori concorrenti. Ogni lavoratore è una nuova istanza del medesimo modello‑harness‑effort, riceve il contesto assegnato e condivide lo spazio di lavoro. Ogni delega passa attraverso lo strumento registrato, consentendo così di analizzare la sequenza di chiamate, il numero di lavoratori coinvolti e le fasi di verifica e revisione.

Il tempo totale a disposizione è limitato a quattro ore di wall‑clock condivise tra agente principale e lavoratori: organizzare il lavoro consuma risorse che altrimenti potrebbero essere impiegate nell’esecuzione effettiva.

Il benchmark non impone una struttura predefinita, lasciando al modello la libertà di scegliere la propria organizzazione. Il metrica principale, “Overall Resolved”, è la media ponderata uguale delle percentuali di successo nei otto domini; un compito è considerato risolto solo se soddisfa tutti i criteri di accettazione specifici del dominio. Un punteggio continuo aggiuntivo ricompensa i progressi parziali.

Risultati sperimentali: performance e strategie di delega

Le prove sono state condotte su 25 configurazioni modello‑effort derivanti da nove modelli diversi. Il miglior risultato in termini di “Overall Resolved” è stato ottenuto da Claude Opus 5.5 in Claude Code a massimo sforzo, con un valore del 36,95 %. Nessuna configurazione ha raggiunto il 100 % in tutti i domini.

Le strategie di delega differiscono significativamente tra le famiglie di modelli:

Modelli Claude (Opus e Sonnet) tendono a effettuare meno chiamate di workflow per compito (media 0,86 e 0,76) ma a lanciare gruppi di lavoratori più numerosi (media 5,55 e 6,14).
Modelli GPT (Astra e Sol) effettuano più chiamate di workflow (media 2,09 e 1,94) con gruppi più piccoli (media 1,72 e 1,69).

Questi dati rappresentano le medie a sforzo elevato e non costituiscono una prova di causalità tra lo stile di delega e la performance finale.

Esempio illustrativo: costruzione 3D di un palazzo

Immaginate di chiedere a un modello di costruire un palazzo in Blender. Il progetto richiede torri, sale e muri che si intersecano correttamente, oltre a render finali e a un manifesto che riconcilia i disegni con un ordine di variazione. Il modello può scegliere di:

Dividere la costruzione tra diversi lavoratori, poi integrare e correggere i pezzi.
Organizzare le attività in una sequenza alternativa, ad esempio verificando i disegni prima di avviare la modellazione.

Il risultato finale (il modello 3D completato) non rivela quale strategia è stata adottata; WorkflowArena registra invece il flusso di lavoro scelto, rendendo possibile l’analisi comparativa.

Visualizzazione di tre task 3D

Nel benchmark sono presenti tre compiti di costruzione 3D (palazzo, cattedrale, fortezza). Le visualizzazioni mostrano come Claude Opus 5.5 in Claude Code e GPT‑6 Astra in Codex differiscono:

Nel compito “cattedrale”, i “regional builders” di Astra alimentano un “assembly worker” separato.
Nel “fortezza”, Opus analizza i disegni prima di un “central builder”, mentre Astra esegue audit sui disegni in parallelo alla costruzione.

Questi pattern di workflow sono osservabili, ma non indicano automaticamente la superiorità di uno rispetto all’altro.

Esperimento di trasferimento: isolare l’impatto del workflow

Per distinguere la capacità del lavoratore dalla qualità del workflow, gli autori hanno condotto un esperimento su un sottoinsieme difficile di 32 compiti (tutti gli otto domini). Il procedimento è stato:

Opus e Astra hanno scritto workflow a sforzo massimo.
Modelli più deboli (Kimi, Luna, Doubao, DeepSeek) hanno agito come esecutori, ogni lavoratore essendo un’istanza di quel modello.
In modalità statica, il modello sorgente scrive il workflow e poi si ferma; in modalità dinamica lancia i workflow, osserva i risultati e li revisa.
Il modello sorgente non può modificare lo spazio di lavoro; la generazione del workflow consuma il budget di tempo condiviso.

Il punteggio è continuo da 0 a 100, poiché con 32 task le percentuali di risoluzione sarebbero troppo grossolane.

Risultati dell’esperimento di trasferimento

Con l’esecutore fisso Kimi K3.1 Pro, i workflow statici di Opus hanno ottenuto 45,04 contro 29,69 per Astra. Il pattern si è mantenuto per gli altri esecutori:

Luna: 30,37 (Opus) vs 24,87 (Astra)

Doubao: 28,04 vs 22,07

DeepSeek: 21,79 vs 12,85

In media, i workflow di Opus hanno migliorato i punteggi di 6,41 punti in modalità statica e di 6,27 punti in modalità dinamica rispetto a quelli di Astra.

Poiché il modello sorgente non modifica direttamente lo spazio di lavoro, ogni miglioramento deriva esclusivamente dall’organizzazione proposta nel workflow, anche se i workflow includono istruzioni che possono trasmettere conoscenza del compito.

Interpretazioni e limiti

L’esperimento dimostra che, tenuto fisso l’esecutore, la scrittura del workflow è un fattore misurabile che influisce sui risultati. Tuttavia, non è possibile isolare se il guadagno sia dovuto alla topologia del workflow, alla sequenza di delega o al contenuto informativo delle istruzioni fornite ai lavoratori.

Inoltre, ogni configurazione è stata valutata una sola volta per compito, senza stime di varianza; ciò può influenzare la comparazione tra sistemi molto vicini in performance.

Conclusioni

WorkflowArena introduce una nuova prospettiva nella valutazione dei sistemi LLM‑based multi‑agente, spostando l’attenzione dal semplice risultato finale alla qualità dell’organizzazione sottostante. I risultati evidenziano:

Assenza di una configurazione universale dominante.

Strategie di delega divergenti tra modelli Claude e GPT.

Un impatto misurabile della qualità del workflow sulla performance degli esecutori più deboli.

Questo benchmark apre la strada a future ricerche focalizzate sulla progettazione automatica di workflow ottimali e sulla comprensione delle dinamiche di coordinazione in sistemi di intelligenza artificiale sempre più complessi.