Workflow Deterministici vs Agenti AI: quando servono davvero e quando sono un errore

Negli ultimi mesi l'hype attorno agli Agenti AI ha portato molte aziende a commettere un errore sistematico: forzare l'uso di un agente autonomo anche laddove una semplice sequenza deterministica di chiamate risolverebbe il problema a un decimo del costo, con latenza dimezzata e zero rischi di deviazione.

Nel mondo reale dei progetti enterprise, l'autonomia non è gratis: conferire a un Large Language Model il potere di decidere se, quando e in quale ordine chiamare degli strumenti comporta costi computazionali variabili, rischio di loop infiniti e potenziale imprevedibilità delle risposte.

Capire quando fermarsi a un workflow a passaggi fissi e quando invece l'architettura agentica è l'unica via possibile è la prima decisione strategica di qualsiasi progetto di automazione dei processi aziendali.

1. L'illusione dell'Agente a tutti i costi

Dietro le quinte, un Large Language Model di per sé è una funzione statica: riceve un testo in input e predice la sequenza di token statisticamente più probabile. Non compie azioni nel mondo esterno a meno che non gli vengano forniti degli strumenti (Tool).

Quando parliamo di intelligenza artificiale applicata ai processi, possiamo strutturare l'esecuzione in due modi radicalmente diversi:

• Workflow Deterministico (LLM-based Workflow): Il codice dello sviluppatore decide a priori l'esatta sequenza di passaggi. L'LLM interviene all'interno di step prestabiliti solo per compiti specifici di estrazione, sintesi o trasformazione.
• Agente Autonomo (Agentic Flow): L'LLM riceve un obiettivo generale e una cassetta degli attrezzi (API, database, motori di ricerca). È il modello stesso a decidere, iterazione dopo iterazione, quali tool invocare e quando considerare concluso il compito.

2. La Regola d'Oro: sequenza fissa vs branching dinamico

La discriminante fondamentale tra le due architetture si riassume in una domanda: «Conosci a priori l'esatta catena di operazioni necessarie per risolvere il task?»

3. Function Calling: chiamate parallele, sequenziali e gestione errori

Quando invece l'autonomia è indispensabile (ad esempio in un chatbot su documenti aziendali dove le domande degli utenti sono imprevedibili), il cuore tecnico dell'agente risiede nel meccanismo di Function Calling:

A. Dipendenza vs Indipendenza dei Tool

I modelli moderni (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) sono in grado di comprendere se più azioni richieste possono essere eseguite in parallelo o richiedono una sequenza rigorosa:

• Chiamate Parallele: Se l'utente chiede «Che tempo fa a Milano e che tempo fa a Londra?», il modello restituisce in un unico output due `tool_calls` simultanee. L'applicazione esegue le due query in parallelo, dimezzando i tempi di attesa.
• Chiamate Sequenziali Dipendenti: Se l'utente chiede «Trova il ristorante all'aperto più vicino solo se a Boston non piove», il modello chiama prima il tool meteo, riceve il responso, elabora il contesto e solo al giro successivo invoca il tool di ricerca ristoranti filtrando per locali all'aperto o al chiuso.

B. Il pattern degli errori parlanti (Self-Healing)

Uno degli aspetti più sottovalutati nello sviluppo di agenti riguarda la gestione degli errori dei Tool. Quando una funzione custom va in errore (ad esempio una query SQL fallita per una colonna inesistente), restituire un generico "500 Internal Error" rende l'agente cieco.

Al contrario, se la funzione restituisce il messaggio d'errore dettagliato del database (es. "Column 'total_eur' does not exist, available columns: ['amount', 'currency']"), l'agente all'iterazione successiva legge l'errore, corregge la query SQL in autonomia e risolve il task senza interruzioni.

4. Sistemi Multi-Agente e Human-in-the-Loop

Quando un task richiede troppi tool diversi (es. 15-20 strumenti), concentrare tutte le istruzioni in un singolo system prompt monolitico provoca allucinazioni e confusione.

L'approccio corretto consiste nello scomporre l'architettura in un sistema Multi-Agente con gerarchia specializzata:

Come approfondito nella nostra guida su come lavorano gli agenti AI in azienda, il principio Human-in-the-Loop garantisce che le decisioni irreversibili restino sempre sotto la supervisione umana.

5. Evaluation-Driven Development (EDD) e produzione

Scrivere il codice di un agente AI in Python richiede poche righe. La vera sfida che separa un prototipo da un'applicazione pronta per la produzione aziendale è la valutazione sistematica delle prestazioni.

In consulenza applichiamo la metodologia Evaluation-Driven Development (EDD):

• Costruzione del Dataset di Valutazione: Prima di ottimizzare i prompt, si costruisce a quattro mani con gli esperti di reparto dell'azienda un dataset di almeno 50-100 casi limite reali con relativo output atteso.
• LLM-as-a-Judge: Si implementano modelli supervisori per validare automaticamente la pertinenza, la conformità alle policy e l'assenza di allucinazioni su ogni versione rilasciata.
• Prompt Debugging a Posteriori: Far registrare all'agente le motivazioni del proprio ragionamento dopo aver generato la risposta, così da individuare con precisione eventuali ambiguità nelle istruzioni senza alterare l'output dell'utente.

6. Matrice decisionale per la tua azienda

Per orientare le scelte tecniche del tuo team IT o dei tuoi fornitori, utilizza questa griglia decisionale: