Orchestrazione multi-agente: dal proof-of-concept alla produzione (guida 2026)

Un proof-of-concept con due agenti che si parlano funziona quasi sempre. Bastano un orchestratore in Python, due chiamate LLM in fila, una manciata di tool. La demo gira, il video va su LinkedIn, il cliente firma.

Poi arriva la produzione. Dieci agenti concorrenti, decine di esecuzioni al giorno, dati reali che non si possono perdere, un legale che chiede chi ha approvato cosa, un operations che chiede perché il costo del mese precedente è triplicato. Il POC, lì, smette di reggere. Non perché il modello sbagli — perché manca tutta l'infrastruttura intorno: pattern, governance, monitoring, scaling.

Questa guida raccoglie ciò che funziona davvero quando si porta un sistema multi-agente da una demo a un'operatività quotidiana. Sei pattern operativi, le condizioni del salto verso la produzione, come tenere insieme governance e AI Act, cosa monitorare, come controllare il costo. È materiale operativo, non teorico: deriva da pipeline che girano oggi su clienti reali, non da slide.

Per la mappa concettuale di base — cos'è un agente, cosa cambia tra agente e agentic AI, quando ha senso un sistema multi-agente — il riferimento resta orchestrazione multi-agente spiegata. Qui partiamo dal punto in cui quella mappa si chiude e si entra nella sala macchine.

Perché il POC non scala

Tre cose accadono nel salto da POC a produzione.

Primo: la concorrenza. In demo, una richiesta alla volta. In produzione, decine di esecuzioni che si sovrappongono. Senza un layer che gestisca code, lock, contesti isolati, gli agenti si pestano i piedi: due agenti che modificano lo stesso record, due esecuzioni che si contendono lo stesso tool a quota limitata, una sessione che eredita stato di un'altra.

Secondo: i fallimenti silenziosi. In demo l'output è sotto agli occhi del founder. In produzione no. Un agente che restituisce JSON malformato, un tool che ritorna stale data, un modello che inventa un campo: nessuno se ne accorge finché un cliente downstream non se ne lamenta. Il monitoring non è un nice-to-have, è ciò che separa "sistema affidabile" da "sistema che ogni tanto esplode senza preavviso".

Terzo: la governance. Demo = nessuno chiede chi ha autorizzato cosa. Produzione = legale, security, compliance vogliono un audit trail. Quale agente ha modificato il record del cliente alle 14:32? Con quale prompt? Con quali tool? Chi ha approvato il job ricorrente che lo richiama? Senza queste risposte, il sistema non si può portare in clienti regolati (banche, sanità, PA) e con l'AI Act diventa un rischio anche fuori da quei settori.

I sei pattern che seguono sono ciò che, nella nostra esperienza, risolve queste tre crisi insieme. Non sono mutuamente esclusivi: in una pipeline reale se ne combinano due o tre.

Pattern 1 — Foreman / Manager

L'orchestratore non è un agente paritario: è un caposquadra. Riceve la richiesta dell'utente o del trigger, decompone il lavoro in sotto-task, assegna ogni sotto-task a un agente specializzato, raccoglie i risultati, li ricompone in una risposta finale. Nessun agente specializzato parla direttamente con un altro: tutto passa dal foreman.

Quando usarlo. Workflow con dipendenze sequenziali chiare: prima estrai i lead, poi arricchiscili, poi qualifica, poi scrivi l'email. Ogni step ha un agente esperto e l'ordine conta.

Cosa risolve. Chiarezza di responsabilità (un solo punto di failure, un solo punto di logging), controllo dei costi (il foreman decide quanti turni ogni agente può consumare), audit trail naturale (tutto il dialogo passa da un nodo solo).

Cosa non risolve. Lavori paralleli che non hanno bisogno di coordinamento sequenziale: lì il foreman diventa un collo di bottiglia inutile.

Pattern 2 — Role-Card

