O scheduler cron do Hermes Agent é a terceira grande forma do trabalho de agente, depois do chat turno-a-turno e dos loops /goal. No modo cron, o agente roda sem supervisão num horário, com os resultados entregues na plataforma de mensageria que você quiser — ou em todas de uma vez via deliver=all (#21495).
Este passo a passo monta um job específico — um relatório matinal — e usa pra explicar como o scheduler funciona de verdade. O mesmo padrão dá conta de backups noturnos, auditorias semanais de segurança, avisos de troca de plantão, ou o que mais você estiver ligando agora com bash + cron meio frágil.
O que vamos montar
Todo dia útil às 8 da manhã:
- 1.Ler os e-mails da noite (desde 17h de ontem)
- 2.Puxar as notificações do GitHub (issues, reviews de PR, menções)
- 3.Conferir o calendário das primeiras 4 horas de hoje
- 4.Resumir os três numa mensagem só de Telegram
Se aconteceu algo importante, a mensagem é detalhada. Se não aconteceu nada, a mensagem é uma frase: "Noite tranquila. Calendário leve até as 11."
Passo 1: definir o job
hermes cron add te conduz pela criação. A CLI pergunta: um nome, um horário, a descrição do job (linguagem natural) e os 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 é sintaxe cron padrão: minuto 0, hora 8, qualquer dia do mês, qualquer mês, de segunda a sexta. O Hermes aceita tanto sintaxe cron quanto expressões mais soltas em linguagem natural, tipo "every weekday at 8 AM".
Passo 2: o que roda às 8
No próximo dia útil às 8, o Hermes sobe uma sessão de agente isolada com:
- •A descrição do job como mensagem inicial do usuário
- •Os skills que o agente decidir chamar (
email,github,google-calendar) - •Um delivery hook que envia a resposta final pro Telegram
Sem contexto persistente, sem usuário digitando. O agente lê a descrição, chama os skills, esboça uma mensagem, manda. Tipicamente em 15 a 30 segundos.
A saída aparece no Telegram como mensagem do seu bot do Hermes. Se o job demorou mais que o normal ou bateu num erro, você também recebe uma mensagem de erro no mesmo canal.
Passo 3: deliver=all — espalhamento pra todas as plataformas
Por padrão, a entrega vai pra uma plataforma — aquela que você indicou em cron add. Se quer que o relatório caia em qualquer lugar que possa te alcançar, define:
hermes cron edit daily-morning-report --deliver all
Agora a mensagem sai pra toda plataforma de mensageria conectada de uma vez — seu Telegram, Discord, Slack, WhatsApp, Signal, LINE, SimpleX, o que você tiver configurado. A v0.14.0 ligou a entrega por plataforma especificamente pro cron (#21495).
Quando é útil: você quer a garantia de ver a mensagem independentemente do app em que estiver.
Quando é exagero: você só checa uma plataforma de manhã. Pega só ela.
Passo 4: ver o que tá agendado
hermes cron list
Mostra tudo agendado, próxima execução, status da última. A v0.14.0 adicionou busca por nome pra operações de job (#26231), daí você consegue referenciar jobs por nome em vez de ID:
hermes cron logs daily-morning-report --last 5
hermes cron disable daily-morning-report
hermes cron run-now daily-morning-report # dispara agora, fora do horário
O que acontece quando um job quebra
Jobs de cron rodam na sua própria sessão de sandbox (mesmos backends do Hermes interativo — vê o post sobre backends de sandbox). Se uma chamada de skill falha, o agente recebe o erro e ou tenta de novo ou reporta.
Se o job inteiro derruba (o próprio agente sai com erro), o Hermes te avisa na sua plataforma de mensageria padrão com o erro e um link pros logs. O trabalho de durabilidade de sessão da v0.13.0 garante que um reinício de gateway não perde entregas de cron pendentes — a deduplicação vai por claim atômico com rewind em caso de falha (#23401).
Alguns jobs úteis de verdade
Esses são padrões que gente roda de verdade:
Verificação de backup noturna. Cron às 3 da manhã: listar snapshots de backup, conferir que o de hoje existe e não tá vazio, falhar bem alto se sumir. deliver=all pra você acordar com a falha se tiver uma.
Auditoria semanal de segurança. Cron domingo 22h: puxar advisories de dependências, escanear CVEs conhecidos nos seus lockfiles, resumir as vulnerabilidades novas. O verificador de advisories de cadeia de suprimentos da v0.14.0 (#24220) deixa isso mais limpo do que scripts caseiros.
Passagem de plantão. Cron sexta 17h: ler os incidentes da semana, escrever um parágrafo de transferência pro plantonista da próxima semana. Entrega no canal compartilhado do Slack.
Watchers (o skill da v0.14.0, #21881). Faz polling num feed RSS, num endpoint HTTP JSON ou num repositório do GitHub procurando mudanças ; só te avisa quando algo mudou. Combinado com cron, vira "me avisa quando o X mudar", um dos primitivos de automação mais subaproveitados que existem.
Onde os logs vão
hermes cron logs daily-morning-report
Por padrão, as últimas 10 execuções. Cada uma mostra: timestamp, duração, quais skills foram chamados, o que foi entregue, o que falhou se algo falhou. Os logs ficam em ~/.hermes/cron/logs/ e rotacionam automaticamente.
Por que isso ganha de escrever um script de shell
Você consegue escrever esse mesmo relatório diário como bash + cron + curl pro Telegram + talvez uma chamadinha de LLM. Muita gente já fez assim.
O motivo de cron-em-cima-de-agente ser interessante:
- 1.A descrição do job é a spec. Sem código pra manter. Você muda "4 primeiras horas" pra "6 primeiras horas" — edita a descrição, não tem que redeployar.
- 2.Skills se compõem. Adicionar "também olha o Linear pra tickets novos" é uma frase na descrição. Com um script de shell, é um cliente de API novo.
- 3.Entrega tá desacoplada.
deliver=allsignifica que você não escreve 5 webhooks diferentes pra 5 apps de chat diferentes. O gateway já fala todas as 22. - 4.Erros são debugáveis. Quando um job quebra, o agente te conta o que tentou e por que falhou, em português. Scripts de bash te dão exit code 1.
Isso não faz de agent-cron a resposta certa sempre — pra jobs que precisam ser 100% determinísticos e fechar em 30 ms, script de shell continua melhor. Mas pra "faz algo pensado nesse horário e me avisa", cron-no-Hermes é a ferramenta mais limpa da caixa.