Agenti AI: come coordinarli tra deleghe, approvazioni e costi

L’orchestrazione degli agenti AI funziona meglio quando si stabilisce chi è responsabile del passo successivo prima di aggiungere un altro agente. Dalla presa in carico della richiesta alla ricerca, dalla stesura all’approvazione, 4 schemi coprono le decisioni principali: un agente coordinatore con agenti esecutori, il passaggio di consegne tra specialisti, un grafo con checkpoint e un workflow durevole che racchiude gli agenti. L’autorizzazione a inviare messaggi, spendere o modificare dati deve restare fuori dalla discrezionalità del modello.

La documentazione e i prezzi dell’infrastruttura riportati di seguito sono stati verificati il 13 ottobre 2026. Gli esempi aziendali sono proposte progettuali, non implementazioni documentate né benchmark prestazionali.

Come funziona l’orchestrazione degli agenti AI?

L’orchestrazione stabilisce quale agente interviene, quali informazioni riceve e quali condizioni devono essere soddisfatte prima che il suo risultato si traduca in un’azione. Un agente combina un modello con istruzioni e strumenti. L’orchestratore coordina il lavoro degli agenti: assegna le responsabilità, gestisce lo stato condiviso e definisce le transizioni consentite e le condizioni di arresto.

L’agente che prende in carico le richieste potrebbe già trasformare messaggi confusi in un brief utile. Aggiungere un ricercatore e un redattore apre però nuove questioni. Chi risolve le contraddizioni tra le fonti? Quale bozza ha visto chi deve approvarla? Se il servizio email va in timeout, il messaggio è partito? Sono domande a cui deve rispondere la progettazione del processo.

Lo schema va scelto in base al confine di responsabilità da definire:

Questi schemi possono essere annidati. Un workflow durevole che gestisce una pratica può richiamare un grafo; un nodo, cioè un passaggio del grafo, può chiedere a un agente coordinatore di delegare la ricerca. Ogni livello deve avere un compito distinto. Aggiungerne senza una responsabilità precisa significa moltiplicare i punti in cui cercare gli errori.

Rispetto a un sistema con un solo agente, cambia l’attribuzione delle responsabilità. Il responsabile operativo ha bisogno di una coda di pratiche con un referente e una prossima azione. Il responsabile tecnico ha bisogno di stato salvato e di un’esecuzione che si possa riprendere dopo un errore. Chi acquista deve sapere quali di queste responsabilità sono gestite dal servizio scelto e quali restano all’azienda.

Un agente coordinatore con esecutori: un solo responsabile

Questo schema è adatto quando il lavoro beneficia di contributi specialistici ma deve produrre una risposta coerente. È come un responsabile di proposta che chiede ai colleghi di raccogliere riscontri e poi redige il documento finale. I colleghi contribuiscono; non prendono impegni autonomi con il cliente.

Per una richiesta di supporto alle vendite, il coordinatore può affidare agli esecutori una ricerca sul cliente e una verifica interna dell’adeguatezza del prodotto, quindi riunire i risultati in un brief per la stesura.

1. 1

   Assegnare al coordinatore un risultato e un perimetro

   Il risultato atteso è una bozza di proposta supportata da riscontri. Le attività consentite sono ricerca e stesura. Inviare la proposta, promettere uno sconto e aggiornare la scheda cliente restano azioni separate.

2. 2

   Delegare ricerche con confini precisi

   Ogni esecutore deve ricevere le fonti pertinenti, gli strumenti consentiti, il risultato atteso e una regola di arresto. Le ricerche indipendenti possono procedere in parallelo; quando un’attività dipende davvero dal risultato di un’altra, occorre aspettare.

3. 3

   Raccogliere i riscontri e poi sintetizzare

   Richiedere riferimenti alle fonti, risultati e questioni irrisolte. Il coordinatore risolve le contraddizioni e prepara la bozza. Una fonte mancante resta tale: la sintesi non può trasformarne l’assenza in un’affermazione sicura.

