Agenti AI: quando basta un solo agente e quando serve un team

Quando progetti sistemi con agenti AI, parti da 1 agente e da strumenti migliori. I sistemi multiagente hanno senso quando i singoli agenti possono svolgere ricerche indipendenti, lavorare con contesti diversi o assumersi la responsabilità di compiti distinti. Un pianificatore, un ricercatore, un programmatore e un revisore che hanno continuamente bisogno delle stesse informazioni rischiano di generare più lavoro di coordinamento che progressi utili.

La domanda decisiva è questa: un agente può ricevere un incarico chiaro, svolgere un lavoro utile senza consultarsi di continuo con gli altri e restituire un risultato verificabile? Se la risposta è no, suddividere il lavoro tra più agenti di solito sposta la complessità nei messaggi che si scambiano.

Il funzionamento dei framework descritto di seguito è stato verificato sulla documentazione ufficiale disponibile online il 26 ottobre 2026. La tabella decisionale applica i modelli documentati ad attività comuni nello sviluppo di applicazioni.

Agenti AI e sistemi multiagente: che cosa sono?

Un sistema multiagente affida a più agenti parti di un lavoro più ampio e fornisce loro un modo per scambiarsi il lavoro svolto. In un'applicazione basata su un modello linguistico di grandi dimensioni (LLM), un agente è un modello che opera all'interno di un ciclo: può scegliere strumenti, esaminarne i risultati e decidere come procedere. Più agenti coordinano queste decisioni, invece di concentrarle tutte in un unico agente. La panoramica di IBM descrive la struttura generale di un sistema di agenti che interagiscono.

Gli agenti possono usare lo stesso modello di base. A renderli distinti sono il contesto di esecuzione e le responsabilità, non i nomi dei modelli. A un ricercatore, per esempio, puoi fornire documenti di riferimento e strumenti di ricerca; a un programmatore, il repository e una richiesta di modifica precisa.

Pensa a un produttore musicale che combina tracce registrate separatamente. Registrare in autonomia funziona quando i musicisti hanno concordato l'arrangiamento. Se tutti cambiano il tempo e riscrivono lo stesso passaggio, il produttore passa la sessione a conciliare registrazioni incompatibili. Anche i team di agenti devono scegliere tra lavoro indipendente e coordinamento continuo.

Sistemi multiagente nell'AI: di quale scelta parliamo?

Il settore comprende anche robot, veicoli autonomi e simulazioni, come spiega la panoramica di Google Cloud. Qui ci occupiamo della scelta tra agenti LLM impegnati in ricerca, sviluppo software e attività aziendali.

Effettuare più chiamate a un modello non rende automaticamente un sistema multiagente. Un agente che cerca informazioni, legge un file, scrive codice e verifica il proprio lavoro può restare un unico agente dall'inizio alla fine. Anche una sequenza fissa di prompt può essere un workflow senza agenti autonomi. La distinzione sta in chi può prendere decisioni e nel contesto che usa per farlo.

Per capire come funzionano le chiamate al modello, gli strumenti e le condizioni di arresto, parti dal ciclo di un agente. L'architettura di un agente AI, nel suo insieme, richiede comunque stato, permessi e risultati osservabili, a prescindere dal numero di agenti.

Come progettare un sistema multiagente in base al lavoro da svolgere

Scegli più agenti quando separarli elimina più complessità di quanta ne introduca. Una separazione utile distingue fonti, competenze o responsabilità. Una separazione puramente formale si limita ad assegnare una qualifica professionale al prompt successivo.

Prima di scegliere un framework, usa questi punti di partenza:

Per chi fonda un'impresa, questo significa che la prima versione di un assistente non ha bisogno di un organigramma. Per chi lo sviluppa, significa individuare la dipendenza che impedisce a un agente di procedere da solo. Per chi lo gestisce, significa valutare il caso portato a termine, comprese le correzioni, anziché contare quanti specialisti hanno partecipato.

La consueta combinazione di pianificatore, ricercatore, programmatore e revisore è un elenco utile di attività. Non è automaticamente un elenco utile di processi. La pianificazione può avvenire all'interno dell'agente di programmazione. La ricerca può essere una chiamata a uno strumento. La revisione può iniziare con test dall'esito netto: superato o fallito.

Immagina di dover correggere l'esportazione delle fatture. Se il piano dipende dallo schema del database e durante l'implementazione emerge un'eccezione in quello schema, un pianificatore separato deve ricevere continui aggiornamenti. Meglio tenere vicine pianificazione e implementazione. Un revisore separato può comunque essere utile, purché riceva la patch finale, i requisiti dell'esportazione e i risultati dei test pertinenti.