Ogni agente riceve una scheda ruolo esplicita: chi sei, cosa fai, cosa non fai, quali tool puoi usare, quale formato di output devi produrre. La scheda non è il system prompt completo: è la sezione "identità" che precede le istruzioni del task.

Quando usarlo. Sempre, in produzione. È un costo basso e un beneficio alto: gli agenti deviano molto meno dal mandato, i tool fuori scope vengono rifiutati, i formati di output restano stabili tra esecuzioni.

Cosa risolve. La deriva di ruolo (agente "scrittore email" che inizia a fare ragionamento sul prezzo), l'abuso di tool (agente "lettore database" che prova a scrivere), l'instabilità di formato (un giorno restituisce JSON, il giorno dopo prosa).

Cosa serve a contorno. Un layer di policy che faccia rispettare la scheda: filtraggio dei tool a livello di runtime (non solo nel prompt), validazione dell'output con schema, retry con feedback se la forma non è rispettata.

Pattern 3 — Swarm

Niente foreman. Gli agenti si parlano in una topologia paritaria, ognuno annuncia ciò che ha trovato, gli altri reagiscono. Tipico di lavori esplorativi: analisi di un mercato dove uno cerca competitor, uno cerca segnali social, uno legge bilanci, e ognuno alimenta gli altri con i suoi pezzi.

Quando usarlo. Quando la decomposizione del lavoro non è nota a priori e i risultati di un agente cambiano cosa l'altro deve cercare. Tipicamente: ricerca, brainstorming strutturato, second-opinion ad ampio spettro.

Cosa risolve. Esplorazione adattiva, copertura di spazi di ipotesi che un foreman fisso non avrebbe pianificato.

Cosa non risolve. Affidabilità in produzione su workflow ricorrenti: lo swarm tende a divergere, a consumare token, a non chiudere mai. In produzione si usa quasi sempre con un timeout duro e un agente "chiusore" che dichiara terminata l'esplorazione e produce il sintetico.

Pattern 4 — Peer-Review

Output di un agente passa a un secondo agente che fa il revisore: cerca errori, chiede chiarimenti, propone modifiche. L'output finale o esce solo dopo approvazione del revisore, oppure va in un terzo round con un mediatore.

Quando usarlo. Workflow dove l'errore costa: contenuti pubblicabili, codice in prod, comunicazioni cliente. Anche per lavori dove un singolo modello tende ad allucinare e un secondo passaggio "critico" cattura gran parte degli errori.

Cosa risolve. Tasso di errore percepito sull'output finale, perché due passaggi indipendenti raramente sbagliano nello stesso punto. È anche un pattern utile per ridurre la pressione sul prompt-engineering del primo agente: se sbaglia, il revisore corregge.

Cosa costa. Raddoppia (almeno) i token. In produzione si applica solo alle classi di task dove il costo dell'errore è alto rispetto al costo del peer-review.

Pattern 5 — Hybrid Human-in-the-Loop (HITL)

Alcuni step non passano in produzione finché un umano non li approva. La pipeline si ferma in una "casella di approvazione", un operatore vede il proposto, approva / amenda / rifiuta, e solo allora prosegue.

Quando usarlo. Sempre, in fasi critiche di processi regolati o ad alto rischio: invio cold email a una lista nuova, modifica di un record cliente, esecuzione di una transazione, pubblicazione esterna. È anche il pattern obbligato per ciò che l'AI Act qualifica come "ad alto rischio" o per qualunque processo dove la responsabilità giuridica resta umana.

Cosa risolve. Responsabilità (la firma dell'umano è il punto di ancoraggio), risk management (gli errori più costosi vengono intercettati prima dell'esterno), training data (le correzioni umane diventano segnale per migliorare il sistema).

Cosa serve. Una UI di approvazione decente, perché un HITL con UX terribile diventa il collo di bottiglia: l'operatore rinvia le decisioni, le code crescono, il sistema rallenta. Una buona regola: ogni casella HITL deve poter essere processata in meno di 30 secondi se il proposto è ragionevole.

Pattern 6 — Audit-Trail-by-Design