4. 4

   Sottoporre il documento all’approvazione

   Il responsabile del cliente verifica il messaggio proposto, il destinatario e gli impegni assunti. Un passaggio di invio controllato dall’applicazione invia esclusivamente il contenuto approvato.

Claude Agent SDK, l’ambiente di esecuzione programmabile di Anthropic per gli agenti, implementa questo schema tramite subagenti: istanze separate, ciascuna con istruzioni, contesto e accesso agli strumenti propri. Si definiscono con l’opzione agents; l’agente principale li richiama tramite lo strumento Agent. Un subagente normale, non creato tramite fork, non riceve la cronologia della conversazione dell’agente padre: il prompt del compito deve quindi contenere il contesto necessario. Il padre riceve il resoconto finale. Documentazione dei subagenti Claude.

Il confine utile è un accordo esplicito sui riscontri da fornire. Un ricercatore può restituire una raccomandazione insieme ai passaggi delle fonti che la sostengono. Il limite: un contesto isolato può tralasciare un vincolo essenziale del cliente. Quel vincolo va trasmesso esplicitamente, mantenendo disponibile il materiale di supporto per la revisione.

CrewAI, un framework che organizza agenti e compiti per ruolo, offre un processo gerarchico con un manager_llm o un manager_agent. Il manager pianifica, delega e verifica i risultati dei compiti. Un processo sequenziale segue invece l’elenco delle attività, usando i risultati precedenti come contesto. Documentazione dei processi di CrewAI.

La gerarchia serve quando distribuire il lavoro richiede una valutazione. Se la ricerca deve sempre precedere la stesura, una sequenza esplicita è più facile da esaminare. Il limite: la verifica del manager resta un giudizio automatizzato. L’opzione human_input dei compiti di CrewAI richiede una revisione umana della risposta finale; ricerca e stesura devono avere soltanto capacità di lettura, così la revisione non rischia di arrivare dopo una scrittura con conseguenze reali. Documentazione dei compiti di CrewAI.

Passaggio di consegne: la prossima decisione spetta allo specialista

Il passaggio di consegne, o handoff, serve quando un altro specialista deve assumere la responsabilità della risposta successiva o di un ramo del lavoro. È come trasferire una pratica di assistenza alla fatturazione, allegando il fascicolo. È diverso dal chiedere un parere alla fatturazione e restare responsabili della pratica.

OpenAI Agents SDK, una libreria per applicazioni basate su agenti, rende esplicita questa distinzione: gli handoff trasferiscono il controllo a uno specialista, mentre gli agenti esposti come strumenti lasciano al manager la responsabilità della risposta. Il metodo JavaScript agent.asTool() supporta questa seconda modalità. Gli handoff possono includere metadati strutturati o una cronologia filtrata. Documentazione sull’orchestrazione di OpenAI.

Per una casella di posta dedicata alla gestione clienti, la sequenza può essere questa:

1. L’agente che prende in carico la richiesta riconosce una contestazione di fatturazione e raccoglie i riferimenti pertinenti al cliente e alla fattura.
2. Trasferisce la pratica allo specialista della fatturazione, insieme alla richiesta del cliente, ai fatti verificati, alle questioni aperte e alle prossime azioni consentite.
3. Lo specialista approfondisce il caso e prepara una soluzione. È responsabile della risposta successiva, anziché restituire una nota di ricerca all’agente iniziale.
4. Una persona approva ogni rimborso o modifica dell’account proposti prima che lo strumento corrispondente venga eseguito.

Il limite: un handoff trasferisce il controllo, non l’autorizzazione aziendale. L’agente che riceve una pratica non deve acquisire il permesso di rimborsare solo perché la richiesta gli è stata inoltrata. La regola di autorizzazione va applicata nel punto in cui viene eseguito lo strumento di rimborso.

