Multi-agent orchestration in azienda: quando serve un architetto AI

Chi valuta oggi un sistema multi-agente in azienda parte quasi sempre dalla domanda sbagliata: quale framework scegliere. LangGraph, CrewAI, OpenAI Agents SDK e Claude Agent SDK risolvono tutti lo stesso problema di base, far parlare più agenti tra loro, e nessuno dei quattro risolve il problema che fa fallire i progetti: decidere cosa succede quando un agente sbaglia, quanto può costare una singola richiesta e quali sistemi aziendali ogni agente ha il diritto di toccare. L’orchestrazione agenti AI azienda è, prima che una scelta tecnologica, una decisione di architettura. E le decisioni di architettura hanno bisogno di un architetto.

In questo articolo scoprirai:

• Che cos'è l'orchestrazione multi-agente: supervisor, handoff, tool routing, memoria
• Perché per l'orchestrazione di agenti AI in azienda il framework non basta
• I pattern di orchestrazione: sequenziale, concorrente, gerarchico, handoff
• Quanti agenti servono davvero: il conto in token che cambia il progetto
• Le tre cose che nessun framework progetta per te: fallback, budget, permessi
• Chi risponde delle azioni di un agente: governance e AI Act

Che cos’è l’orchestrazione multi-agente: supervisor, handoff, tool routing, memoria

L’orchestrazione multi-agente è il livello software che decide quale agente lavora, quando, con quali strumenti e con quale porzione di contesto. Non è un modello e non è un prompt: è un control plane. La survey accademica The Orchestration of Multi-Agent Systems (Adimulam, Gupta, Kumar) lo descrive come un layer che integra quattro funzioni distinte, pianificazione, applicazione delle policy, gestione dello stato e quality operations, per ottenere un ragionamento «scalabile, auditabile e conforme alle policy» su un insieme distribuito di agenti. Tolta una di quelle quattro funzioni, non hai un sistema multi-agente: hai un gruppo di chatbot che si scrivono a vicenda.

I quattro meccanismi dell’orchestrazione multi-agente

Nella pratica il layer si compone di quattro meccanismi ricorrenti. Il supervisor (o orchestrator) è un agente che non esegue il lavoro ma lo assegna e ne valuta l’esito. L’handoff è il passaggio di consegne: nell’OpenAI Agents SDK viene esposto al modello come un normale tool (transfer_to_<nome_agente>), e per default l’agente ricevente vede l’intera cronologia precedente salvo input filter espliciti. Il tool routing stabilisce chi può chiamare cosa: MCP e il protocollo Agent2Agent sono i due standard che regolano rispettivamente l’accesso a dati e strumenti e il dialogo fra pari, se il tema è nuovo, la guida al Model Context Protocol spiega il meccanismo. La memoria condivisa, infine, decide cosa sopravvive a un turno: qui il confine con il recupero documentale è sottile, e vale la pena capire come funziona il RAG prima di far dipendere tre agenti dallo stesso indice.

Memoria condivisa negli agenti AI: progettazione e rischio di propagazione

È il meccanismo dove le decisioni di progetto sono più esplicite: bisogna stabilire cosa persiste fra un turno e l’altro, le conclusioni intermedie, le sole decisioni finali, o nulla, perché ogni frammento che sopravvive è contesto che tutti gli agenti a valle pagheranno in token. Bisogna poi separare i diritti di scrittura da quelli di lettura sull’indice condiviso: un agente che scrive è un agente che può riscrivere ciò su cui gli altri stanno lavorando, e quasi mai serve che tutti abbiano quel diritto. Il rischio da mettere a verbale è la propagazione: se tre agenti leggono dallo stesso store, un dato sbagliato scritto una volta diventa la premessa condivisa di tutto ciò che segue, e l’errore non si vede nel log dell’agente che l’ha commesso ma in quello dei due che gli hanno creduto.

Perché per l’orchestrazione di agenti AI in azienda il framework non basta

Un framework fornisce primitive; un sistema in produzione richiede decisioni. Dataiku, nella sua analisi su agent orchestration, quantifica lo scarto: l’86% delle organizzazioni usa già agenti AI nelle operazioni quotidiane, ma la maggior parte non ha l’infrastruttura di orchestrazione e governance per gestirli su scala. Il risultato sono agenti che duplicano lavoro, si contendono le stesse risorse e producono buchi di audit che nessuna funzione compliance accetta.

C’è poi un vincolo che i vendor raccontano poco: la scelta del pattern è quasi irreversibile. Sempre Dataiku la definisce «la decisione architetturale più consequenziale», perché cambiare da sequenziale a concorrente o a handoff dopo il deployment costa quanto riscrivere. Ogni pattern porta con sé failure mode, scenari di conflitto e profili di latenza propri, che vanno capiti prima di scrivere il primo nodo del grafo.

