Come Rilevare un'Esecuzione Pianificata di un Agente AI Che Ha Fallito in Silenzio

Un agente AI pianificato che non parte mai appare, dall'esterno, esattamente come uno che ha eseguito senza problemi. Nessuno riceve un'email di errore. Nulla compare nel vostro tracker delle eccezioni. L'unico segnale è un'assenza — e le assenze sono facili da ignorare, finché non è un cliente, un revisore o una settimana di lead persi a farvelo notare per primi. La soluzione non è gestire meglio gli errori all'interno dell'agente; è un monitor che vive al di fuori dell'agente e si aspetta di ricevere sue notizie.

Perché il fallimento silenzioso è la modalità di errore predefinita degli agenti pianificati

La maggior parte dello sforzo ingegneristico va nella gestione elegante degli input errati: retry, fallback, log degli errori strutturati. È utile, ma presuppone che il processo dell'agente sia effettivamente partito. In pratica, le esecuzioni che non avvengono mai falliscono solitamente per ragioni che non toccano affatto il codice dell'applicazione:

• Una voce cron o la configurazione dello scheduler viene modificata (o eliminata) durante un deploy e nessuno se ne accorge.
• L'host, il container o la funzione serverless su cui gira è giù, in throttling o a corto di quota.
• Una chiave API o un token OAuth scade e il processo termina prima ancora che il vostro logging si inizializzi.
• Una coda o un orchestratore (Airflow, Temporal, un Lambda attivato via cron) perde silenziosamente il trigger durante un riavvio.

Nessuno di questi casi produce un'eccezione nel codice dell'agente, perché quel codice non arriva mai a girare. Qualsiasi alerting configurato all'interno dell'agente è cieco esattamente alla modalità di errore che qui conta di più. È la stessa classe di problemi trattata nella nostra checklist di sicurezza per agenti AI: il rischio non sta nella logica che avete testato, ma nelle condizioni al contorno per cui nessuno ha scritto un test.

Il pattern: un dead man's switch, non un alert sugli errori

La soluzione standard è un heartbeat monitor, talvolta chiamato dead man's switch: un servizio separato, semplice ed estremamente affidabile che si aspetta di ricevere un segnale ("ho girato, sono vivo") secondo una certa pianificazione, e vi avvisa quando quel segnale non arriva entro una finestra di tolleranza. L'agente non deve riportare il successo o il fallimento nei dettagli; deve solo fare il check-in.

Un'implementazione minimale si presenta così:

```

all'avvio del job pianificato

curl -fsS https://your-monitor.example/ping/start-token

... l'agente svolge il suo lavoro ...

dopo il completamento del job (successo o errore gestito)

curl -fsS https://your-monitor.example/ping/finish-token ```

Se finish-token non arriva entro, diciamo, 15 minuti dalla pianificazione prevista, il monitor avvisa qualcuno. Non importa se il job è crashato, se il container non è mai partito o se l'intero account è stato sospeso: l'assenza del ping è il segnale. È lo stesso principio alla base della documentazione sul monitoraggio cron di Healthchecks.io, una delle implementazioni più diffuse di questo pattern, e funziona sia che il vostro "agente" sia un singolo cron job sia una flotta di worker guidati da LLM.

Cosa monitorare concretamente

Non limitatevi a monitorare "il processo è uscito con codice 0." Per un agente AI in particolare, fate il check-in sulle fasi che contano per il risultato di business, non solo sul runtime:

• È partito nei tempi previsti (intercetta i fallimenti di scheduler e infrastruttura)
• Ha prodotto un output della forma attesa (intercetta un modello che restituisce silenziosamente risposte vuote o malformate)
• L'azione downstream è effettivamente avvenuta (email inviata, record scritto, ticket creato), non solo "la chiamata all'LLM ha restituito una risposta"

Il terzo punto conta più di quanto sembri. Un agente può completare il suo ciclo, registrare il successo e aver comunque deluso chi lo aspettava — se la scrittura finale nel vostro CRM o database è un no-op silenzioso. Fate l'heartbeat sull'esito, non sul processo.

Un esempio concreto: monitoraggio di un agente di outreach notturno

Gestiamo un agente di outreach self-hosted che analizza il sito di ogni prospect e redige un'email personalizzata per azienda, con cadenza notturna. All'inizio avevamo solo il logging a livello applicativo: se lo scraper o la chiamata all'LLM generava un errore, lo vedevamo. Quello che non abbiamo intercettato — per una settimana piuttosto scomoda — è stato un errore di configurazione dello scheduler dopo una migrazione del server, che faceva sì che il job semplicemente non partisse mai. Nessun errore, nessun alert, solo una settimana di lead che tranquillamente non hanno mai ricevuto email. Aggiungere un heartbeat che si aspettasse un ping giornaliero e ci avvisasse in caso di mancato arrivo avrebbe rilevato il problema in un giorno anziché in una settimana. È una piccola aggiunta all'agente in sé, ma è la differenza tra "il sistema è degradato" e "il sistema ha smesso di esistere e nessuno se n'è accorto."

Implicazioni per la scelta tra build e buy

Se state valutando un'agenzia o un vendor per realizzare o gestire un agente AI pianificato, chiedete direttamente: come rileva un'esecuzione che non è mai avvenuta? Un vendor che risponde indicando un monitor specifico, un grace period e un percorso di escalation ha realmente ragionato sull'affidabilità operativa. Un vendor che dice "lo vedremmo dai log" sta descrivendo un sistema che richiede che qualcuno vada attivamente a cercare — che è esattamente la modalità di errore che un dead man's switch è progettato per eliminare. Questo si collega direttamente ai costi di manutenzione degli agenti AI: l'infrastruttura di monitoraggio è economica da aggiungere in anticipo e costosa da introdurre a posteriori, dopo che la prima esecuzione mancata vi è già costata qualcosa di concreto. Vale anche la pena chiarire chi viene avvisato e quando, il che si sovrappone alla definizione dei percorsi di escalation dell'agente in senso più ampio.

Checklist pratica

• Aggiungete un ping di avvio e di completamento a ogni agente pianificato critico per il business, non solo l'alerting sugli errori
• Impostate il grace period in base alla gravità reale di un'esecuzione mancata: minuti per gli agenti critici per il fatturato, ore per i job di reportistica
• Monitorate l'esito downstream (record scritto, email inviata), non solo il codice di uscita del processo
• Assicuratevi che l'alert raggiunga una persona, non solo una dashboard che nessuno controlla
• Verificate occasionalmente il percorso dell'alert stesso: un alert che nessuno nota equivale a nessun alert

Gli agenti pianificati falliscono in silenzio molto più spesso di quanto falliscano in modo vistoso. La soluzione non è una gestione degli errori più sofisticata all'interno del codice; è un controllo separato, semplice e affidabile: qualcosa, al di fuori dell'agente, che stia in ascolto della sua assenza.

Se state costruendo o gestendo sistemi agentici e volete uno sguardo esterno su come vengono monitorati, parliamone.