Agenti AI in produzione: come progettare l’architettura

Per progettare l’architettura degli agenti AI, parti da un solo agente capace di analizzare un caso, proporre un’azione e fermarsi in attesa dell’approvazione. Acquista il modello e l’infrastruttura standard; sviluppa le regole di business, i limiti dei permessi e i meccanismi che dimostrano che il lavoro è stato svolto correttamente.

Un agente di assistenza diventa utile quando sa collegare il messaggio di un cliente all’account, alla policy e all’azione giusti. Diventa affidabile quando l’applicazione che lo gestisce sa ricostruire a quali dati ha avuto accesso, impedire modifiche non autorizzate e riprendere il lavoro se uno strumento non funziona.

Immagina il sistema come una rete di trasporto. Il modello sceglie il percorso, gli strumenti permettono di raggiungere le destinazioni, la memoria conserva il tragitto e l’orchestrazione regola gli spostamenti. I controlli di sicurezza e i passaggi di approvazione governano gli accessi; valutazioni e log indicano se i passeggeri sono arrivati nel posto giusto.

Le descrizioni dei componenti che seguono sono state verificate sulla documentazione di Anthropic, OpenAI, Google Cloud e sulla specifica Model Context Protocol il 25 ottobre 2026. Il workflow di assistenza è un esempio progettuale, non la descrizione di un sistema già operativo presso un cliente.

Agenti AI: cosa deve garantire l’applicazione

L’architettura stabilisce quali scelte spettano al modello e quali regole deve far rispettare l’applicazione. Questa distinzione conta più del nome del framework.

Il concetto di LLM potenziato di Anthropic, cioè un modello linguistico collegato a sistemi di recupero delle informazioni, strumenti e memoria, offre un buon punto di partenza. La sua guida distingue i workflow, il cui percorso è definito nel codice, dagli agenti, che scelgono dinamicamente le azioni successive; raccomanda di aggiungere complessità solo quando il compito lo richiede. La guida di Anthropic agli agenti

Nel triage delle richieste di assistenza, il modello potrebbe decidere se consultare una guida alla risoluzione dei problemi o verificare un ordine. Spetta comunque al codice dell’applicazione stabilire di quale cliente può leggere i dati, se il rimborso proposto è consentito e cosa succede se l’esecuzione si interrompe a metà.

Le attività prevedibili devono restare tali. Autenticare un account, verificare un diritto di accesso e registrare un’azione completata non richiedono l’improvvisazione di un agente. Affida al modello la parte incerta: comprendere il messaggio, selezionare le informazioni rilevanti e proporre il passo successivo più utile.

Schema dell’architettura: livelli e collegamenti

Un agente ha bisogno di un ciclo controllato, con stato persistente e verifiche che ne accompagnino l’esecuzione. I livelli descritti qui rappresentano responsabilità: non richiedono ciascuno un servizio o un abbonamento separato.

Leggi i collegamenti come un ciclo: l’applicazione prepara il contesto, il modello richiede un’azione, il runtime la verifica e la esegue, e il risultato entra nel contesto della decisione successiva. La guida al ciclo degli agenti approfondisce questo meccanismo e le condizioni di arresto.

Modello: interpretare il caso e proporre l’azione successiva

OpenAI Agents SDK, la libreria di OpenAI per costruire workflow con agenti, riunisce modello, istruzioni e strumenti in un Agent; il modello interpreta il ticket e propone come procedere. In questo progetto riceve un problema di accesso all’account e richiede il record relativo al diritto di accesso prima di preparare una risposta. Scegli il modello valutandolo su casi di assistenza rappresentativi: una risposta ben scritta non dimostra che abbia selezionato lo strumento corretto né che abbia l’autorità per agire. Le definizioni degli agenti di OpenAI

Strumenti e MCP: accedere ai sistemi aziendali

Model Context Protocol (MCP), un’interfaccia standard tra applicazioni AI e funzionalità esterne, definisce strumenti dotati di un nome e di un inputSchema, individuabili tramite tools/list e richiamabili tramite tools/call. La ricerca di un account può essere esposta via MCP oppure attraverso una normale funzione che chiama un’API aziendale; in entrambi i casi, il servizio sottostante deve validare gli argomenti e limitare l’accesso all’account corretto. MCP standardizza il collegamento; la guida a MCP approfondisce il protocollo e i suoi confini di fiducia. La specifica degli strumenti MCP