Il difetto strutturale delle guardrail nei sistemi multi-agente

Un esempio concreto di ciò che il framework non decide per te. La documentazione dell’OpenAI Agents SDK avverte che le input guardrail si applicano solo al primo agente della catena e le output guardrail solo all’agente che produce la risposta finale. Tradotto: tutto ciò che accade nel mezzo, tre handoff, dodici tool call, un accesso al CRM, non è coperto da nessun controllo automatico, a meno che qualcuno l’abbia progettato. È esattamente il punto in cui un progetto pilota diventa un incidente, e la ragione per cui in questi sistemi il servizio conta più del modello.

I pattern di orchestrazione: sequenziale, concorrente, gerarchico, handoff

La tassonomia più stabile è quella dell’Azure Architecture Center, aggiornata a febbraio 2026, che censisce cinque pattern di orchestrazione: sequenziale, concorrente, chat di gruppo, handoff e magentic. I framework li implementano con nomi diversi ma la sostanza è la stessa. In CrewAI la scelta è binaria e dichiarativa: processo sequenziale (default) oppure gerarchico, dove un manager agent, configurato via manager_llm o manager_agent, delega i task e valida gli esiti prima di procedere. Nel supervisor di LangGraph il pattern è invece un grafo esplicito: il supervisor è un nodo che decide a quale agente passare il controllo, e ogni specialista, finito il proprio task, restituisce il controllo al supervisor invece di proseguire in autonomia, la struttura del routing è codice, non prompt. Nel Claude Agent SDK ogni subagente parte con una finestra di contesto pulita, riceve solo la stringa di prompt che il padre gli passa e restituisce al padre solo il messaggio finale: l’isolamento del contesto è una proprietà del pattern, non un’ottimizzazione.

Quale pattern scegliere: la regola pratica

La regola pratica è cominciare dal supervisor. È il pattern con la semantica più chiara, un orchestratore, N specialisti, una condizione di terminazione, e quello che consente di misurare le responsabilità. Il gerarchico puro va introdotto solo quando il numero di specialisti rende il supervisor un collo di bottiglia; il group chat solo quando serve genuinamente una deliberazione fra prospettive diverse, perché moltiplica i token senza garantire convergenza. La scelta va comunque letta dentro il quadro più ampio dell’architettura enterprise con agenti AI, non come decisione isolata di un team tecnico.

Quanti agenti servono davvero: il conto in token che cambia il progetto

Qui arriva il dato più utile per chi deve firmare un budget. Anthropic ha pubblicato le misure del proprio sistema multi-agente di ricerca: un agente singolo consuma circa 4 volte i token di una chat, un sistema multi-agente circa 15 volte. Sul benchmark BrowseComp, il solo consumo di token spiega l’80% della varianza di performance. È una notizia a doppio taglio: il multi-agente funziona perché spende, e quindi ha senso solo dove il valore del task giustifica quindici volte il costo.

Lo stesso documento indica dove non usarlo: i domini in cui tutti gli agenti devono condividere lo stesso contesto o presentano molte dipendenze reciproche. Anthropic cita esplicitamente il coding, dove i task realmente parallelizzabili sono meno di quanti sembrino. Il criterio operativo è la parallelizzabilità, non la complessità: se il lavoro si divide in tronconi indipendenti e l’informazione eccede una singola finestra di contesto, il multi-agente paga; altrimenti un agente solo con più tool è più economico, più prevedibile e più facile da debuggare. Prima di moltiplicare gli agenti conviene quindi verificare la readiness dell’azienda e ricordare che quando l’AI generativa non genera ROI il problema non è la tecnologia.

Le tre cose che nessun framework progetta per te: fallback, budget, permessi

È questa la parte che separa un prototipo da un sistema che regge il lunedì mattina.

Fallback: cosa fa il sistema quando un agente fallisce

Anthropic descrive un approccio ibrido: adattività del modello più «safeguard deterministici come retry logic e checkpoint regolari», con deploy progressivi per non interrompere agenti già in esecuzione. Comunicare all’agente che un tool sta fallendo, aggiungono, «funziona sorprendentemente bene». Ma nessun framework decide per te se un fallimento va ritentato, escalato a un umano o silenziato.

Budget di token per catena di agenti

Il costo non va stimato per chiamata ma per catena. CrewAI espone usage_metrics a fine esecuzione; il Claude Agent SDK consente maxTurns e un model diverso per subagente, pattern che Anthropic usa in produzione con un modello più capace come lead e modelli più economici come worker. Dataiku raccomanda limiti di token per-agente applicati a ogni esecuzione. Sono tre leve dello stesso cruscotto, e vanno impostate insieme prima del go-live.

