Negli ultimi mesi quasi ogni automazione viene proposta come agente: un modello che decide, chiama tool, riprova, riassume. A volte è la scelta giusta. Spesso però il problema non ha bisogno di decidere nulla: ha bisogno di girare ogni notte, fare sempre la stessa cosa e fallire in modo rumoroso quando qualcosa va storto. Lì un cron e uno script chiaro vincono quasi sempre.
Non è una posizione contro gli agenti. È una domanda di progetto da farsi prima: in questo flusso, dov'è l'incertezza? Se la risposta è “da nessuna parte”, il loop è solo costo, latenza e una superficie di errore in più.
Caso 1: il lavoro è deterministico e ripetuto
Export notturno del database, sincronizzazione di un listino da un fornitore, rigenerazione di una sitemap, pulizia dei file temporanei. Input noti, output noti, passaggi sempre uguali. Un agente qui aggiunge una cosa sola: la possibilità che oggi scelga di fare qualcosa di leggermente diverso da ieri.
Uno script con un cron (o un job schedulato sulla piattaforma che usi già) è leggibile in due minuti, si testa con un input finto e produce lo stesso risultato ogni volta. Se un domani serve un passaggio “intelligente”, ad esempio classificare le righe anomale, puoi chiamare un modello dentro lo script per quel solo punto, senza consegnargli il controllo dell'intero flusso.
Caso 2: l'errore deve essere visibile, non “gestito”
Un agente ben costruito tende a recuperare: se un'API risponde male, riprova, cambia strategia, magari trova una strada alternativa. È utile quando esplori; è pericoloso quando un fallimento dovrebbe fermare tutto. Un backup che non riesce a scrivere su storage non deve “arrangiarsi”: deve uscire con codice diverso da zero e mandarti un avviso.
Con uno script la regola è semplice: set -e, log su file o su un servizio di monitoraggio, exit code controllato dallo scheduler, notifica in caso di errore. Sai esattamente cosa è successo e a che riga. Con un loop agentico devi ricostruirlo leggendo un transcript, e non sempre il transcript dice la verità sul perché.
Caso 3: il budget conta più della flessibilità
Un job che gira ogni cinque minuti, 288 volte al giorno, con un agente dentro significa centinaia di chiamate al modello anche quando non c'è nulla da fare. La maggior parte delle esecuzioni di un controllo periodico finisce con “niente di nuovo”. Uno script lo scopre con una query o una richiesta HTTP, a costo quasi nullo.
Il pattern che funziona meglio è a due livelli: lo script fa il filtro economico e deterministico, e solo quando trova qualcosa di davvero ambiguo passa la palla al modello. Così paghi l'intelligenza solo quando serve, e il caso comune resta veloce e prevedibile.
Come capire da che parte stai
Tre domande bastano quasi sempre. Il flusso ha passaggi che cambiano in base a contenuti non strutturati, come testo libero, email o documenti? Il risultato accettabile è uno spettro e non un sì/no? Un errore di giudizio è recuperabile senza danni? Se rispondi sì a tutte e tre, un agente ha senso. Se rispondi no anche a una sola, parti da uno script.
È lo stesso principio che vale per i tool che dai a un agente: confini stretti, input e output espliciti, effetti collaterali chiari. Uno script schedulato è, in fondo, il tool più piccolo e più onesto che puoi scrivere. Molte volte è anche tutto quello che serve.
Se invece l'agente serve davvero, il lavoro si sposta su come progetti loop e grafo: l'ho messo in ordine in Dalla prompt alla graph engineering. E se quel loop deve girare in locale, parti dalla Guida AI locale.