Memoria: conservare il contesto giusto

Agent Development Kit (ADK), il framework di Google per sviluppare agenti, usa Session e state per le informazioni relative a un’interazione e supporta la memoria tra sessioni tramite componenti come Memory Bank. Nell’assistenza, conserva il caso corrente e l’approvazione in sospeso nell’archivio dell’applicazione, recupera i dati aggiornati dell’account dalla fonte e memorizza le preferenze del cliente solo quando è opportuno. Sono compiti distinti: la guida alla memoria degli agenti chiarisce le differenze tra contesto, archiviazione della sessione e memoria a più lungo termine. La guida architetturale di Google Cloud

Orchestrazione: gestire avanzamento, pause e ripristino

La guida di OpenAI alla creazione di agenti descrive Agents SDK come il componente che gestisce il ciclo degli strumenti, i passaggi di controllo tra agenti e i guardrail, fornendo all’applicazione un motore di esecuzione per le attività guidate dal modello. Attorno a questo motore, salva in modo persistente lo stato del ticket: in analisi, in attesa di revisione, in esecuzione o concluso. Così un processo riavviato può riprendere il caso. La guida all’orchestrazione spiega come inserire le esecuzioni degli agenti in un processo aziendale più ampio. La guida di OpenAI agli agenti

Guardrail e approvazione umana: controllare gli effetti delle azioni

OpenAI Agents SDK distingue i guardrail automatici dalle interruzioni per approvazione, che sospendono una chiamata a uno strumento e restituiscono uno stato da cui riprendere l’esecuzione. Per l’agente di assistenza, verifica automaticamente l’accesso all’account e gli argomenti proposti, poi richiedi che una persona autorizzata approvi ogni modifica sensibile prima dell’esecuzione. Fai rispettare questi controlli in corrispondenza dello strumento che compie l’azione; la guida ai guardrail li esamina in dettaglio. Guardrail e revisione umana in OpenAI

Valutazione e osservabilità: ricostruire i fatti e giudicare il risultato

Il tracing di OpenAI Agents SDK registra chiamate al modello, chiamate agli strumenti, passaggi di controllo e attività dei guardrail; la guida alla valutazione delle tracce spiega invece come assegnare un punteggio al comportamento del workflow secondo criteri espliciti. L’osservabilità mostra come si è svolta la gestione di un ticket; la valutazione verifica se l’agente ha selezionato l’account corretto, rispettato la policy e prodotto una risposta sostenuta dai riscontri. Definisci con cura raccolta e conservazione dei dati prima di confrontare gli strumenti di osservabilità per LLM. Il tracing dell’SDK, la valutazione degli agenti

L’architettura di riferimento di Google Cloud combina ADK, Cloud Run, accesso ai modelli, connessioni MCP, Model Armor e osservabilità in una soluzione concreta da distribuire. L’esempio documentato esclude esplicitamente dal diagramma memoria e archiviazione delle sessioni: la persistenza dello stato del caso resta quindi una scelta progettuale, non una funzionalità da dare per inclusa. L’architettura di riferimento

Dal ticket in arrivo alla risposta risolutiva

Affida all’agente un caso circoscritto, il cui completamento sia verificabile. In questo esempio, un cliente dichiara di aver pagato per l’accesso ma di non riuscire ancora a usare il servizio; l’agente può indagare e preparare una correzione, mentre nella fase iniziale un responsabile dell’assistenza approva le modifiche all’account e la risposta da inviare.

I nomi degli strumenti qui sotto indicano funzioni applicative da implementare, non un’integrazione di assistenza già pronta offerta da un fornitore.

1. 1

   Ricevere e identificare il caso

   Il webhook del ticket, un evento inviato dal sistema di assistenza, crea o riprende un caso usando l’identificativo esterno del ticket. Autentica il cliente attraverso il flusso già previsto per gli account; un indirizzo email scritto nel messaggio non deve bastare a ottenere l’accesso a un account. Salva il messaggio in arrivo come contenuto del cliente non attendibile.

2. 2

   Recuperare i riscontri con strumenti circoscritti

   Metti a disposizione dell’agente funzioni come get_account_entitlement e search_support_policy. Nel codice dell’applicazione, vincola l’accesso all’account all’identità autenticata e restituisci il record pertinente e il riferimento alla policy. Il modello può scegliere quali riscontri richiedere senza ottenere accesso indiscriminato al database.

