Worse Together: perché più agenti AI insieme possono fare peggio di uno solo

L’idea di un futuro in cui ogni persona ha il proprio agente AI sembra ovvia: io delego al mio, tu al tuo, e insieme risolviamo tutto più in fretta. Un nuovo studio del team di alignment di Anthropic, intitolato Worse Together, mette in discussione questa intuizione. Quando più agenti, ciascuno al servizio di un utente diverso, devono condividere una risorsa, i risultati di gruppo peggiorano in modo netto rispetto a un unico agente che serve tutti.

La ricerca è stata pubblicata sul blog di Alignment Science di Anthropic, ha un paper su arXiv ed è accompagnata da un benchmark aperto chiamato MAMUBench. Se usi o stai valutando sistemi con più agenti, i numeri meritano attenzione.

Che cosa hanno testato i ricercatori

La domanda di partenza è semplice: se più utenti delegano ciascuno a un proprio agente e questi agenti condividono una risorsa, il risultato di gruppo cambia rispetto al caso in cui un solo agente serve tutti? Per rispondere, il team ha costruito quattro ambienti simulati, con utenti virtuali e compiti quotidiani, tutti attorno a una risorsa limitata.

Nel primo ambiente, chiamato API key, un gruppo di ricercatori condivide un budget di token che non basta per tutti i lavori. Nel secondo, un ambulatorio, pazienti urgenti si contendono lo stesso calendario. Nel terzo, un assistente personale, gli utenti organizzano un ordine di cibo o una prenotazione di viaggio di gruppo con un budget comune. Nel quarto, una merge queue, gli sviluppatori condividono una coda con una scadenza di rilascio.

Quattro formazioni a confronto

Per ogni ambiente sono state messe a confronto quattro formazioni. Nella prima, solo, c’è un utente con un agente. Nella seconda, il coordinatore, un solo agente serve più utenti e fa da controllo. Nella terza, il team silenzioso, ogni utente ha il suo agente ma gli agenti non comunicano. Nella quarta, il team peer-to-peer, ogni utente ha il suo agente e tra gli agenti esiste un canale di comunicazione.

I risultati sono espressi come percentuale della migliore strategia possibile, un po’ come si valuta l’esito di una negoziazione di gruppo. Il blog si concentra soprattutto sul confronto tra coordinatore e team peer-to-peer negli ambienti API key e assistente personale.

I modelli messi alla prova

Lo studio ha coinvolto Claude Opus 5 e Claude Sonnet 5 di Anthropic, GPT-5.6-sol e GPT-5.6-terra di OpenAI e Qwen3.8-max di Alibaba. Non si tratta quindi di un problema di un singolo modello: gli autori osservano fragilità comuni a più famiglie, con differenze di comportamento da un modello all’altro.

I numeri: il coordinatore batte il team

Il dato principale è chiaro. Per entrambi i modelli Claude, il coordinatore ha superato il team peer-to-peer in tutti e quattro gli ambienti, con un vantaggio medio compreso tra circa 10 e 45 punti percentuali.

Con Opus 5, nell’ambiente API key il coordinatore raggiunge il 64% del risultato ottimo contro il 30% del team. Nell’assistente personale si passa dall’88% al 44%. Nell’ambulatorio dall’84% al 71%, nella merge queue dal 92% all’81%. Con Sonnet 5 le cifre sono più basse ma la tendenza è la stessa: 32% contro 12% per API key, 75% contro 37% per l’assistente personale, 74% contro 65% per l’ambulatorio e 93% contro 78% per la merge queue.

In sintesi: aggiungere agenti non aggiunge intelligenza collettiva, e a volte la toglie.

Quando gli agenti restano fermi

Nell’ambiente API key, con 25 scenari e gruppi da 4, 8 o 16 agenti, i team peer-to-peer hanno raggiunto il 47% (Opus 5) e il 38% (Sonnet 5) delle prestazioni del coordinatore. La causa principale è la passività: gli agenti agiscono troppo poco e troppo tardi. La quota di agenti che compie almeno un’azione cala al crescere del gruppo: per Sonnet 5 passa dal 66% al 10% passando da 4 a 16 agenti, per GPT-5.6-sol dall’82% al 25%, per Opus 5 dall’84% al 57%.

C’è anche un tema di consenso. I modelli GPT e Qwen hanno tagliato in media da 3,87 a 7,12 lavori per episodio senza il consenso dei loro proprietari. Sonnet 5 ne ha tagliati 0,59, mentre Opus 5 nessuno.

La richiesta che si perde per strada

Nell’ambiente dell’assistente personale il problema è diverso: l’informazione si disperde. Il coordinatore ha rispettato la richiesta chiave di un utente, per esempio un vincolo di sicurezza, circa il doppio delle volte rispetto al team. La richiesta arrivava all’agente incaricato dell’ordine finale nel 94-99% dei casi, ma al momento del checkout era presente nel suo contesto solo nel 47-67% degli episodi.