Occorre anche decidere se lo specialista può restituire la pratica all’agente precedente. Prevedere un’escalation esplicita e motivata, con un limite ai trasferimenti ripetuti. Altrimenti una richiesta ambigua può rimbalzare tra specialisti, consumando chiamate al modello senza fare progressi.

Il ciclo di approvazione dell’SDK restituisce interruzioni e uno stato da cui riprendere l’esecuzione, permettendo all’applicazione di gestire la revisione. Se la decisione arriva in un secondo momento, salvare quello stato e riprendere la stessa esecuzione. I controlli di sicurezza sull’input si applicano al primo agente; quelli sull’output all’agente che produce la risposta finale. Gli strumenti sensibili richiedono controlli propri: non si può presumere che i controlli posti alle estremità esaminino ogni azione interna. Documentazione di OpenAI sulla revisione umana.

Grafi con checkpoint: rendere esplicito il prossimo passo

Un grafo è utile quando conta soprattutto stabilire i percorsi consentiti, più che lasciare a un agente l’improvvisazione del piano. È un insieme di passaggi collegati da regole. Un checkpoint salva i progressi, consentendo di sospendere il processo e riprenderlo in seguito.

LangGraph, un framework per workflow di agenti con gestione dello stato, supporta percorsi espliciti, comprese ramificazioni e attività parallele. I suoi checkpointer salvano lo stato del grafo per un thread, mentre il meccanismo interrupt() sospende l’esecuzione in attesa di un input esterno. Il thread interrotto si riprende con Command(resume=...). Schemi di workflow in LangGraph, documentazione delle interruzioni.

Per un ufficio acquisti che prepara una raccomandazione su un fornitore:

1. 1

   Salvare la pratica in uno stato strutturato

   Conservare richiesta, riferimenti alle fonti, informazioni mancanti, posizione della bozza e stato della revisione in campi con nomi espliciti. La trascrizione può accompagnare la pratica, ma non deve essere l’unico posto in cui compare lo stato attuale.

2. 2

   Definire i percorsi consentiti

   Dalla presa in carico si passa alla ricerca quando sono presenti i campi obbligatori. Se mancano informazioni, la richiesta torna al mittente. La ricerca alimenta la stesura; una verifica dei riscontri può rimandare la pratica a una ricerca mirata.

3. 3

   Creare un checkpoint e sospendere per la revisione

   Salvare la raccomandazione proposta e interrompere l’esecuzione prima delle attività soggette ad approvazione. Il responsabile degli acquisti esamina il documento esatto, i riscontri a supporto e l’azione richiesta.

4. 4

   Riprendere lungo un percorso consentito

   L’approvazione abilita l’inoltro. Una richiesta di modifica riporta alla stesura e invalida l’approvazione precedente. Un rifiuto chiude la pratica, registrandone il motivo.

Il limite: riprendere un’interruzione di LangGraph riavvia dall’inizio il nodo che la contiene. Il codice che precede l’interruzione viene eseguito di nuovo. Una scrittura con conseguenze reali va collocata in un passaggio controllato separatamente; le operazioni ripetibili devono essere idempotenti, cioè la ripetizione della stessa richiesta logica non deve produrre un effetto aggiuntivo. Regole delle interruzioni di LangGraph.

Per esempio, un nodo che inserisce una scheda fornitore e poi chiede l’approvazione ha già oltrepassato il confine. Alla ripresa potrebbe anche inserirla di nuovo. Prima si prepara la modifica proposta, poi si ottiene l’approvazione, infine si esegue la modifica approvata con un identificativo stabile dell’azione.

In produzione serve un archivio persistente per i checkpoint. I sistemi di salvataggio in memoria di LangGraph perdono i checkpoint al riavvio del processo. Un identificativo persistente del thread e uno stato conservato in un database fanno parte del progetto di ripristino. Documentazione sulla persistenza di LangGraph.

Workflow durevoli: la pratica continua anche oltre gli agenti