Ogni esecuzione di ogni agente lascia, alla fine, un record strutturato: chi era l'agente, quale prompt, quali tool chiamati, quale input, quale output, quale costo, quale durata, quale esito. Niente di tutto questo è facoltativo. È l'unico pattern che è anche un'invariante di sistema: se manca per anche un solo agente, l'intero audit del sistema è compromesso.

Quando usarlo. Sempre, in produzione, senza eccezioni.

Cosa risolve. Indagine post-incidente (cosa è successo alle 14:32?), conformità (chi ha approvato cosa?), miglioramento (quali prompt producono il maggior numero di errori?), costo per cliente (quanto consuma davvero questo workflow su un cliente reale?).

Cosa costa. Storage e disciplina. È poco, ed è il pattern con il più alto rapporto valore-costo dell'intera lista.

Per il dettaglio normativo che sostiene questo pattern, l'ancoraggio è la guida AI Act per le aziende e gli articoli specifici come articolo 25 — fornitori e deployer: l'audit trail non è un nice-to-have, è uno dei requisiti documentali espliciti.

Il salto dal POC alla produzione

Tre dimensioni cambiano nel salto.

Numero di agenti. Un POC è 1-3 agenti, una produzione è 10-30. Sopra i 10 agenti la topologia non si tiene più "a mente": serve un registro esplicito (ogni agente con id, ruolo, tool autorizzati, modello, costo unitario) e una mappa delle dipendenze. Senza registro, il sistema diventa illeggibile dopo poche settimane.

Frequenza di esecuzione. Un POC è "demo on demand", una produzione è "ricorrente o reattiva". Ricorrente = scheduler. Reattiva = trigger su evento (webhook, riga nuova in DB, email arrivata). Entrambi richiedono un layer di triggering esterno agli agenti: nessun agente deve "girare in loop in attesa di lavoro", è anti-pattern.

Tolleranza al fallimento. Un POC tollera che il 20% delle esecuzioni vadano male, il founder le ricorre a mano. Una produzione no. Servono retry policy, dead-letter queue (esecuzioni fallite tre volte vanno in coda morta per ispezione), idempotenza (rieseguire un job non deve duplicare effetti). Sono tre primitive di engineering, non di prompt engineering.

Il segnale più affidabile che il salto sia avvenuto: si può spegnere il telefono del founder per un weekend e il sistema continua a girare senza degradare. Se questa proprietà non vale, non si è in produzione, si è in POC esteso.

Per il confronto tra costruire questa infrastruttura in casa e adottarne una pronta, il riferimento è costruire vs comprare agenti AI; per la scelta della piattaforma, piattaforma AI workforce: guida.

Governance: AI Act e audit trail

In Europa, da agosto 2026, la governance multi-agente non è più un'opzione di prodotto: è un obbligo normativo per la maggior parte degli usi non-banali. L'AI Act distingue obblighi del fornitore (chi costruisce il sistema) e obblighi del deployer (chi lo usa). Per un'azienda che adotta un sistema multi-agente, di solito si è sia fornitore (perché si configura, si specializza, si integra) sia deployer (perché lo si usa su processi propri).

Cosa serve concretamente per essere in regola, sul piano operativo, qui e ora:

• Registro dei sistemi AI. Ogni sistema multi-agente in produzione ha una scheda: scopo, dati trattati, livello di rischio, oversight umano, agenti coinvolti, metriche di qualità.
• Audit trail per ogni esecuzione. Già descritto sopra come pattern; qui diventa anche obbligo documentale.
• Oversight umano configurato per task ad alto rischio. Concretamente, HITL nei punti giusti.
• Procedura di incidente. Cosa succede se un agente produce output dannoso, chi viene avvisato, in quanti giorni, con quale documentazione.
• Trasparenza verso l'utente finale. Quando un agente comunica con un essere umano, l'umano deve sapere che è AI.

Per la mappa completa degli obblighi e delle scadenze, scadenze AI Act 2026-2027 e l'integrazione con i sistemi di governance già esistenti in AI Act + decreto 231.

