Agente AI o workflow automatico: la differenza concreta

Ho usato entrambi. Workflow automatici da anni, agenti AI da qualche mese. La differenza non è dove pensi.

Quando le persone dicono "ho automatizzato con l'AI" spesso intendono cose diverse. A volte parlano di un agente. Più spesso parlano di un workflow con un LLM nel mezzo. Non è la stessa cosa.

Il workflow segue una mappa

Un workflow automatico è una sequenza definita di passi. Punto A → punto B → punto C. Il percorso è fisso. Le condizioni sono pre-scritte da chi ha costruito il sistema.

Se arriva una email con allegato PDF, estrailo. Mandalo a GPT. Salva la risposta in un foglio. Fine.

Funziona benissimo per problemi stabili. Ho costruito decine di workflow così — per Aboca, per Loro Piana, per clienti più piccoli. Sono affidabili, prevedibili, veloci da debuggare. Quando qualcosa si rompe, sai esattamente dove guardare.

Il limite è uno solo: il workflow non sa cosa fare quando incontra qualcosa fuori dalla mappa.

L'agente decide il percorso

Un agente AI riceve un obiettivo, non una sequenza. Deve capire da solo quali passi fare per raggiungerlo.

Gli do accesso a degli strumenti — una ricerca web, un database, una API — e gli dico: trova le ultime tre news rilevanti su questo cliente e scrivimi un briefing. Non gli dico come farlo. Lui decide se cercare prima su Google, se consultare il CRM, se rileggere la conversazione precedente.

Se il primo tentativo non produce nulla di utile, può riprovare con una strategia diversa. Questo è il punto chiave: l'agente valuta i risultati intermedi e adatta il comportamento.

In produzione uso Agno per questo. Un agente con quattro tool connessi gestisce task che prima richiedevano un workflow da venti step — e lo fa con meno codice da manutenere.

La domanda giusta da farti

Non è "devo usare un agente o un workflow?". È: il problema che sto risolvendo ha sempre lo stesso percorso, o il percorso cambia a seconda del contesto?

Se il percorso è fisso, usa un workflow. È più veloce, più economico, più controllabile. n8n, Make, Python con una serie di chiamate API — tutto funziona.

Se il percorso cambia — perché i dati di input variano, perché le condizioni non sono tutte prevedibili, perché vuoi che il sistema ragioni su cosa fare — allora hai bisogno di un agente.

Un esempio concreto: ho un bot Telegram che risponde a domande su un progetto locale chiamato Manfria Attiva. Le domande degli utenti non sono mai le stesse. Non posso pre-scrivere tutti i percorsi possibili. L'agente legge la domanda, decide se cercare nella knowledge base o rispondere direttamente, e costruisce la risposta. Un workflow classico non reggerebbe la variabilità.

Cosa si rompe in produzione

Gli agenti hanno un costo reale che i workflow non hanno: sono meno prevedibili. Possono prendere strade inattese. Possono usare più token del previsto. Possono bloccarsi in se non hai definito bene i limiti.

Per questo in produzione non lancio mai un agente senza tre cose: un limite massimo di iterazioni, un sistema di logging su ogni step, e un fallback manuale per i casi critici.

I workflow invece falliscono in modo silenzioso — un dato mancante, una API che non risponde, un formato cambiato. Devi monitorarli con altrettanta attenzione, ma il debug è lineare.

Nessuno dei due è "meglio" in assoluto. Dipende dal problema.

L'architettura che uso più spesso

Nella pratica, li combino. Un workflow gestisce il trigger e la struttura della pipeline. Un agente gestisce il pezzo ambiguo nel mezzo — quello dove la logica non è codificabile a priori.

Trigger (webhook / cron)
  → Workflow: normalizza input, recupera contesto
  → Agente: ragiona, decide, agisce
  → Workflow: salva output, notifica, logga

Questo pattern riduce la superficie di imprevedibilità dell'agente. Gli do un contesto già pulito. Lui fa solo il lavoro per cui serve davvero.

La domanda che mi faccio adesso — e che non ho ancora una risposta definitiva — è quanto si può spingere la complessità degli agenti prima che il sistema diventi ingestibile. È il territorio che sto esplorando.