Agenti AI in produzione: il problema dell’affidabilità e la seconda ondata di architetture

Gli agenti AI stanno entrando in produzione, e con loro arriva un problema che molti team avevano sottovalutato: l’affidabilità. Non basta che un modello linguistico funzioni bene in laboratorio. In produzione, un workflow AI che dura ore deve sopravvivere a crash, preservare lo stato, riprendersi dai guasti, gestire i costi di inferenza e coordinarsi con API, strumenti e sistemi enterprise esistenti.

Dopo una prima ondata focalizzata sulla velocità di deployment, le organizzazioni si trovano a dover tornare indietro e riprogettare quelle prime implementazioni. Lo ha detto Preeti Somal, Senior VP Engineering di Temporal Technologies, durante l’AI Impact Series di New York. "Abbiamo molti clienti che vengono da noi per costruire la versione 2.0 dello stesso agente", ha spiegato. "Hanno dovuto muoversi velocemente, ma non si sono preoccupati dell’impianto idraulico. Le cose crashano e bruciano, e poi tornano a ricostruire su fondamenta solide."

Il problema non è nuovo, l’AI lo amplifica

Per Temporal, azienda di orchestrazione di workflow la cui infrastruttura esisteva già prima della moda degli agenti AI, questo cambiamento riflette una presa di coscienza più ampia: i sistemi AI in produzione richiedono esecuzione durevole, gestione dello stato, visibilità sui workflow e meccanismi di recupero quando i modelli o i sistemi downstream falliscono.

"Questi schemi non sono nuovi", ha detto Somal. "L’AI li amplifica e basta." I sistemi basati su agenti introducono complessità aggiuntiva perché spesso coinvolgono processi multi-step lunghi, che attraversano servizi, modelli, API e strumenti diversi. Un singolo workflow può chiamare più modelli linguistici, accedere a sistemi di retrieval, attivare applicazioni esterne e gestire lo stato per ore o giorni.

Le domande ingegneristiche arrivano solo dopo il deploy. "La gente scrive agenti ma non ha pensato a cosa succede se l’agente crasha", ha detto Somal. "Devo far ripartire l’intero flusso dell’agente da capo?" Per le imprese con vincoli di costo, la risposta è importante: riavviare i workflow dopo un fallimento può moltiplicare le spese di inferenza, aumentare la latenza e creare esperienze cliente negative.

Somal ha paragonato il momento attuale a una fase precedente dell’adozione del cloud enterprise, quando le organizzazioni migravano i carichi di lavoro senza riprogettare le architetture sottostanti. "Questa corsa a fare AI in un mondo in cui non hai nemmeno modernizzato la tua applicazione mi ricorda un po’ il lift-and-shift del cloud", ha detto. "Tutti si sono resi conto che spendevano più soldi sul cloud senza ottenere valore."

Workflow lunghi e architettura nuova

I workflow enterprise coinvolgono sempre più agenti che operano su finestre temporali lunghe, a volte molte ore, interagendo con strumenti e sistemi. I problemi di affidabilità si accumulano quando i workflow persistono nel tempo, e questo impatta sia lo stato che la memoria, due concetti spesso trattati come intercambiabili nelle conversazioni sull’AI.

Lo stato riguarda l’esecuzione del workflow: dove si trova l’agente in un processo, quali azioni sono già state completate e da dove riprendere dopo un guasto. La memoria o contesto cattura le informazioni che un agente si porta avanti attraverso interazioni o compiti. "Lo stato dell’agente riguarda quali passaggi e azioni sono stati eseguiti, e se qualcosa crasha, da dove vuoi riprendere, mentre il contesto e la memoria sono un’altra cosa", ha spiegato Somal.

Questa distinzione diventa importante quando le imprese vanno oltre le semplici chatbot verso processi aziendali più lunghi. Somal ha fatto l’esempio di Abridge, cliente nel settore sanitario, dove i workflow processano le visite mediche attraverso più fasi: elaborazione audio, riassunto, chiamate ai modelli e generazione del riepilogo post-visita. "Non c’è un solo pezzo in quel flusso", ha detto. "Prendere i video e segmentarli, fare i riassunti, chiamare gli LLM, generare il riepilogo post-visita: tutto questo viene orchestrato."

La colonna vertebrale deterministica

Un framework utile per il design AI enterprise è la colonna vertebrale deterministica, ha detto Somal, cioè come Temporal vede il proprio ruolo. "Indica il percorso che vuoi seguire. Chiama il cervello, ma se il cervello non risponde, lo richiama. Se il cervello risponde ma il passo successivo fallirà, riprende da dove è avvenuto il fallimento."

In questo schema, il modello linguistico agisce come sistema probabilistico che produce output variabili, mentre il software di orchestrazione mantiene l’affidabilità dell’esecuzione intorno a esso. Il concetto è importante perché i sistemi enterprise richiedono coerenza anche quando i modelli rimangono non deterministici. Un workflow di procurement, un riepilogo sanitario, un’escalation del supporto clienti o un processo di conformità non possono semplicemente fallire in silenzio perché una chiamata al modello è scaduta o una dipendenza esterna è crashata.

"Quello che ti interessa di più è assicurarti di poter recuperare e di non pagare il token tax se qualcosa va storto", ha detto Somal.

Visibilità e costi dei token

Con i leader enterprise che valutano il ROI dell’AI, la visibilità sui costi è diventata una preoccupazione crescente. Gli agenti a lunga esecuzione fanno spesso multiple chiamate ai modelli attraverso workflow complessi, creando pattern di spesa opachi. Somal ha descritto un vantaggio operativo dell’orchestrazione: la visibilità su dove si accumulano i costi. Poiché i workflow sono osservabili passo dopo passo, i team possono vedere dove vengono consumati i token in un processo agente. "Hai visibilità sull’intero flusso in un unico pannello", ha detto. "Puoi vedere dove stai spendendo i token in un agente che ha più passaggi e chiama sistemi diversi."

Il recupero dei workflow influisce anche sull’efficienza dei costi. Senza orchestrazione durevole, un fallimento in fase avanzata può costringere a riavviare l’intero processo dall’inizio, comprese tutte le chiamate ai modelli precedenti. Somal ha detto che i sistemi progettati per il recupero possono riprendere l’esecuzione dal punto di interruzione. "Riprendi da dove è avvenuto il crash. Ti risparmiamo il costo di far ripartire l’agente dal passo uno."

Percorsi pavimentati e competenze dei partner

Le preoccupazioni sulla governance sono un altro schema emergente con l’affermarsi dell’AI agentica. Piuttosto che adottare sistemi gestiti completamente preconfezionati, Somal ha detto che le imprese vogliono framework interni standardizzati che forniscano guardrail mantenendo la flessibilità, e implementare funzionalità necessarie come controlli di governance, politiche di selezione dei modelli, sistemi di identità, gestione dei costi e osservabilità. "Le imprese stanno cercando di costruire questi percorsi pavimentati", ha detto. "Prendere qualcosa già pronto probabilmente non funziona perché ci sono tutti questi altri requisiti."

Con le organizzazioni che tornano a rivedere le prime implementazioni, le sfide assomigliano sempre meno a un problema di modello e sempre più a un problema di ingegneria dei sistemi. Temporal è posizionata per aiutare le imprese in questo passo successivo, in parte perché per molte organizzazioni esisteva già come parte di programmi di modernizzazione più ampi prima che l’AI diventasse una priorità strategica. "Temporal è già nell’enterprise", ha detto Somal. "Prenderlo ed estenderlo alle piattaforme AI e agenti sembra molto naturale."