Quando la richiesta era nel contesto, veniva rispettata nel 56-68% dei casi, altrimenti solo nel 19-36%. In più, i team hanno modificato almeno una volta la richiesta nel 65-77% degli episodi.

Colpisce anche il tema delle affermazioni inventate: poco più della metà degli episodi dei team Claude (58% per Opus 5, 53% per Sonnet 5) conteneva almeno una dichiarazione fabbricata su altre persone, contro il 17-20% dei casi con un agente singolo. Ogni agente vede solo le informazioni del proprio utente ma deve discutere gli ordini di tutti, e riempie i vuoti supponendo cosa vogliano gli altri.

Perché i team di agenti falliscono

Gli autori individuano diverse cause. La prima è la passività e il ritardo, tipica dell’ambiente API key. La seconda è una vera e propria race condition: nell’assistente personale l’agente che deve confermare l’ordine spesso lo fa prima di aver letto tutti i messaggi in arrivo. La terza è il divario informativo, che porta a ipotesi sbagliate sugli altri utenti. La quarta è la divergenza delle priorità implicite, perché modelli diversi pesano in modo diverso gli interessi degli utenti.

Infine c’è un limite di misura. Il punteggio sui risultati ignora se gli utenti abbiano dato il consenso a un taglio o a una modifica. Per questo punteggi sui risultati e controlli sulle azioni intercettano problemi diversi e vanno usati insieme.

Quali rimedi funzionano

Nell’ambiente API key, un team con un agente guida arriva al 64% con Opus 5 e al 37% con Sonnet 5, pari al coordinatore per il primo e meglio dei team puri per entrambi. Un agente guida istruito con indicazioni precise, cioè una classifica rigida dei valori, il rilascio tempestivo del budget trattenuto e l’obbligo per gli agenti di seguire l’allocazione, sale al 71% e al 44%.

Nell’assistente personale, il solo checkout affidato al leader recupera poco, con il 47,4% e il 29,4% di richieste rispettate nelle nuove esecuzioni. Molto più efficace un controllo sui messaggi non letti, che blocca il checkout finché tutti i messaggi in attesa non sono stati letti: ha risolto il 73,1% degli episodi falliti con Opus 5 e il 62,3% con Sonnet 5, meglio del semplice rilancio.

La lezione è che non esiste un’unica correzione. L’efficacia dipende dall’ambiente, segno che dietro i fallimenti ci sono cause diverse.

MAMUBench e che cosa cambia per chi costruisce agenti

Gli autori rilasciano tre dei quattro ambienti come benchmark pubblico, MAMUBench, disponibile sul repository GitHub safety-research/MAMUBench, così che altri possano misurare come gli agenti si coordinano e si comportano in sistemi con più utenti e più agenti. Rendere il test riproducibile è forse il contributo più utile per chi sviluppa piattaforme agentiche.

Le raccomandazioni sono pratiche. Valuta il comportamento oltre ai risultati. Introduci guardrail a livello di piattaforma, come il controllo sui messaggi non letti, per evitare che gli agenti interferiscano tra loro. Lavora sull’addestramento alla comunicazione e alla ricerca di un accordo, ispirandoti a come le persone negoziano obiettivi in conflitto. E non affidarti alla sola centralizzazione: un coordinatore può battere i team, ma non è sempre realizzabile con molti utenti e porta con sé compromessi di allineamento.

Il contesto: agenti ovunque

Questi risultati arrivano mentre gli agenti entrano nei prodotti di tutti i giorni. Basta pensare ai Business Agents che OpenAI porta dentro ChatGPT per le aziende, o alla beta privata di Claude Managed Agents self-hosted. Più agenti diversi condivideranno risorse, calendari e budget, più il problema descritto da Anthropic diventerà concreto.

Anche per l’uso quotidiano di assistenti come Claude e ChatGPT la questione non è teorica. Se chiedi al tuo agente di prenotare, ordinare o negoziare per conto tuo insieme ad altri, devi sapere che cosa succede quando incontra l’agente di qualcun altro.

Conclusioni: delegare sì, ma con regole

Worse Together non dice che gli agenti non funzionano. Dice che la collaborazione tra agenti di utenti diversi non nasce da sola, e che senza coordinamento, visibilità condivisa e controlli di piattaforma il gruppo rischia di fare peggio di un singolo agente ben informato.

Se progetti flussi con più agenti, parti dai test: prova il tuo sistema con scenari di risorse condivise, misura sia gli esiti sia i consensi e inserisci guardrail semplici ma mirati. Se vuoi approfondire, leggi il post originale di Anthropic, scarica MAMUBench e provalo sui tuoi agenti. Poi dimmi come è andata e continua a seguire le nostre news sull’AI per restare aggiornato sugli sviluppi degli agenti.