Cos'è un workflow automatizzato, e perché quasi sempre batte un agente di intelligenza artificiale
Un workflow automatizzato è una sequenza di passaggi il cui ordine è deciso in anticipo da chi lo scrive, e non dal programma che lo esegue. La definizione sta in una riga, e contiene già la cosa che conta davvero: in un workflow automatizzato l'intelligenza sta nel disegno, non nell'esecuzione.
Lo metto in chiaro subito perché quasi tutto quello che oggi viene venduto come agente, guardato da vicino, è un workflow automatizzato con una chiamata a un modello in mezzo. Non è una brutta notizia. È la migliore notizia possibile, perché un workflow costa meno, si ripara, e quando si rompe si capisce in quale punto.
Cos'è un workflow automatizzato e cosa lo separa da un agente
Un workflow automatizzato esegue passaggi che qualcuno ha numerato prima di premere avvio, mentre un agente sceglie il passo successivo mentre gira, guardando com'è andato quello precedente. Il confine non passa dalla presenza dell'intelligenza artificiale, che può esserci in entrambi i casi: passa da chi tiene in mano l'ordine delle operazioni.
Anthropic mette la stessa distinzione per iscritto nell'articolo tecnico Building effective agents, pubblicato il 19 dicembre 2024. I workflow sono "sistemi in cui modelli e strumenti sono orchestrati attraverso percorsi di codice predefiniti", gli agenti sono "sistemi in cui i modelli dirigono dinamicamente i propri processi e l'uso degli strumenti, mantenendo il controllo su come portano a termine i compiti".
| Workflow automatizzato | Agente | |
|---|---|---|
| Chi decide l'ordine dei passaggi | chi lo ha scritto, prima | il modello, mentre gira |
| Quanti passaggi fa | sempre gli stessi | non si sa in anticipo |
| Quando un passaggio fallisce | si ferma nel punto previsto | prova un'altra strada |
| Come si trova un errore | si rilegge il passaggio numero N | si rilegge tutto il ragionamento |
| Quanto costa una esecuzione | prevedibile | dipende da quanti giri fa |
| Cosa serve per fidarsi | leggere il codice | fissare limiti e permessi |
Le cinque forme che un workflow automatizzato prende
Nello stesso articolo Anthropic elenca cinque schemi ricorrenti, e conoscerli evita di reinventarli male. Il prompt chaining spezza un compito in chiamate in fila, dove l'uscita di una diventa l'ingresso della successiva. Il routing smista la richiesta verso il ramo giusto in base a una classificazione fatta all'inizio. La parallelizzazione manda avanti più rami insieme e ricompone i risultati alla fine.
Gli ultimi due schemi somigliano di più a un agente e restano workflow. Nell'orchestrator-workers un passaggio centrale distribuisce sotto-compiti e raccoglie le risposte, ma l'elenco dei sotto-compiti possibili lo ha scritto una persona. Nell'evaluator-optimizer un passaggio produce e un secondo passaggio giudica, e il ciclo si ripete finché il giudizio passa oppure finché scatta il limite di tentativi, che è un numero fissato nel codice.
Come è fatto un workflow automatizzato che gira ogni giorno davvero
Il workflow automatizzato che conosco meglio è quello che porta i contenuti su questo sito, e la sua anatomia è documentata in automazione-blog/README.md dentro il repository. La routine parte a orario fisso, chiede la trascrizione a un endpoint HTTP, scrive una bozza di articolo con published: false, apre una Pull Request e marca la trascrizione come trattata. Cinque passaggi, sempre nello stesso ordine, sempre gli stessi cinque.
Una decisione dentro quel disegno vale più delle altre, e non ha niente a che fare con i modelli. La routine non entra mai nella VPS via SSH: chiama un solo endpoint protetto da token, e la VPS espone quella finestrella e nient'altro. È scritto così nel README perché è stata una scelta, non una scorciatoia. Un workflow che gira da solo di notte ha esattamente i permessi che gli ho dato, quindi meno gliene do e meno danni può fare quando sbaglia, che è lo stesso principio per cui vale la pena decidere in anticipo chi controlla gli agenti AI in azienda.
L'unico passaggio che non è deterministico
Dei cinque passaggi della routine uno solo non dà lo stesso risultato due volte, ed è la scrittura dell'articolo. Tutto il resto è codice che fa sempre la stessa cosa: una richiesta HTTP, la creazione di un file, l'apertura di una Pull Request, una riga marcata come trattata.
Quel passaggio non deterministico va circondato da vincoli scritti, altrimenti il workflow produce ogni giorno una cosa diversa e nessuno sa perché. Nel repository i vincoli sono tre file dentro .claude/skills/articolo/, che fissano struttura, voce e controlli finali una volta per tutte. È la differenza fra mettere un modello dentro un workflow automatizzato e sperare che vada bene: il modello resta imprevedibile, l'intervallo dentro cui può muoversi no.
Il passaggio che ho lasciato fallire di proposito
In package.json di questo sito lo script postbuild è scritto così: tsx scripts/indexnow.ts --solo-in-produzione || true. Quel || true in coda è la parte interessante, perché dice al sistema di considerare riuscito il passaggio anche quando fallisce.
La ragione è una gerarchia decisa prima: la notifica ai motori di ricerca è utile, il sito online è indispensabile. Se il servizio di notifica non risponde, non voglio che la pubblicazione si blocchi. In un workflow automatizzato questa distinzione fra passaggi bloccanti e passaggi sacrificabili va presa una volta per ognuno, altrimenti la prende il caso. Lo stesso ragionamento vale quando si lascia lavorare un agente di coding da solo, e l'ho messo per esteso in far girare Claude Code in automatico.
Quando basta un workflow automatizzato e quando serve l'AI che decide
Un workflow automatizzato basta ogni volta che riesci a numerare i passaggi su un foglio prima di scrivere una riga di codice. Il test è meccanico e si fa in cinque minuti, e il suo esito vale più di qualsiasi confronto fra piattaforme, perché sposta la spesa di un ordine di grandezza.
Tre criteri concreti, in ordine di quanto pesano.
- Scrivi i passaggi numerati. Se arrivi in fondo senza usare la parola "dipende", hai un workflow e ti conviene costruirlo come tale.
- Conta i punti in cui il passo successivo cambia in base a un testo libero che nessuno ha classificato prima. Zero punti vuol dire che il modello non serve neanche dentro il workflow.
- Fissa un tetto di esecuzioni al giorno prima di accendere qualsiasi cosa. Un workflow lo rispetta per costruzione, un agente lo rispetta solo se glielo imponi, ed è il motivo per cui quanto costa un agente AI in azienda non si sa mai in anticipo.
Dove far girare un workflow automatizzato, e cosa resta da decidere
Quando i tre criteri dicono workflow, la domanda diventa dove farlo girare, e il confronto fra i due modi opposti di contare il consumo sta in n8n o Make, quale scegliere. Quando invece dicono agente, cambia il mestiere: il lavoro si sposta sul disegno degli strumenti e dei permessi, che è la parte che affrontiamo nei progetti di automazione dei processi con l'AI.
La distinzione fra un flusso che esegue e un sistema che decide è la stessa che separa un chatbot da un agente, e l'ho già spaccata in due nel pezzo sulla differenza tra chatbot e agente di intelligenza artificiale. Qui il punto è un altro: la maggior parte dei problemi aziendali che sembrano meritare un agente si risolvono con dodici passaggi numerati e una sola chiamata a un modello nel mezzo. Scoprirlo prima di firmare conviene a tutti, anche a chi quei sistemi li costruisce per lavoro.
Domande frequenti
Un workflow automatizzato ha bisogno dell'AI per funzionare?
No, e confonderli è l'errore che fa spendere di più. Un workflow automatizzato è fatto di passaggi in sequenza, e quei passaggi possono essere chiamate a un database, a un'API o a un comando di sistema, senza nessun modello coinvolto. L'AI entra dentro un workflow come uno dei passaggi, di solito quello che deve leggere testo libero o produrne.
Che differenza c'è fra un workflow automatizzato e una macro?
Una macro registra i gesti fatti su una singola applicazione e li ripete dentro quella stessa applicazione. Un workflow automatizzato attraversa sistemi diversi, riceve un esito da ognuno e decide se andare avanti o fermarsi. La macro si rompe quando cambia la posizione di un pulsante, il workflow si rompe quando cambia un contratto fra due sistemi, e il secondo tipo di rottura è molto più facile da leggere in un registro.
Chi si accorge se un workflow automatizzato smette di girare di notte?
Nessuno, a meno che non sia stato deciso in anticipo chi riceve il messaggio di errore. È il pezzo che manca quasi sempre nelle automazioni nate in fretta, perché un workflow che fallisce in silenzio sembra identico a un workflow che non aveva niente da fare. Il rimedio costa poco: un avviso quando un passaggio fallisce e un avviso anche quando l'esecuzione non parte affatto.
Un workflow automatizzato si può trasformare in un agente più avanti?
Sì, ed è l'ordine giusto in cui fare le cose. Costruire prima il workflow obbliga a definire gli strumenti, i permessi e i limiti, che sono esattamente i pezzi che servono a un agente per non fare danni. Passare a un agente vuol dire togliere l'ordine fisso dei passaggi e lasciare che sia il modello a sceglierlo, tenendo tutto il resto.
Quanto conta la velocità di un workflow automatizzato?
Molto meno di quanto sembra quando si disegna. Un workflow che gira una volta al giorno può metterci dieci minuti senza che nessuno se ne accorga, mentre uno che risponde a una persona che aspetta ha un budget di secondi. Il numero da fissare prima di scrivere il codice non è quanto ci mette, è entro quando il risultato deve essere pronto per essere ancora utile.