Un workflow durevole serve quando il processo aziendale deve proseguire anche dopo la fine della chiamata a un agente, il riavvio di un processo esecutore o una risposta esterna in ritardo. Gestisce il ciclo di vita della pratica: avvio, attesa, nuovo tentativo, ripresa, conclusione o escalation. L’agente partecipa a quel ciclo di vita.

Cloudflare Workflows, un servizio per l’esecuzione durevole di processi in più passaggi, offre passaggi persistenti e tentativi configurabili. step.do esegue il lavoro, step.waitForEvent attende una decisione esterna e instance.sendEvent la trasmette all’istanza in attesa. Cloudflare Workflows, documentazione degli eventi.

Per un team operativo che gestisce una richiesta di servizio personalizzata:

1. All’arrivo della richiesta, creare un record della pratica e un identificativo stabile del workflow.
2. Chiamare l’agente di ricerca, salvare in modo persistente il materiale con i riscontri e poi passarlo all’agente di stesura.
3. Salvare la risposta proposta e attendere l’evento di approvazione del responsabile operativo. L’interfaccia di approvazione identifica sia la pratica sia la versione del contenuto.
4. Convalidare la decisione ed eseguire l’invio o l’aggiornamento approvati in un passaggio separato.
5. Registrare la ricevuta del sistema esterno e completare la pratica. Se l’esito è incerto, verificare lo stato sul sistema esterno prima di effettuare un’altra scrittura.

Il limite: un’esecuzione durevole non rende automaticamente sicura la ripetizione di un’azione su un servizio esterno. Cloudflare raccomanda esplicitamente chiamate API idempotenti, passaggi granulari e nomi deterministici per i passaggi; sconsiglia inoltre gli effetti collaterali al di fuori di step.do. Se un servizio ha accettato un invio ma la risposta è andata persa, riprovare senza deduplicazione può causare un secondo invio. Regole di Workflows.

Configurare i nuovi tentativi per gli errori transitori, ossia quelli che possono risolversi senza modificare la richiesta. Un errore di autenticazione, un’approvazione negata o un’istruzione aziendale non valida richiedono in genere un intervento. Cloudflare mette a disposizione la configurazione dei tentativi e NonRetryableError per gli errori che devono interromperli. Documentazione sui nuovi tentativi.

Un’applicazione LangGraph con checkpoint persistenti dispone già di capacità di ripristino. Un ulteriore motore di workflow è giustificato quando gestisce un ciclo di vita più ampio, che attraversa servizi, callback e ambienti di esecuzione degli agenti. Evitare che entrambi i livelli ritentino autonomamente la stessa operazione a pagamento o con effetti esterni. Questo confine è approfondito nell’articolo su risultati dei managed agent, webhook e workflow Cloudflare.

L’approvazione umana deve precedere l’azione

Una persona deve approvare l’esatta azione che produrrà conseguenze, prima della sua esecuzione. Controllare una bozza ben scritta non basta se un altro agente può poi modificare destinatario, importo o allegato.

Per una proposta, l’interfaccia di revisione deve mostrare destinatario, messaggio finale, documento allegato, impegni commerciali e riscontri a sostegno delle affermazioni incerte. La registrazione dell’approvazione deve collegare l’identità del revisore a quella versione del contenuto e a quei parametri dell’azione.

Il componente che esegue l’azione deve controllare quella registrazione subito prima di agire. Se la bozza o la destinazione sono cambiate dopo l’approvazione, la pratica torna in revisione. Serve una decisione esplicita della persona autorizzata; commenti e modifiche suggerite devono restare separati da quella decisione.

CrewAI Flows può rendere persistente lo stato con @persist e sospendere l’esecuzione per raccogliere un riscontro con @human_feedback. Per le azioni con conseguenze reali conta un dettaglio: quando sono configurati gli esiti emit, il meccanismo usa un modello linguistico per interpretare il feedback libero e ricondurlo a un esito. Per autorizzare l’azione serve un campo di approvazione convalidato separatamente, anziché considerare l’interpretazione di un commento come unico permesso di agire. Documentazione di CrewAI Flows.