I modelli di architettura multiagente

I modelli si distinguono soprattutto per chi è responsabile della risposta e per la quantità di informazioni che passa da un agente all'altro. Supervisore, gerarchia, passaggio di controllo e chat di gruppo sono configurazioni combinabili, non categorie di prodotto che si escludono a vicenda.

Supervisore o orchestratore con agenti esecutori: un agente risponde del risultato

LangGraph, un runtime per workflow di agenti con stato, supporta un supervisore che delega attività circoscritte e ne combina i risultati. Il supervisore mantiene la responsabilità del risultato presentato all'utente; gli agenti esecutori restituiscono riscontri o elaborati.

Nell'attuale tutorial di LangChain sul supervisore, gli agenti per calendario ed email sono esposti come strumenti di alto livello. Il supervisore richiama questi strumenti e riceve le risposte finali degli specialisti. Non ha bisogno di includere nella propria conversazione tutte le operazioni intermedie.

C'è una distinzione importante nell'implementazione: la documentazione di riferimento di langgraph-supervisor descrive ancora create_supervisor, ma per la maggior parte dei casi d'uso consiglia di implementare il modello del supervisore direttamente tramite strumenti. Questo offre un controllo maggiore sul contesto che gli agenti ricevono e restituiscono. Il pacchetto documenta anche supervisori che gestiscono altri supervisori.

Scegli questo modello per un rapporto di ricerca composto da domande indipendenti: studiare le funzionalità di un prodotto, esaminare le dipendenze tecniche e raccogliere riscontri da gruppi di fonti separati. Ogni agente può portare a termine un incarico significativo, mentre il coordinatore resta responsabile della risposta complessiva.

Il limite è l'integrazione. Se ogni agente ha bisogno dell'ultima scoperta di tutti gli altri, il supervisore diventa un messaggero. E non può colmare una lacuna nelle fonti semplicemente scrivendo una sintesi dal tono sicuro.

Team gerarchici: delegare attraverso responsabili intermedi

CrewAI, un framework per coordinare agenti basati su ruoli, organizza un gruppo di lavoro attorno ad agenti, compiti e un processo di esecuzione. Il suo processo gerarchico usa Process.hierarchical con manager_llm oppure manager_agent. Il responsabile assegna il lavoro, controlla gli output e decide se i compiti sono conclusi.

Una gerarchia può includere responsabili che supervisionano interi team, ma un gruppo gerarchico di CrewAI non implica di per sé un'organizzazione con molti livelli annidati. CrewAI supporta anche Process.sequential, in cui i compiti seguono l'ordine definito. Sono scelte di esecuzione diverse, non nomi intercambiabili per indicare la collaborazione.

Considera una valutazione di prodotto con un filone di ricerca e uno di implementazione. Una gerarchia è plausibile quando ogni filone ha già responsabilità coerenti e produce un risultato ben definito. È molto meno convincente quando l'intero lavoro consiste in una risposta breve e i responsabili si limitano soprattutto a riformulare le istruzioni degli altri.

Il limite è il costo del coordinamento. Ogni livello deve interpretare l'incarico e comunicare il proprio risultato. Aggiungi un livello perché il lavoro richiede davvero team distinti, non perché un'azienda fatta di persone ha dei reparti.

Handoff: lo specialista prende in carico la conversazione

OpenAI Agents SDK, una libreria per eseguire agenti e strumenti, implementa gli handoff come trasferimenti di controllo a un altro agente. La configurazione handoffs elenca gli agenti destinatari a cui un agente può delegare. Lo specialista che riceve il controllo diventa responsabile della risposta successiva. È diverso dal richiamare uno specialista con as_tool(), caso in cui il responsabile principale mantiene il controllo della risposta. La documentazione di OpenAI sull'orchestrazione esplicita questa distinzione.

Una conversazione di assistenza chiarisce la differenza. Se uno specialista della fatturazione deve fare domande di approfondimento e risolvere un problema con una fattura, ha senso passargli la conversazione. Se all'assistente principale serve soltanto un calcolo di fatturazione per rispondere a una domanda più ampia, possono bastare uno strumento o una chiamata circoscritta a uno specialista.

Il limite è il passaggio di consegne. L'agente che subentra ha bisogno dei fatti rilevanti, delle domande ancora aperte e dei permessi necessari. Un handoff non garantisce che tutto il lavoro precedente sia corretto, né che lo specialista sia autorizzato a compiere qualsiasi azione. Il codice dell'applicazione deve far rispettare le regole di accesso e approvazione.

Usa gli handoff quando deve cambiare il responsabile della conversazione. Impiegarli solo per attribuire un personaggio diverso a ogni fase moltiplica le occasioni di perdere contesto.

Chat di gruppo: gli agenti lavorano in una conversazione condivisa

Microsoft Agent Framework, un framework per creare applicazioni e workflow con agenti, implementa la chat di gruppo con un orchestratore che decide chi interviene. Il suo GroupChatBuilder per Python supporta una funzione di selezione oppure un orchestratore basato su un agente, insieme a una condizione di terminazione. I partecipanti hanno sessioni separate la cui cronologia delle conversazioni viene sincronizzata. La documentazione di Microsoft sulla chat di gruppo descrive il meccanismo.

Questo modello si adatta a una proposta che migliora attraverso l'interazione: un autore rivede la bozza dopo che un revisore ha individuato un requisito mancante, poi un altro specialista verifica l'argomentazione aggiornata. A differenza dei rami di ricerca indipendenti, qui gli interventi successivi dipendono intenzionalmente dai contributi precedenti.

Il limite è la crescita della conversazione. I partecipanti possono consumare i propri turni discutendo il lavoro invece di modificarlo. Una discussione condivisa espone inoltre gli agenti alla stessa premessa sbagliata. Il consenso all'interno di quella conversazione non equivale a una verifica indipendente.

Assegna alla chat di gruppo un elaborato da migliorare, una condizione di accettazione concreta e una regola di arresto. Per un'attività con un ordine fisso evidente, un workflow semplice è di solito più facile da comprendere.

Il confronto tra framework per agenti AI affronta la scelta complessiva dell'implementazione. Una volta stabilito che la suddivisione è giustificata, la guida all'orchestrazione degli agenti AI tratta coordinamento, stato, approvazioni e controlli operativi.

Esempi di sistemi multiagente: quando dividere il lavoro aiuta

La ricerca ad ampio raggio è un punto di partenza più convincente delle modifiche strettamente interdipendenti. Il sistema Research documentato da Anthropic usa un agente coordinatore e agenti che lavorano in parallelo su direzioni diverse, per poi restituire i risultati. Nella valutazione interna pubblicata, un coordinatore Claude Opus 4 con sottoagenti Claude Sonnet 4 ha superato del 90.2% le prestazioni di Claude Opus 4 usato come agente singolo. Si tratta del miglioramento relativo riportato in quella valutazione sulla ricerca, non di un tasso di successo del 90.2% né di un vantaggio universale ottenibile aggiungendo agenti. Il confronto modifica anche la configurazione dei modelli e delle risorse di calcolo. Il resoconto tecnico di Anthropic.

Per chi sviluppa un'applicazione e valuta diverse opzioni di integrazione, un'attività analoga consiste nell'esaminare in modo indipendente la documentazione di ciascun candidato e restituire riscontri rispetto agli stessi requisiti. La decisione finale richiede comunque qualcuno che risolva le contraddizioni tra le affermazioni e le lacune informative. La ricerca parallela può ampliare le informazioni disponibili; non può renderle concordanti quando sono incompatibili.

La programmazione presenta dipendenze diverse. Agenti indipendenti potrebbero esaminare il codice di autenticazione, individuare i test pertinenti e studiare il comportamento documentato di una libreria. Sono indagini circoscritte. Far riscrivere contemporaneamente lo stesso flusso di autenticazione a più agenti è molto più difficile, perché le loro decisioni possono invalidarsi a vicenda.

Nell'assistenza clienti, la separazione risponde a un'altra esigenza: la responsabilità. Un assistente generalista può identificare il problema, mentre uno specialista gestisce un ambito distinto. Il vantaggio deriva dalle istruzioni e dagli strumenti più mirati dello specialista, non dall'allungare la conversazione.

Questi scenari di programmazione e assistenza sono esempi progettuali, non implementazioni documentate o miglioramenti misurati. La loro utilità dipende da una domanda: l'agente proposto può fare qualcosa che quello originale non riuscirebbe a svolgere altrettanto chiaramente con uno strumento migliore o un prompt più preciso?

Perché i sistemi multiagente basati su LLM falliscono?

Possono fallire nei passaggi tra agenti, anche quando ciascuno sembra competente se valutato da solo. Aumentare gli agenti significa moltiplicare gli incarichi da interpretare, i risultati intermedi di cui fidarsi e i punti in cui il requisito originale può cambiare significato.

Più token e attese tra passaggi dipendenti

