Lo scheduler cron di Hermes Agent è la terza forma di lavoro dell'agente, dopo la chat turno per turno e i cicli /goal. Col cron, l'agente gira a orario, senza supervisione, e i risultati vanno alla piattaforma di messaggistica che vuoi — o a tutte in una volta tramite deliver=all (#21495).
Questo articolo costruisce un job specifico — un report mattutino — e lo usa per spiegare come lo scheduler funziona davvero. Lo stesso schema regge backup notturni, audit di sicurezza settimanali, promemoria di turno on-call, o qualsiasi altra cosa per cui altrimenti ti saresti messo a cablare un fragile bash + cron.
Cosa stiamo costruendo
Ogni giorno feriale alle 8 del mattino:
- 1.Leggere la posta della notte (dalle 17 di ieri in poi)
- 2.Tirare giù le notifiche di GitHub (issue, review di PR, menzioni)
- 3.Controllare l'agenda di oggi per le prime 4 ore
- 4.Riassumere le tre cose in un singolo messaggio Telegram
Se è successo qualcosa di importante, il messaggio è dettagliato. Se non è successo nulla, il messaggio è una sola frase: "Notte tranquilla. Agenda leggera fino alle 11."
Passo 1: definire il job
hermes cron add ti accompagna. La CLI ti chiede: un nome, un orario, la descrizione del job (linguaggio naturale) e i target di consegna.
$ hermes cron add
Name: daily-morning-report
Schedule (cron expression or natural language): 0 8 * * MON-FRI
Description: |
Read overnight email (since 5 PM yesterday).
Pull GitHub notifications via the github skill.
Check today's calendar via google-calendar for the first 4 hours.
Summarize all three into one Telegram message.
Be brief when nothing important happened.
Delivery: telegram
0 8 <em class="italic text-slate-200"> </em> MON-FRI è sintassi cron standard: minuto 0, ora 8, ogni giorno del mese, ogni mese, dal lunedì al venerdì. Hermes accetta sia la sintassi cron sia formulazioni più sciolte in linguaggio naturale come "every weekday at 8 AM".
Passo 2: cosa gira alle 8
Il prossimo giorno feriale alle 8, Hermes apre una sessione di agente isolata con dentro:
- •La descrizione del job come messaggio utente iniziale
- •Gli skill che l'agente decide di chiamare (
email,github,google-calendar) - •Un delivery hook che instrada la risposta finale verso Telegram
Niente contesto persistente, niente utente che digita. L'agente legge la descrizione, chiama gli skill, abbozza un messaggio, lo manda. Tipicamente 15–30 secondi e ha finito.
L'output arriva su Telegram come messaggio del tuo bot Hermes. Se il job ha impiegato più del solito o ha incontrato un errore, anche sul canale ti arriva un messaggio d'errore.
Passo 3: deliver=all — fan-out su tutte le piattaforme
Di default la consegna va a una sola piattaforma — quella che hai specificato in cron add. Se vuoi che il report atterri ovunque tu possa essere raggiunto, fai:
hermes cron edit daily-morning-report --deliver all
Adesso il messaggio va su ogni piattaforma di messaggistica collegata in una volta — il tuo Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, qualsiasi cosa tu abbia configurato. v0.14.0 ha cablato esplicitamente la consegna per-piattaforma del cron (#21495).
Quando serve: vuoi la garanzia di vedere il messaggio indipendentemente dall'app che stai usando in quel momento.
Quando è esagerato: la mattina controlli una sola piattaforma. Allora scegli quella.
Passo 4: vedere cosa c'è in coda
hermes cron list
Mostra tutto quello che è in coda, il prossimo orario di esecuzione, lo stato dell'ultimo giro. v0.14.0 ha aggiunto il lookup per nome sulle operazioni dei job (#26231), così puoi referenziarli per nome invece che per ID:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # fai partire subito, fuori orario
Cosa succede quando un job fallisce
I job cron girano nella loro sandbox session (gli stessi backend del Hermes interattivo — vedi il post sui sandbox backend). Se una chiamata di skill fallisce, l'agente riceve l'errore e o ritenta o lo riporta.
Se l'intero job va in crash (l'agente stesso esce con errore), Hermes ti notifica sulla tua piattaforma di messaggistica di default con l'errore e un link ai log. Il lavoro di durabilità della sessione di v0.13.0 fa sì che un riavvio del gateway non perda le consegne cron pendenti — la deduplica passa per claim atomico con rewind in caso di fallimento (#23401).
Qualche job vero che vale la pena
Sono pattern che la gente fa girare per davvero:
Verifica del backup notturno. Cron alle 3 di notte: lista gli snapshot di backup, controlla che quello di oggi esista e non sia vuoto, fa rumore se manca. deliver=all così se c'è un guaio ti svegli e lo vedi.
Audit di sicurezza settimanale. Cron domenica alle 22: tira giù gli advisory delle dipendenze, fa lo scan dei CVE noti nei lockfile, riassume le vulnerabilità nuove. Il supply-chain advisory checker di v0.14.0 (#24220) rende questa cosa più pulita degli script artigianali.
Handoff di turno on-call. Cron venerdì alle 17: legge le page di questa settimana, scrive un paragrafo di passaggio di consegne per chi sarà on-call la prossima. Consegna sul canale Slack condiviso.
Watchers (lo skill di v0.14.0 #21881). Fa polling su un feed RSS, un endpoint HTTP JSON, o un repo GitHub per cambiamenti ; ti notifica solo quando qualcosa è cambiato. Messo insieme al cron diventa "avvisami quando X cambia" — una delle primitive di automazione più sottovalutate che ci siano.
Dove finiscono i log
hermes cron logs daily-morning-report
Di default, gli ultimi 10 giri. Ognuno mostra: timestamp, durata, quali skill sono stati chiamati, cosa è stato consegnato, cosa è fallito se è fallito qualcosa. I log stanno in ~/.hermes/cron/logs/ e ruotano da soli.
Perché è meglio di scriversi uno shell script
Lo stesso report giornaliero lo puoi scrivere come script bash + cron + curl-verso-Telegram + magari una piccola chiamata a un LLM. In tanti l'hanno fatto.
Il motivo per cui cron-su-un-agente è interessante:
- 1.La descrizione del job è la specifica. Niente codice da mantenere. Cambiare "prime 4 ore" in "prime 6 ore" — modifichi la descrizione, niente redeploy.
- 2.Gli skill compongono. Aggiungere "controlla anche se ci sono ticket nuovi su Linear" è una frase nella descrizione. Con uno shell script è un client API nuovo.
- 3.La consegna è disaccoppiata.
deliver=allvuol dire che non scrivi 5 webhook diversi per 5 chat app diverse. Il gateway parla già tutte e 22. - 4.Gli errori sono debuggabili. Quando un job fallisce, l'agente ti dice cosa ha provato e perché ha fallito, in italiano. Gli script bash ti danno exit code 1.
Questo non rende cron-su-agente sempre la risposta giusta — per i job che devono essere deterministici al 100% e finire in 30 ms, uno shell script resta meglio. Ma per "a questa ora fai qualcosa di sensato e poi raccontamelo", cron-su-Hermes è l'attrezzo più pulito che ci sia in cassetta.