3. 3

   Preparare una proposta fondata sui riscontri

   Il modello confronta la segnalazione del cliente con il record dell’account e la policy applicabile. Se i riscontri giustificano una correzione del diritto di accesso, prepara una bozza della modifica e della risposta; se mancano informazioni o emergono contraddizioni, chiede chiarimenti o passa il caso a un livello superiore. Salva insieme alla proposta i riferimenti ai riscontri, così chi la esamina può verificarne il fondamento.

4. 4

   Fermarsi prima dell’operazione aziendale

   Verifica che l’operazione proposta rispetti la policy, poi salva l’azione in sospeso e lo stato dell’approvazione. Mostra al responsabile dell’assistenza l’account interessato, la modifica esatta proposta, i riscontri a sostegno e la risposta destinata al cliente. Se la proposta viene respinta, la scrittura resta bloccata e il caso torna in revisione o passa alla gestione manuale.

5. 5

   Eseguire e verificare il risultato

   Dopo l’approvazione, verifica di nuovo che account e proposta corrispondano ancora a quanto esaminato, poi richiama lo strumento di correzione. Se il servizio sottostante lo supporta, usa una chiave di idempotenza: un identificativo che impedisce di applicare nuovamente la stessa operazione in caso di nuovo tentativo. Accerta che il diritto di accesso risultante sia corretto prima di inviare una risposta che ne dichiari il ripristino; registra l’esito dell’invio prima di segnare il caso come completato.

6. 6

   Usare l’esito come riscontro per la valutazione

   Collega alla traccia il risultato dell’esecuzione, la risposta approvata e lo stato finale del caso. Affida gli esiti incerti a una persona, senza interpretare un timeout come un successo o un fallimento. Quando la revisione individua un errore, conserva nel set di valutazione un esempio da cui siano stati opportunamente rimossi i dati sensibili.

Il problema più critico è una scrittura dall’esito ambiguo: il servizio che gestisce gli account potrebbe aver applicato la modifica senza che l’applicazione ne abbia ricevuto la risposta. Prima di riprovare, verifica lo stato nel sistema di origine e riconcilialo con quello dell’applicazione. Una trascrizione che riporta «Ripristinerò l’accesso» documenta un’intenzione, non dimostra che l’accesso sia cambiato.

Architetture per agenti AI: quando serve davvero un altro agente

Mantieni un solo agente finché il compito condivide una policy coerente, lo stesso insieme di strumenti e un unico responsabile. Aggiungi uno specialista quando risolve un’esigenza dimostrabile di separazione delle responsabilità, poi verifica se il miglioramento regge anche con il coordinamento aggiuntivo.

OpenAI distingue gli handoff, in cui uno specialista prende in carico la conversazione, dagli agenti usati come strumenti, in cui l’agente principale chiama uno specialista ma mantiene la responsabilità della risposta. La guida raccomanda la separazione quando istruzioni, capacità o policy differiscono in modo sostanziale. Orchestrazione e passaggi di controllo

Nel caso di assistenza, cercare un articolo della guida e preparare una risposta non giustifica automaticamente agenti separati. Una contestazione di fatturazione potrebbe invece richiederli: può comportare una policy diversa, strumenti finanziari ad accesso limitato e un altro revisore. Puoi chiamare quello specialista per una valutazione circoscritta, lasciando all’agente di assistenza la responsabilità del caso, oppure trasferire esplicitamente la gestione quando deve subentrare il workflow di fatturazione.

Schema multiagente: separare dove cambiano le responsabilità

Una policy diversa è un buon motivo per valutare la separazione, ma non è un requisito universale. Anche attività distinte di raccolta dei riscontri possono giustificare agenti che lavorano in parallelo, purché il responsabile finale sappia riconciliare risultati contrastanti e il beneficio osservato giustifichi il lavoro aggiuntivo dei modelli.

Prima di aggiungere uno specialista, scrivi quale problema dovrebbe risolvere: scelta dello strumento sbagliato, istruzioni in conflitto, contesto eccessivo o competenze mancanti. Confronta la nuova architettura sugli stessi casi, compresi quelli che producono errori. Mantienila solo se il risultato migliora abbastanza da giustificare latenza, consumi, debugging e lavoro di revisione aggiuntivi; è un criterio decisionale, non una promessa di prestazioni superiori.