La delega aggiunge istruzioni, contesto per gli agenti, risultati restituiti e sintesi. I tentativi ripetuti e la cronologia condivisa della conversazione aggiungono altro lavoro. Anthropic riferisce che, nei propri dati, i sistemi multiagente hanno usato circa 15× i token delle chat. Il termine di paragone sono le chat, non le esecuzioni con un solo agente: questo rapporto non è un moltiplicatore generale da usare per le stime. Il consumo di token riportato da Anthropic.

Il consumo aggiuntivo di token è un rischio da misurare, non una legge universale secondo cui ogni configurazione multiagente debba consumarne di più. Contesti separati possono evitare di caricare ripetutamente materiale irrilevante. Conta il consumo totale necessario per ottenere un risultato accettato, compresi i rami falliti e il lavoro da rifare.

Gli agenti in parallelo possono ridurre il tempo complessivo solo quando il loro lavoro è indipendente. Un ricercatore che deve finire prima che il pianificatore possa agire, seguito da un programmatore che deve aspettare il piano, forma comunque una catena di dipendenze. Dare nomi diversi ai passaggi non li rende simultanei.

Un debug più difficile

La risposta finale può nascondere la prima decisione sbagliata. Un programmatore può implementare correttamente un requisito errato, mentre un revisore approva l'implementazione sulla base di quello stesso requisito. Esaminare soltanto l'ultima risposta porta ad attribuire il problema al componente sbagliato.

Anthropic riferisce che il tracciamento completo ha aiutato a distinguere i problemi di ricerca, selezione delle fonti e uso degli strumenti nel suo sistema di ricerca. Descrive anche come gli errori si accumulino nelle esecuzioni degli agenti che mantengono uno stato. Le osservazioni tecniche.

Nel confrontare le architetture, chiediti se riesci a individuare il primo punto in cui il sistema si allontana dal compito: quali istruzioni ha ricevuto l'agente, quali riscontri gli sono stati forniti, che cosa ha restituito e che cosa l'agente successivo ha trattato come un fatto accertato. Se non puoi esaminare questi passaggi, non puoi sapere se un revisore in più migliori il sistema o aggiunga soltanto un messaggio finale rassicurante.

Gli errori si accumulano a ogni passaggio

Immagina che un ricercatore scriva: «Questo endpoint sembra supportare le esportazioni, ma i requisiti relativi ai permessi non sono chiari». Un pianificatore riassume così: «Usare l'endpoint di esportazione». Il programmatore realizza il piano. Un revisore confronta la patch con il piano e non trova discrepanze.

L'incertezza iniziale è scomparsa senza che nessuno l'abbia risolta. Hanno partecipato più agenti, ma nessuno ha verificato l'informazione mancante.

Insieme alla sintesi, restituisci riferimenti alle fonti, punti ancora da chiarire esplicitati e l'elaborato effettivo. Fornisci ai revisori il requisito originale, non soltanto il modo in cui lo descrive chi ha prodotto il lavoro. Sono motivi per preferire un team piccolo e ispezionabile a una lunga sequenza di ruoli definiti in modo vago.

Che cosa viene sopravvalutato nei team di agenti?

Il numero di ruoli è un cattivo indicatore delle capacità. Più agenti non producono automaticamente più conoscenza, giudizi indipendenti o un'esecuzione più rapida. La domanda utile è quale nuovo lavoro diventi possibile grazie alla separazione.

Un solo agente può usare strumenti in parallelo: effettuare ricerche simultanee non richiede, di per sé, un team. Può anche caricare istruzioni specialistiche quando servono. LangChain documenta un modello basato sulle skill che mantiene un unico agente al comando e rende disponibili le conoscenze pertinenti su richiesta.

Non confondere neppure prompt separati con isolamento di sicurezza. Chiamare un agente «ricercatore» e un altro «approvatore» non ne limita automaticamente gli accessi. L'applicazione deve far rispettare i permessi degli strumenti e i limiti di approvazione previsti.

L'argomento più solido a favore di più agenti è di solito specifico: questo agente ha bisogno di un contesto distinto, può indagare una domanda in autonomia oppure deve assumersi la responsabilità di un altro ambito della conversazione. «Assomiglia a un team» non basta.

Da lunedì, metti alla prova la suddivisione minima utile

Mantieni una configurazione di riferimento con un solo agente e aggiungi soltanto quello che affronta un problema osservabile. Se il sistema attuale funziona, aggiungere responsabili e revisori crea un nuovo sistema di cui devi dimostrare l'utilità.