Permessi cross-team: il vero rischio dell’orchestrazione multi-agente

La formulazione di Dataiku è netta: «un agente che analizza il sentiment dei clienti non deve avere accesso ai sistemi di pagamento». Servono RBAC per agente, mascheramento dei PII nei passaggi fra agenti e audit trail immutabili. Il Claude Agent SDK offre le primitive giuste, tools, disallowedTools, permissionMode per singolo agente, con gli strumenti esclusi che non esistono nemmeno nella sessione, ma la mappa dei permessi la disegna chi conosce l’organizzazione, non chi conosce l’SDK. Nei sistemi legacy tipo ERP e CRM è il punto più delicato dell’intero progetto.

Chi risponde delle azioni di un agente: governance e AI Act

La responsabilità non si delega al software. L’articolo 14 dell’AI Act impone, per i sistemi ad alto rischio, una supervisione umana effettiva: chi opera deve comprendere capacità e limiti del sistema, riconoscere il rischio di automation bias, poter ignorare o ribaltare un output e poter interrompere il sistema tramite uno «stop button» o procedura equivalente. In un’architettura multi-agente questo significa progettare punti di interruzione: approval gate sui passaggi che scrivono su sistemi di record, e tracciamento distribuito che permetta di ricostruire quale agente ha deciso cosa.

Il presupposto tecnico è l’osservabilità su tre livelli: salute tecnica (token per agente, latenza, error rate), esiti di business (qualità del task, costo per risoluzione) e tracing distribuito. La distanza fra il primo e il secondo livello è dove la maggior parte dei programmi di monitoraggio fallisce. Chi affronta il tema in ottica normativa trova un quadro più ampio in AI Act e agenti AI in azienda; sul piano organizzativo, l’introduzione di più agenti ridisegna ruoli e deleghe come descritto ne L’Organizzazione Agentica e richiede change management reale.

Onboarding dell’orchestrazione agenti AI in azienda: progettazione, non installazione

Noi in Mimír l’orchestrazione multi-agente non la raccontiamo in astratto: la usiamo. Il sistema editoriale che produce questo blog è multi-agente per costruzione, un agente direttoriale che seleziona i temi e dà il verdetto finale, agenti scrittori distinti per formato, un agente di revisione con una soglia esplicita oltre la quale non corregge ma rimanda al mittente, un agente dedicato ai link interni, uno alla misurazione dei dati e uno alla sicurezza. Ogni agente ha memoria propria su file, un set di tool ristretto e un contratto di handoff scritto: cosa riceve, cosa deve restituire, quando deve fermarsi e chiedere. Non sono agenti più intelligenti degli altri: sono agenti con confini più chiari. Le regole che li tengono insieme, chi può riscrivere cosa, quando si escala a una persona, sono state progettate, non ereditate dal framework.

Progettare i confini degli agenti AI in azienda

È per questo che il nostro onboarding non è un’installazione. Anthropic scrive che bisogna «insegnare all’orchestratore a delegare», fornendo a ogni subagente obiettivo, formato di output, indicazioni sui tool e confini chiari del task: senza quelle descrizioni gli agenti duplicano lavoro o lasciano buchi. Quel lavoro di scrittura dei confini si può fare solo dentro l’azienda, guardando processi e permessi reali. Se stai valutando dove collocarti, aiutano il confronto fra agenti custom e off-the-shelf, la scelta fra soluzione chiavi in mano e self-service, e, per chi parte dalle basi, cosa sono gli agenti AI e perché sono indispensabili per le aziende. Sul piano operativo, il primo dominio in cui il multi-agente ripaga è spesso il back-office, e se il vostro stack è Anthropic vale la lettura di Claude Agent SDK per PMI.

Da dove partire con l’orchestrazione agenti AI in azienda

Se in azienda avete un processo che sembra chiedere più di un agente e nessuno che possa disegnare fallback, budget e permessi, è esattamente la conversazione che facciamo volentieri: parlane con noi su mimir.bot. Portiamo l’architettura, non solo l’integrazione, quello che offriamo è Mimír AI Agent più il servizio che lo mette al lavoro, e come funziona una consulenza su agenti AI per PMI lo abbiamo scritto nero su bianco.

Fonti:

• The Orchestration of Multi-Agent Systems (arXiv)
• OpenAI Agents SDK — Handoffs
• Dataiku — Agent orchestration explained
• Azure Architecture Center — Pattern di progettazione per agenti AI
• CrewAI — Crews e processi di esecuzione
• LangGraph — Multi-agent supervisor
• Claude Agent SDK — Subagents
• Anthropic — How we built our multi-agent research system
• AI Act — Articolo 14, sorveglianza umana