Chiamare gli agenti «ricercatore», «critico» e «responsabile» non garantisce giudizi indipendenti. Se condividono gli stessi riscontri errati, il loro accordo può limitarsi a ripetere l’errore. Per una classificazione più ampia, consulta la mappa dei tipi di agenti AI.

Cosa acquistare e cosa gestire direttamente nell’architettura

Acquista i componenti intercambiabili e mantieni il controllo delle regole e degli impegni di business. Per un primo agente in produzione, il motivo più solido per sviluppare un componente in proprio è che il workflow richiede un comportamento che il componente disponibile non può rappresentare o esporre.

Per i founder: acquista un prodotto gestito per agenti se supporta il tuo workflow effettivo, i passaggi di approvazione richiesti e l’esportazione dei riscontri. Sviluppa attorno a componenti standard quando sono le policy specifiche degli account o il comportamento delle integrazioni a distinguerti. Una demo convincente non basta se non puoi riprendere un caso sospeso o analizzare un’azione fallita.

Per CTO e sviluppatori: mantieni gli strumenti aziendali circoscritti e verificabili indipendentemente dal modello. Un runtime gestito può ospitare l’applicazione; non può dedurre la differenza tra un cliente che chiede un rimborso e un dipendente autorizzato a emetterlo. Definisci questa distinzione nel servizio che esegue l’operazione.

Per i responsabili operativi: presidia la coda delle eccezioni e definisci quando un caso è risolto. Specifica chi subentra nei casi irrisolti, quali riscontri riceve e quando è possibile chiudere un ticket. Una casella di approvazioni che nessuno controlla lascia il workflow incompiuto.

L’esecuzione di codice è facoltativa per questo agente di assistenza. Se in futuro un’attività richiederà di eseguire codice generato, affronta l’isolamento come una decisione separata e consulta la guida alle sandbox per il codice degli agenti; non introdurre una shell generica solo per cercare un account.

Dove inserire l’approvazione umana e cosa registrare da subito

Colloca l’approvazione immediatamente prima dell’azione che richiede un’autorità delegata. Esaminare il testo prodotto dall’agente dopo che l’account è già stato modificato non può impedire quella modifica.

Il meccanismo di approvazione di OpenAI restituisce un’esecuzione sospesa e uno stato da cui riprenderla; l’applicazione risolve la decisione in sospeso e riprende l’esecuzione. La stessa documentazione avverte che i controlli di input e output a livello di agente non si applicano prima e dopo ogni chiamata intermedia agli strumenti: per questo serve una validazione specifica nel punto in cui avviene l’azione. Il ciclo di approvazione e i confini dei workflow

Nella fase iniziale dell’esempio, il revisore vede insieme la modifica esatta all’account e la risposta. Se dopo la revisione cambiano l’azione, il destinatario o i riscontri, richiedi una nuova decisione. Registra chi ha approvato cosa, quale policy si applicava e se l’esecuzione ha rispettato l’approvazione.

Usa l’elenco seguente come base per definire cosa registrare nei log. Una trace, o traccia, collega gli eventi di un caso; uno span registra una singola operazione al suo interno.

• Identità del caso: identificativo del caso, identificativo della traccia, evento di origine e riferimento all’account autenticato. Usa riferimenti, senza duplicare ovunque i dati del cliente.
• Configurazione: identificativo del modello restituito dal provider, versione delle istruzioni, versione dello schema degli strumenti e versione della policy. Servono a ricostruire il comportamento previsto in quel momento.
• Riscontri: identificativi dei documenti recuperati, revisioni pertinenti e ambito di accesso. Registra ciò che ha sostenuto la decisione senza copiare indiscriminatamente dati privati.
• Azioni: nome dello strumento, argomenti con i dati sensibili oscurati, timestamp, durata, stato del risultato e identificativo del tentativo o chiave di idempotenza. Conserva informazioni sufficienti a distinguere un’azione proposta da una completata.
• Decisioni: esiti della validazione, motivo dell’escalation, stato dell’approvazione, riferimento al revisore e proposta approvata.
• Esito e utilizzo: stato finale del ticket, effetti confermati, risultato della consegna, consumi riportati dal provider ed etichette di valutazione. Traccia le correzioni richieste dai clienti o i casi riaperti quando il sistema di assistenza rende disponibili questi dati.