1. 1

   Individua il problema nel workflow attuale

   Scegli attività reali in cui l'agente trascura informazioni rilevanti, seleziona strumenti sbagliati, perde requisiti o produce un elaborato inaccettabile. Rimedia agli strumenti mancanti e alle istruzioni poco chiare prima di attribuire il problema al numero di agenti.

2. 2

   Definisci un'alternativa circoscritta

   Per un assistente di programmazione, lascia all'agente principale la responsabilità della patch e aggiungi un revisore indipendente solo se il punto debole è la revisione. Specifica gli input del revisore e i riscontri che deve restituire. Evita di cambiare l'intero workflow in una volta sola.

3. 3

   Confronta i risultati accettati

   Esegui la configurazione di riferimento e l'alternativa sullo stesso insieme di attività, con gli stessi criteri di accettazione. Registra la qualità del lavoro completato, i token totali, il tempo trascorso e il lavoro umano necessario per diagnosticare o correggere gli errori. Nell'interpretare il risultato, tieni conto delle differenze tra i modelli.

4. 4

   Mantieni o elimina la separazione

   Conserva l'agente aggiuntivo se migliora il risultato abbastanza da giustificare l'impegno operativo che comporta. Se si limita soprattutto a ripetere il contesto o a riformulare il lavoro di un altro agente, riporta quell'attività nell'agente originale. Chi gestisce un sistema senza lacune misurate può aspettare; chi sviluppa rami di ricerca indipendenti ha un motivo più concreto per sperimentare subito.

Domande frequenti sui sistemi multiagente

ChatGPT è un sistema multiagente?

Il nome ChatGPT, da solo, non rivela l'architettura di uno specifico workflow. Per definire multiagente una funzionalità, cerca una documentazione che descriva agenti distinti capaci di scambiarsi il lavoro svolto o trasferire il controllo. Un'interfaccia di chat, l'uso di strumenti o una risposta lunga non sono prove sufficienti.

Qual è un esempio di sistema multiagente?

Il sistema Research di Anthropic delega le indagini ad agenti esecutori e ne combina i risultati: è un esempio del modello con orchestratore e agenti esecutori.

Qual è il miglior sistema multiagente?

Non esiste un migliore in assoluto. Adatta il modello al compito: un supervisore per incarichi specialistici circoscritti, gli handoff per trasferire la responsabilità della conversazione e una chat di gruppo per revisioni iterative utili. Mantieni un unico agente quando suddividere il lavoro non migliora il risultato.

Quali sono i 4 principali agenti AI?

Non esiste un elenco canonico del settore chiamato «big 4». Pianificatore, ricercatore, programmatore e revisore sono ruoli comuni nelle proposte di team di agenti, non componenti obbligatori. Definisci il lavoro di ciascun ruolo prima di trasformarlo in un agente separato.

ChatGPT è un agente o un LLM?

ChatGPT è il nome di un'applicazione; LLM indica il tipo di modello sottostante. Un agente è invece un sistema che usa un modello per scegliere azioni e reagire ai risultati. Si tratta di livelli diversi: esamina quindi la funzionalità specifica, senza considerare intercambiabili queste definizioni.

Quali sono i 7 tipi di agenti AI?

Gli elenchi di sette tipi combinano classificazioni diverse, come regole decisionali, modalità di apprendimento, ruoli operativi o modelli di collaborazione. Non esiste un'architettura fissa in sette parti da implementare. Per la scelta che stiamo esaminando, distingui il comportamento di un singolo agente dall'organizzazione di più agenti.

Quali sono gli agenti AI più comuni?

Tra le categorie aziendali utili ci sono gli assistenti per il supporto clienti, gli agenti di ricerca e quelli di programmazione. Sono categorie di attività, non una classifica di popolarità verificata. I loro nomi non dicono se operino da soli, sotto un supervisore o tramite handoff.

Puoi fare qualche esempio di agente AI?

Un agente di assistenza che consulta un ordine e sceglie l'azione successiva, un agente di ricerca che cerca e verifica le fonti, un agente di programmazione che modifica file ed esegue test. Ciascuno può essere un unico agente, anche quando svolge molti passaggi.

Quali sono i 5 tipi di agenti AI?

IBM descrive una tassonomia classica che comprende agenti reattivi semplici, reattivi basati su un modello, basati su obiettivi, basati sull'utilità e capaci di apprendere. Classifica il modo in cui un agente decide o impara. Non prescrive quanti agenti LLM debba usare la tua applicazione.

Per prendere decisioni pratiche su come sviluppare con l'AI, iscriviti alla newsletter.