Occorre un ulteriore controllo dei permessi in ogni punto in cui il processo può effettuare un nuovo acquisto. Ritentare una connessione fallita e acquistare un nuovo risultato perché quello già completato non è piaciuto all’agente sono decisioni diverse. Nel secondo caso serve un limite di spesa definito o una nuova approvazione. L’articolo sull’approvazione umana dei nuovi tentativi degli agenti AI esamina questo problema specifico.

Cosa registrare e quali limiti imporre

Registrare quanto basta per ricostruire la pratica e applicare i limiti prima di avviare altro lavoro. Una risposta finale impeccabile non spiega perché il processo abbia inviato il documento sbagliato o superato il budget.

Nel record della pratica e negli eventi di esecuzione, prevedere questi gruppi di campi:

• Identità e relazioni tra esecuzioni: ID della pratica, ID del workflow o dell’esecuzione, ID delle esecuzioni padre e figlie, ruolo dell’agente, passaggio corrente e tentativo. Permettono di ricondurre l’errore di un esecutore alla richiesta aziendale.
• Input e configurazione: riferimenti e versioni dei materiali in ingresso, identificativo del modello, versione del prompt o della configurazione e strumenti consentiti. Permettono di individuare ciò che è cambiato tra un’esecuzione e l’altra.
• Decisioni e riscontri: decisione di instradamento, destinazione scelta, riferimenti alle fonti, risultati della convalida e informazioni mancanti. Registrare decisioni osservabili e motivazioni concise, senza dipendere dal ragionamento privato del modello.
• Approvazione: revisore, decisione, data e ora, digest del contenuto, parametri dell’azione e scadenza. Il digest è un’impronta del contenuto esaminato.
• Azioni e ripristino: nome dello strumento, parametri con i dati sensibili oscurati, chiave dell’azione o di idempotenza, ID della richiesta esterna, ricevuta, categoria di errore e nuovo tentativo programmato. Quando l’esito non è noto, mantenere uno stato di incertezza esplicito.
• Consumi ed esito: categorie di token del modello, spesa stimata e riconciliata, utilizzo di strumenti a pagamento, tempo trascorso, attesa della revisione, stato finale e accettazione o meno del risultato da parte di una persona.

Limitare l’accesso a questi log. Escludere i segreti, ridurre al minimo i dati dei clienti e usare riferimenti a materiali con accesso controllato quando copiarne l’intero contenuto comporterebbe un’esposizione inutile.

Il tracing di OpenAI Agents SDK registra chiamate ai modelli, chiamate agli strumenti, handoff e controlli di sicurezza. Collegare queste tracce tecniche al record della pratica; la sola traccia non deve fare fede, per l’azienda, sull’approvazione di un’azione rivolta al cliente. Documentazione sul tracing di OpenAI.

Gli strumenti di orchestrazione degli agenti AI richiedono limiti effettivi

Imporre limiti a spesa complessiva della pratica, turni degli agenti, chiamate agli strumenti, esecutori simultanei, profondità della delega, numero di handoff, nuovi tentativi e durata totale. Separare la scadenza dell’esecuzione attiva da quella della revisione umana. I valori dipendono dai costi e dai ritardi che l’azienda può accettare: non esiste un valore predefinito sicuro per tutti.

Riservare il budget prima di avviare attività parallele, poi riconciliarlo al termine di ogni chiamata. Altrimenti ogni esecutore può vedere lo stesso saldo residuo e spenderlo per conto proprio. Anche le esecuzioni riprese devono gravare sul medesimo budget della pratica.

Claude Agent SDK espone controlli di spesa per le query, tra cui maxBudgetUsd in TypeScript e max_budget_usd in Python, oltre a controlli sulla profondità e sulla concorrenza dei subagenti. Verificare i requisiti della versione installata nella documentazione dei subagenti.

