Molti agenti AI dovevano essere workflow
Un agente decide da solo il passo successivo in un loop; un workflow segue un percorso fisso e chiama il modello solo dove l'input è ambiguo. Perché di solito il workflow è più economico, più testabile e più facile da dimostrare — e quando l'agente serve davvero.
La parola "agente" è diventata il modo predefinito per descrivere qualsiasi cosa usi un modello linguistico per lavorare. Non dovrebbe esserlo. Un agente e un workflow sono due architetture diverse, con modi di fallire diversi, e gran parte di ciò che viene venduto come agente sarebbe più affidabile, più economico e più facile da difendere come workflow. Non è una distinzione accademica: decide come il sistema fallisce, quanto costa tenerlo in piedi e se qualcuno riesce a testarlo prima che tocchi la produzione.
Due architetture, un solo modello
Un agente decide da solo il passo successivo, in un loop: legge un obiettivo, sceglie un'azione, osserva il risultato e sceglie di nuovo, finché non ritiene di aver finito. Un workflow segue un percorso fisso che hai scritto nel codice e chiama il modello solo nei punti in cui l'input è davvero ambiguo. Usano lo stesso LLM. La differenza è chi possiede il controllo di flusso. Nell'agente è il modello. Nel workflow sei tu — e al modello lasci l'unico compito in cui è bravo davvero: trasformare un input disordinato in una decisione strutturata, in un singolo passo.
Il costo vive nel loop
Ogni giro del loop di un agente è un'altra chiamata al modello, un'altra occasione per uscire dal percorso e un altro output che non puoi coprire con un test perché non è deterministico per costruzione. Aggiungi i tool e il raggio d'azione cresce: un passo sbagliato non produce più solo una frase sbagliata, scrive su un database o chiama un'API. Il debug diventa archeologia — stai ricostruendo una catena di decisioni del modello che non si riprodurrà mai due volte allo stesso modo.
Il workflow ribalta la situazione. Il percorso è codice che leggi, versioni e copri con i test. L'unica chiamata al modello, in mezzo, è isolata e loggata. Quando qualcosa va storto sai esattamente quale passo ha prodotto l'output sbagliato, perché ce n'è uno solo che poteva.
Per una software house .NET la scelta è prima economica
Per chi lavora su commessa questo cambia il conto, non solo l'architettura. Un agente lo devi osservare, contenere e rifare ogni volta che cambia il modello o il suo comportamento: è un costo ricorrente che il cliente non vede nel preventivo ma paga nel canone. Un workflow lo scrivi, lo testi e lo lasci girare. Per le PMI che integrano l'AI in un gestionale esistente, questa è spesso la differenza fra un progetto che si chiude e uno che resta in manutenzione perpetua. E c'è un vincolo che spinge nella stessa direzione: l'AI Act, per i sistemi ad alto rischio, richiede la registrazione automatica degli eventi. Un percorso deterministico e loggato è molto più facile da dimostrare di un loop che si autodirige.
Niente di tutto questo vuol dire che l'agente non sia mai lo strumento giusto. Serve quando il percorso è davvero dinamico — quando non puoi elencare i passi in anticipo perché l'azione successiva dipende da cosa ha scoperto la precedente, e lo spazio delle azioni è aperto. La prova è semplice: se sai disegnare il flusso come una sequenza di passi fissi su una lavagna, non ti serve un agente; ti servono quei passi nel codice con il modello su uno solo. La maggior parte dei processi aziendali supera questa prova. Classifica questo documento, estrai quei campi, scrivi quella risposta, instrada questa pratica: una sequenza nota con uno o due punti morbidi, non un problema aperto.
Quale dei vostri "agenti" è in realtà un workflow con un buon nome?