È uno schema applicativo consigliato, non la promessa che un SDK raccolga automaticamente ogni campo. Limita gli accessi, definisci i tempi di conservazione e rimuovi i segreti prima dell’esportazione. Non fare del ragionamento interno del modello un requisito di logging: la ricostruzione verificabile deve basarsi su input, output, azioni e riscontri osservabili.

I limiti che contano e le aspettative da ridimensionare

Il limite più importante è l’autorità che deleghi. Stabilisci tetti espliciti alla durata dell’esecuzione, all’attività degli strumenti e al consumo di risorse, insieme a un percorso chiaro di escalation; scegli i valori in base al carico di lavoro e ai requisiti del servizio, senza copiare limiti arbitrari da una demo.

La memoria non è una fonte autorevole. Se una conversazione salvata afferma che il cliente ha accesso ma il sistema degli account dice il contrario, chiarisci la discrepanza verificando i record autorevoli aggiornati. Conservare più testo non rende attuali i riscontri obsoleti.

MCP non concede permessi. La sua specifica degli strumenti richiede comunque controlli di accesso e validazione degli input. Un connettore che espone un’operazione ad ampio raggio richiede la stessa verifica delle autorizzazioni aziendali di un’API sviluppata in proprio. I requisiti di sicurezza di MCP

Un’esecuzione completata non equivale a un caso risolto. Valuta se è stato modificato l’account corretto, se la policy è stata rispettata e se la risposta corrisponde al risultato. La guida di OpenAI alla valutazione passa dall’esame delle tracce a dataset per valutazioni ripetibili, così da giudicare le modifiche con criteri coerenti. La valutazione dei workflow con agenti

Più agenti non eliminano la responsabilità finale. Qualcuno deve rispondere della risposta conclusiva, dei riscontri condivisi e delle eccezioni irrisolte. Uno specialista è utile perché ha una responsabilità diversa, non perché rende più sofisticato il diagramma dell’architettura.

Domande frequenti sull’architettura degli agenti AI

Che cos’è l’architettura di un agente AI?

L’architettura di un agente AI organizza decisioni del modello, strumenti, memoria, orchestrazione, controlli e valutazione affinché un’applicazione possa svolgere un compito. Per un agente aziendale, stabilisce anche chi può autorizzare le azioni e come verificarne il completamento.

Che cosa si intende per agente IA?

Un agente IA usa un modello per scegliere azioni orientate a un obiettivo, ne osserva i risultati e decide come proseguire. La sua autonomia utile è delimitata dagli strumenti, dai permessi e dalle regole di arresto forniti dall’applicazione.

Quali tipi di architettura si possono usare per gli agenti?

Una distinzione pratica è tra un workflow predefinito, un singolo agente che sceglie fra più strumenti e specialisti che collaborano. La scelta dipende dalla prevedibilità del compito e dalla necessità di assegnare a responsabilità diverse strumenti, policy o titolari distinti; si tratta di schemi di implementazione, non di una classificazione universale.

Il primo passo: disegnare il caso prima di scegliere lo stack

Puoi partire subito se hai una coda di assistenza con casi ricorrenti, accesso ai record di origine e una persona responsabile delle eccezioni. Scegli un caso rappresentativo e indica l’evento in ingresso, le letture consentite, le scritture proposte, il punto di approvazione e i riscontri necessari per la chiusura. Nella fase iniziale, fai produrre al workflow bozze da sottoporre a revisione; usa poi gli errori osservati per decidere quali permessi ampliare in modo responsabile.

Rimanda l’esecuzione autonoma se non sono ancora chiari l’identità dell’account, chi è responsabile della policy o come dimostrare il completamento. Nel frattempo puoi migliorare il recupero delle informazioni e la qualità delle bozze. Se il workflow segue già regole deterministiche affidabili e non richiede il giudizio di un modello, mantieni quell’automazione.

Il primo risultato da produrre dovrebbe essere un caso di cui sai spiegare ogni passaggio, dalla ricezione all’esito, compreso ciò che accade quando l’approvazione viene negata o il risultato di uno strumento resta sconosciuto.

Per guide pratiche su come sviluppare e gestire sistemi AI, iscriviti alla newsletter.