Il perimetro della contabilizzazione conta: il campo usage esclude l’attività dei subagenti, mentre modelUsage o model_usage la include. total_cost_usd comprende i subagenti, ma è una stima calcolata lato client. Il limite di spesa di una query copre la spesa di quella chiamata, non quella precedente ripristinata da una sessione ripresa. Mantenere un registro contabile per l’intera pratica e riconciliare le stime con i dati di consumo ufficiali. Documentazione di Claude sul monitoraggio dei costi.

Un’impostazione di budget nell’SDK non garantisce inoltre un tetto esatto alla fattura finale: il risultato documentato con limite di spesa può concludersi raggiungendo o superando la soglia. Lasciare un margine per le attività già in corso e interrompere l’assegnazione di nuovo lavoro prima di esaurire il budget aziendale.

Il costo dell’orchestrazione si misura sull’intera pratica

Il budget deve coprire il risultato aziendale completato, compresi il lavoro senza esito e la revisione. Più agenti possono accelerare ricerche indipendenti, ma anche ripetere il contesto, aggiungere chiamate di sintesi e innescare cicli di revisione. La convenienza dipende da quanto migliora il risultato accettato rispetto al costo aggiuntivo.

Il modello mensile da usare è questo:

Costo del processo = utilizzo dei modelli + strumenti a pagamento + infrastruttura dei workflow + archiviazione di stato e log + revisione umana + gestione operativa.

Il totale va poi diviso per i risultati approvati, non per le esecuzioni degli agenti. Le pratiche fallite e le bozze scartate restano nel numeratore. Confrontare questo costo con quello del processo attuale, applicando gli stessi criteri di accettazione e le stesse ipotesi sul costo del personale; senza questi dati non si può ricavare una percentuale di risparmio credibile.

Come riferimento concreto per l’infrastruttura, Cloudflare pubblica queste tariffe:

Fonti: prezzi di Workers e prezzi di Workflows. Il minimo dell’account riguarda l’infrastruttura, non il prezzo complessivo di un agente. Richieste, tempo CPU (lavoro del processore), chiamate ai modelli e altri servizi vanno comunque conteggiati. L’annuncio sulla fatturazione indica che l’addebito di passaggi e archiviazione non decorre prima del 10 agosto 2026; la formulazione pubblica non conferma l’attivazione per un singolo account.

Il nostro calcolo: dividendo la tariffa pubblicata di $0.80 per 100,000 si ottiene un costo effettivo di $0.000008 per passaggio aggiuntivo, prima degli altri addebiti. È una conversione unitaria della tariffa indicata, non una stima del carico di lavoro o una fattura misurata. Tariffa pubblicata per i passaggi.

L’attesa non deve necessariamente tenere attivo un ciclo del modello. Cloudflare dichiara che le attese delle API, le sospensioni e i periodi di inattività non consumano tempo CPU. L’archiviazione dello stato e il conteggio dei passaggi restano separati. Salvare la pratica e attendere un evento, anziché chiedere ripetutamente a un agente se chi deve approvare ha risposto. Prezzi di Workflows.

I framework per agenti AI vengono dopo il disegno del processo

Prima del framework, scegliere il confine del coordinamento. Mantenere un unico responsabile quando serve una sintesi; trasferire la responsabilità quando lo specialista successivo deve agire in autonomia; usare un grafo quando contano le transizioni consentite; aggiungere un controllo durevole del ciclo di vita quando il lavoro deve proseguire oltre una chiamata.

Il confronto tra framework per agenti AI affronta la scelta dei singoli framework. Se il dubbio è ormai tra uno stato esplicito a grafo e gruppi di agenti organizzati per ruolo, il riferimento è LangGraph vs CrewAI.

Il responsabile tecnico deve esplicitare persistenza, permessi di esecuzione e responsabilità del ripristino. Il responsabile operativo deve definire criteri di accettazione, persone autorizzate ad approvare, escalation e spesa consentita. Chi acquista deve chiedere chi gestisce questi controlli, dove risiedono i dati e come viene recuperata una pratica sospesa dopo un errore.