Monitoring: cosa misurare davvero

Quattro famiglie di metriche, in ordine di criticità.

Latenza. Tempo dal trigger alla chiusura del workflow, ed entro questo, il tempo di ogni singolo agente. Da questa metrica si scopre il collo di bottiglia: di solito è un tool esterno (un'API che risponde lenta), non l'LLM. Senza misurarla per agente, non si sa dove ottimizzare.

Tassi di errore. Tre livelli: errore di tool (la chiamata esterna è fallita), errore di forma (l'output non rispetta lo schema), errore semantico (l'output è formalmente corretto ma sbagliato di contenuto). I primi due sono catturati automaticamente; il terzo richiede o peer-review o sampling umano periodico. Se il tasso di errore semantico non è misurato, in produzione resta il rischio principale.

Tool-abuse. Frequenza con cui un agente prova a chiamare tool fuori dalla sua scheda, o passa parametri palesemente fuori range. Un picco di tool-abuse è quasi sempre il segnale che un prompt è degradato (modello aggiornato, prompt non più allineato) o che il sistema sta venendo provato in modo avversariale.

Drift. Distribuzione degli output nel tempo: lunghezza media, vocabolario, distribuzione dei valori dei campi strutturati. Quando questa distribuzione si sposta senza che nulla nel codice sia cambiato, qualcosa a monte è cambiato (il modello, i dati di input, un tool). Senza misura del drift, la regressione di qualità si scopre dal cliente.

Tutte e quattro le metriche sono inutili se non hanno una baseline. La baseline si misura nelle prime due settimane di produzione e diventa il riferimento contro cui ogni alert misura se è anomalia o normalità.

Scaling e costo

In multi-agente, il costo segue una legge brutale: scala con il numero di turni totali, non con il numero di richieste. Un singolo workflow può spendere 50 turni se gli agenti si rimpallano la palla; lo stesso workflow ben disegnato ne spende 8. Differenza in costo: 6x. Differenza in latenza: anche di più, perché ogni turno è anche un round trip.

Tre leve concrete per controllare il costo.

Limite di turni per agente, hard. Mai "fino a quando ha finito". Sempre "massimo N turni, poi forza una conclusione". Un agente che non ha finito in N turni quasi sempre non finirà mai, perché è entrato in un loop o ha frainteso il task.

Modello giusto per il task giusto. Non tutto serve il modello più grande. Estrazione strutturata, classificazione, riscrittura: spesso un modello medio basta e costa una frazione. Ragionamento aperto, codice non banale, documenti lunghi: serve il modello forte. Una pipeline produzione mescola modelli; uno solo è quasi sempre overkill o underkill.

Caching dei prompt comuni. I provider seri offrono prompt caching: la parte stabile del prompt (system prompt + scheda ruolo + esempi) viene cachata e non rifatturata a tariffa piena. In pipeline ad alta frequenza, il caching abbatte il costo del 50-80% sulla parte invariante. Non attivarlo è denaro lasciato sul tavolo.

A questo si somma l'infrastruttura attorno: storage dei log, code, scheduler, dashboard. Pesi ragionevoli su un sistema medio: il 70-80% del costo è LLM + tool esterni, il resto è infrastruttura. Quando l'infrastruttura sale sopra il 30%, è il segnale che la stack è sovradimensionata o mal configurata.

Per il quadro economico più ampio — costi dei singoli agenti, confronto con alternative, ROI — come misurare il ROI dell'AI è il riferimento dedicato.

Errori di campo (e cosa abbiamo imparato a non fare più)

Far parlare gli agenti senza un orchestratore. Sembra elegante, in pratica diverge. Senza un foreman o un protocollo di chiusura, due agenti possono ragionare per ore senza concludere. Mai più senza un terminatore.

Dare a un agente l'accesso a tool che non gli servono. "Tanto male non fa". In realtà fa, perché il modello prima o poi prova quel tool. Ogni agente con la sua dotazione minima di tool, sempre.

Skippare l'audit trail nelle prime versioni "perché tanto è solo POC". L'audit trail va costruito subito perché aggiungerlo dopo costa il triplo: significa retrofittare logging in agenti già esistenti, ricostruire pezzi di storia che non sono stati registrati, e di solito convivere con un periodo cieco che pesa nelle ispezioni.

Pensare che il prompt engineering basti. Non basta. Serve runtime: filtraggio tool, validazione output, retry policy, timeout, idempotenza. Un prompt perfetto su un runtime fragile produce comunque un sistema fragile.

Sottovalutare l'UX dell'oversight umano. L'umano è il collo di bottiglia naturale in HITL. Se la sua UI è cattiva, tutto il sistema rallenta. Investire qui rende dieci volte più che ottimizzare i prompt.

Come Knowlee implementa questi pattern

Conviene dirlo per chiarezza: Knowlee è la piattaforma da cui questa guida nasce. Ogni pattern descritto sopra è in produzione su clienti reali oggi. Foreman su orchestratori dei flussi commerciali. Role-card per ogni agente specializzato. Peer-review nei contenuti pubblicati. HITL nei passaggi critici (invio email a liste nuove, modifiche a record clienti). Audit trail per ogni esecuzione, nativo, non a posteriori.

L'infrastruttura sotto è proprietaria, gira su nodi europei controllati dal cliente quando serve sovranità del dato (vedi AI workforce on-premise EU), e include scheduler, code, dashboard di monitoring, console di approvazione HITL, registro AI Act, knowledge graph cross-agente per la memoria condivisa.

Non descriviamo Knowlee come "wrapper" su altri vendor: è una piattaforma intera, dal layer di runtime al layer di governance al layer di interfaccia utente. È il motivo per cui può portare in produzione sistemi multi-agente in tempi che a costruirli da zero non sarebbero raggiungibili dalla maggior parte dei team interni.

Quando NON costruire multi-agente

Non tutti i problemi vogliono multi-agente. Tre casi in cui un singolo agente o uno script deterministico sono migliori:

Workflow lineare e ben specificato. Se il processo è "prendi A, trasforma con regola fissa, scrivi B", uno script più una sola chiamata LLM (se necessaria) è più affidabile, più economico, più auditabile.

Bassa varianza di input. Se gli input sono molto omogenei e le regole di lavorazione sono note, un sistema multi-agente aggiunge non-determinismo dove non serve.

Volumi enormi a costo unitario basso. Multi-agente è per task ad alto valore unitario. Per milioni di task da pochi millesimi ciascuno, l'overhead non si ammortizza.

Quando in dubbio, partire da single-agente o script. Si passa a multi-agente quando il single non basta più, mai prima.

Conclusione operativa

Un sistema multi-agente in produzione, fatto bene, ha cinque proprietà: pattern espliciti (non tutto è swarm), governance documentata (audit trail e registro AI Act), monitoring a quattro dimensioni (latenza, errori, tool-abuse, drift), oversight umano dove conta, controllo del costo per turno e per agente.

Il salto dal POC alla produzione non è una questione di "scalare il prompt". È una questione di costruirgli intorno l'infrastruttura che il POC, per definizione, non aveva. Chi sottovaluta questa differenza arriva al primo incidente e scopre che l'incidente non è "il modello ha sbagliato": è "il sistema non era progettato per gestire l'errore del modello".

Costruire questa infrastruttura da zero richiede mesi di ingegneria e una cultura di rigore operativo che pochi team interni possono permettersi solo per il proprio caso d'uso. Adottare una piattaforma che la porta già con sé accorcia il time-to-production da mesi a settimane e rimuove dalla lista dei rischi tutto ciò che non riguarda il dominio specifico del cliente.

Per chi sta valutando il salto: la conversazione utile non è "quale framework di orchestrazione". È "quali pattern, quale governance, quale baseline di metriche". Da lì il framework segue.

— Matteo Mirabelli, fondatore di Knowlee