La parola 'agente AI' è diventata un termine ombrello che copre cose molto diverse fra loro. Un chatbot che risponde a clienti, un sistema che processa documenti, un orchestratore che coordina dieci tool diversi: tutti vengono presentati come 'agenti'. Il problema è che le architetture sottostanti sono profondamente diverse, e scegliere quella sbagliata è il modo più rapido per spendere sei mesi a costruire qualcosa che poi nessuno usa.
Nei nostri progetti con PMI italiane abbiamo standardizzato tre architetture di riferimento. Non sono le uniche possibili, ma coprono il novanta per cento dei casi reali. Conoscerle prima di iniziare significa scegliere consapevolmente, non improvvisare. Ognuna ha pregi, vincoli, costi di sviluppo diversi.
Architettura 1: workflow lineare con human-in-the-loop
È l'architettura più semplice e la più sottovalutata. L'agente segue una sequenza definita di passi (estrai, analizza, classifica, propone azione) e in uno o più punti chiave si ferma per chiedere conferma a un operatore umano. La conferma può essere una semplice approvazione, una modifica del risultato, o una decisione di stop.
Funziona bene quando il processo è ripetibile ma le decisioni finali devono restare a un umano per ragioni normative, di responsabilità contrattuale, o di sensibilità del dato. È il pattern più diffuso nelle PMI italiane perché si presta a un graduale incremento di autonomia: si parte con un human-in-the-loop a ogni step, e via via che la fiducia cresce si rimuovono i check intermedi.
Caso reale: anagrafica fornitori in un'azienda alimentare
Una PMI alimentare con circa 60 fornitori attivi e nuovi onboarding mensili. Il processo manuale richiedeva 4-6 ore per fornitore: lettura visura camerale, verifica certificazioni HACCP, controllo dichiarazioni allergeni, allineamento codici prodotto. L'agente estrae automaticamente i dati dai PDF caricati, verifica scadenze certificative, propone un draft di scheda fornitore strutturata. Un addetto qualità conferma in 15-20 minuti. Tempo medio attuale: 25 minuti per fornitore, contro le 5 ore iniziali. ROI raggiunto in nove settimane.
Architettura 2: multi-agent orchestration
Più agenti specializzati lavorano in parallelo o in sequenza, coordinati da un orchestratore. Ogni agente ha un ruolo specifico, accesso limitato a determinati strumenti, e un'identità chiara nel sistema. L'orchestratore decide quali agenti coinvolgere in base al task, gestisce il passaggio di contesto, e aggrega i risultati.
Funziona quando il task è complesso e richiede competenze diverse che non si addensano bene in un singolo prompt. Lavorare con più agenti specializzati produce output di qualità più alta che cercare di far fare tutto a un mega-prompt. Lo svantaggio è la complessità di debug: quando qualcosa va storto, capire quale agente ha sbagliato e in quale handover richiede una buona instrumentazione logging fin dal primo giorno.
Caso reale: gestione richieste tecniche in azienda di servizi energetici
Un cliente nel settore servizi energetici riceve dai propri installatori richieste tecniche miste: domande commerciali, richieste di disegni esecutivi, conferme di scadenze contrattuali, dubbi normativi. Prima dell'agente, una persona dedicata smistava manualmente con tempo medio di risposta superiore alle 4 ore lavorative. Abbiamo costruito un'architettura a tre agenti coordinati: un classifier identifica il tipo di richiesta, un retrieval agent recupera documenti rilevanti dalla knowledge base interna, un drafter compone la risposta. Tempo medio di prima risposta sceso a 9 minuti, con tasso di approvazione delle bozze al 78%.
“Il punto debole degli approcci multi-agent non è la tecnologia: è che ogni agente ha un proprio contesto che va passato pulito al successivo. Senza una disciplina rigorosa di handover, gli errori si moltiplicano. È un problema di design, non di modello.”
Architettura 3: agenti reattivi su trigger
L'agente non è invocato esplicitamente da un umano: si attiva automaticamente in risposta a un evento. L'evento può essere un'email che arriva, un dato che cambia in un database, un sensore che invia un valore fuori soglia, una scadenza che si avvicina. L'agente elabora il trigger, decide se intervenire, e — in base alla configurazione — agisce direttamente o avvisa un operatore.
Funziona quando il volume degli eventi è alto e la maggior parte richiede una risposta standardizzata, ma una minoranza significativa richiede attenzione umana. La parte difficile non è la reattività: è la regola di triage che separa cosa l'agente può gestire da solo da cosa deve passare all'umano. Senza una regola di triage robusta, l'agente intasa le inbox di alert o, peggio, agisce dove non dovrebbe.
Caso reale: monitoraggio performance in azienda sport-tech
Una sport-tech italiana che fornisce piattaforme di analisi performance per atleti professionisti. Ogni allenamento genera circa 200 metriche per atleta. Il coach non ha tempo di leggerle tutte. L'agente analizza i dati in arrivo, confronta con baseline storiche, e produce un alert solo quando si verificano deviazioni significative: indicatori di affaticamento anomalo, miglioramenti notevoli da segnalare, pattern di rischio infortunio. Risultato: il coach riceve in media 3-5 alert al giorno invece di leggere 1.400 righe di dati. Tempo speso sull'analisi performance: da 90 minuti al giorno a 15-20 minuti.
Come scegliere l'architettura giusta
Tre domande prima di iniziare. La risposta a queste tre, fatta onestamente, ti porta direttamente all'architettura giusta per il tuo caso.
- Il processo ha un trigger naturale (evento) o viene avviato esplicitamente da un umano? Trigger naturale orienta verso architettura 3. Avvio esplicito orienta verso 1 o 2.
- Il task è omogeneo (un solo tipo di problema) o eterogeneo (più tipi che richiedono competenze diverse)? Omogeneo orienta verso 1. Eterogeneo orienta verso 2.
- Quali decisioni devono restare umane per legge, contratto o policy aziendale? Più sono numerose, più il design tende verso il pattern human-in-the-loop dell'architettura 1.
Tre errori che vediamo ricorrenti
Tre pattern di fallimento si ripetono nei progetti che falliscono nelle prime sei settimane. Riconoscerli prima evita una decina di settimane di rilavorazione.
- Sovrastimare la complessità iniziale. Si parte con multi-agent quando un workflow lineare sarebbe stato sufficiente. Risultato: tre mesi di sviluppo per un problema risolvibile in sei settimane.
- Sottovalutare la disciplina dei dati. Tutte e tre le architetture richiedono dati strutturati e accessibili. Se il knowledge layer è inconsistente, nessun agente funziona bene.
- Saltare il PII masking. Qualunque architettura tu scelga, se i dati personali entrano nel prompt senza mascheramento, hai un problema GDPR che la tecnologia non risolve.
Scegliere l'architettura sbagliata costa più che ritardare di una settimana per scegliere bene. Le architetture non sono mode, sono strumenti diversi per problemi diversi. Se hai in mente un'automazione AI ma non sei sicuro quale dei tre pattern si adatti meglio, parliamone in una chiamata gratuita di 30 minuti: in mezz'ora capiamo dove vuoi arrivare e quale dei tre approcci ti porta lì con la minima complessità.