Una piattaforma può gestire l’infrastruttura per conto dell’azienda. Non può decidere che cosa l’azienda consideri un rimborso approvato, un’affermazione adeguatamente supportata in una proposta o un acquisto aggiuntivo accettabile.

Dove le promesse superano la sostanza

Aumentare il numero di agenti non dimostra che i risultati migliorino. Ad agenti distinti vanno assegnati fonti, strumenti o responsabilità distinti. Chiedere ad agenti intercambiabili di criticarsi a vicenda più volte può consumare budget senza aggiungere riscontri.

Anche il disegno di un grafo non dimostra che l’esecuzione sia durevole. A determinare che cosa sopravvive a un errore sono lo stato salvato, il sistema di persistenza e il comportamento alla riesecuzione. Allo stesso modo, scrivere in un prompt «chiedi prima di inviare» non fa rispettare una regola di invio: il componente che esegue l’azione deve verificare il permesso.

Infine, la pianificazione affidata al modello deve restare entro un compito delimitato. Un ricercatore può scegliere di volta in volta quale fonte pertinente esaminare. Le decisioni di esporre dati privati, approvare una spesa o inviare un messaggio al cliente devono restare soggette alle regole di accesso e approvazione dell’applicazione.

Da dove partire lunedì

Partire da un solo processo e dal minimo confine aggiuntivo che gli serve. Mantenere l’agente che già funziona. Mettere per iscritto input, risultato prodotto, strumenti, responsabile, condizione di successo e condizione di arresto; poi aggiungere la responsabilità mancante di ricerca o stesura.

Prima di abilitare scritture con effetti sui clienti, provare i casi di errore con input rappresentativi e privi di dati sensibili: interrompere l’esecuzione dopo il salvataggio di una bozza, consegnare due volte un’approvazione, rifiutare una proposta, modificare un contenuto approvato, esaurire il budget e simulare una scrittura esterna la cui risposta vada persa. Verificare che la pratica raggiunga uno stato registrato con una prossima azione chiara.

Intervenire subito se il lavoro passa tra specialisti responsabili, attende un’approvazione o richiede un ripristino affidabile. Rimandare l’aggiunta di agenti se il problema attuale è la scarsa qualità delle fonti o un criterio di accettazione poco chiaro. Un processo affidabile con un solo agente, che non incontra questi confini, può restare com’è.

Le domande di chi gestisce il processo

Serve una piattaforma di orchestrazione degli agenti AI se un agente funziona già?

Solo se servono capacità di coordinamento o operative che l’applicazione esistente non offre. Prima va identificata la responsabilità mancante: assegnazione a uno specialista, salvataggio dei progressi, approvazione differita o ripristino. È quel requisito a stabilire se aggiungere una libreria, un servizio di workflow o una piccola quantità di codice applicativo.

Si possono combinare questi schemi nello stesso processo?

Sì. Un workflow durevole può gestire la pratica, mentre un grafo controlla i percorsi di revisione e un agente coordinatore delega la ricerca. Ogni livello deve avere una responsabilità chiara; le regole sui nuovi tentativi non devono sovrapporsi per la stessa operazione.

Approvare una bozza autorizza anche un altro tentativo a pagamento?

Solo se l’approvazione include esplicitamente quella spesa. L’approvazione all’uso di un contenuto e il permesso di acquistare un altro tentativo vanno registrati separatamente. Anche una bozza modificata deve essere riesaminata prima di eseguire l’azione che ne consegue.

Che cosa deve succedere se chi deve approvare non risponde?

Far scadere la decisione in sospeso secondo una regola definita, avvisare il responsabile e mantenere sospesa o chiudere la pratica. Conservare un contesto sufficiente per una revisione successiva. Il silenzio non deve trasformarsi in approvazione automatica.

Iscriviti alla newsletter per guide pratiche alla creazione e alla gestione di workflow aziendali con l’AI.