El programador cron de Hermes Agent es la tercera forma grande de trabajo del agente, después del chat turno a turno y los bucles /goal. Con cron, el agente corre sin supervisión, en un horario, con los resultados entregados a la plataforma de mensajería que prefieras — o a todas a la vez vía deliver=all (#21495).
Este recorrido construye una tarea concreta — un informe de la mañana — y la usa para explicar cómo funciona el scheduler de verdad. El mismo patrón maneja copias nocturnas, auditorías semanales de seguridad, avisos de rotación de guardia, o lo que ahora estés cableando con un bash + cron quebradizo.
Lo que vamos a construir
Cada día laborable a las 8 AM:
- 1.Leer el correo de la noche (desde las 17:00 de ayer)
- 2.Sacar las notificaciones de GitHub (issues, reviews de PR, menciones)
- 3.Mirar la agenda de hoy para las primeras 4 horas
- 4.Resumir las tres cosas en un único mensaje de Telegram
Si pasó algo importante, el mensaje es detallado. Si no pasó nada, el mensaje es una frase: "Noche tranquila. Agenda ligera hasta las 11."
Paso 1: definir la tarea
hermes cron add te lleva por ello. La CLI te pide: un nombre, un horario, la descripción de la tarea (lenguaje natural) y los destinos de entrega.
$ 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 es sintaxis cron estándar: minuto 0, hora 8, cualquier día del mes, cualquier mes, de lunes a viernes. Hermes acepta tanto sintaxis cron como expresiones en lenguaje natural más sueltas, tipo "every weekday at 8 AM".
Paso 2: qué corre a las 8 AM
A las 8 AM del próximo día laborable, Hermes levanta una sesión de agente aislada con:
- •La descripción de la tarea como mensaje inicial de usuario
- •Los skills que el agente decida llamar (
email,github,google-calendar) - •Un delivery hook que canaliza la respuesta final a Telegram
Sin contexto persistente, sin que tú teclees. El agente lee la descripción, llama a los skills, redacta un mensaje, lo envía. Normalmente en 15–30 segundos.
La salida aparece en Telegram como un mensaje del bot de Hermes. Si la tarea tardó más de la cuenta o se topó con un error, también te llega un mensaje de error en el mismo canal.
Paso 3: deliver=all — reparto a todas las plataformas
Por defecto, la entrega va a una plataforma — la que pusiste en cron add. Si quieres que el informe llegue a cualquier sitio donde puedas verte, configura:
hermes cron edit daily-morning-report --deliver all
Ahora el mensaje sale a la vez a cada plataforma de mensajería conectada — tu Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, lo que tengas configurado. v0.14.0 cableó la entrega por plataforma para cron de forma explícita (#21495).
Cuándo es útil: quieres garantía de ver el mensaje sin importar en qué app estés.
Cuándo es exagerado: por la mañana solo miras una plataforma. Quédate con esa.
Paso 4: ver qué hay programado
hermes cron list
Muestra todo lo programado, próxima ejecución, estado de la última. v0.14.0 añadió búsqueda por nombre para operaciones sobre tareas (#26231), así que puedes referenciarlas por nombre en lugar de por ID:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # dispara ya mismo, fuera de horario
Qué pasa cuando una tarea falla
Las tareas cron corren en su propia sesión de sandbox (mismos backends que el Hermes interactivo — mira el artículo de los backends de sandbox). Si una llamada a skill falla, el agente recibe el error y o reintenta o lo reporta.
Si toda la tarea se cae (el propio agente errores fuera), Hermes te avisa en tu plataforma de mensajería por defecto con el error y un enlace a los logs. El trabajo de durabilidad de sesión de v0.13.0 significa que un reinicio de gateway no pierde entregas de cron pendientes — el deduplicado va por claim atómico con rewind en caso de fallo (#23401).
Algunas tareas reales útiles
Estos son patrones que la gente corre de verdad:
Verificación nocturna de copias. Cron a las 3 AM: lista snapshots de backup, comprueba que el de hoy existe y no está vacío, falla con ruido si falta. deliver=all para que te despiertes con el fallo si lo hay.
Auditoría semanal de seguridad. Cron domingo a las 22:00: tira advisories de dependencias, escanea CVEs conocidos en tus lockfiles, resume las vulnerabilidades nuevas. El verificador de avisos de cadena de suministro de v0.14.0 (#24220) deja esto más limpio que con scripts caseros.
Traspaso de guardia. Cron viernes a las 17:00: lee las paginadas de esta semana, redacta un párrafo de traspaso para la guardia de la semana que viene. Entrega al canal compartido de Slack.
Watchers (el skill de v0.14.0, #21881). Hace polling a un feed RSS, un endpoint HTTP JSON o un repo de GitHub buscando cambios; solo te avisa cuando cambió algo. Combinado con cron se convierte en "avísame cuando X cambie", una de las primitivas de automatización más infrautilizadas que hay.
Adónde van los logs
hermes cron logs daily-morning-report
Por defecto, las últimas 10 ejecuciones. Cada una muestra: timestamp, duración, qué skills se llamaron, qué se entregó, qué falló si falló algo. Los logs viven bajo ~/.hermes/cron/logs/ y rotan automáticamente.
Por qué esto le gana a un script de shell
El mismo informe diario lo puedes escribir como bash + cron + curl a Telegram + quizá una llamadita LLM. Mucha gente lo ha hecho.
La razón por la que cron sobre un agente resulta interesante:
- 1.La descripción de la tarea es la spec. Sin código que mantener. Cambias "primeras 4 horas" por "primeras 6 horas" — editas la descripción, sin redeploy.
- 2.Los skills componen. Añadir "también revisa Linear por tickets nuevos" es una frase en la descripción. Con un script de shell es un nuevo cliente de API.
- 3.La entrega está desacoplada.
deliver=allsignifica que no escribes 5 webhooks distintos para 5 apps distintas. La gateway ya habla las 22. - 4.Los errores son depurables. Cuando una tarea falla, el agente te cuenta qué intentó y por qué falló, en inglés (o en castellano). Los scripts de bash te dan exit code 1.
Eso no convierte a cron-sobre-agente en la respuesta correcta siempre — para tareas que tienen que ser 100% deterministas y acabar en 30 ms, el script de shell sigue siendo mejor. Pero para "haz algo con cabeza a esta hora y cuéntamelo", cron-sobre-Hermes es la herramienta más limpia de la caja.