Como fazer o Hermes Agent executar tarefas recorrentes sozinho?

Pedir a mesma tarefa todo dia é trabalho SEU, definir a rotina uma vez é trabalho do agente

Fala aí, beleza? O Hermes Agent é um agente de IA open source mantido pela Nous Research, com memória persistente entre sessões e skills reutilizáveis, e o repositório oficial já está em 222,6 mil estrelas no GitHub (rank global #20), então não é experimento de fim de semana 🙂

A peça que transforma "me manda o resumo" em "todo dia às 9h o resumo chega" é a ferramenta cronjob

Ela é uma ferramenta única, com operações no estilo action: create, list, update, pause, resume, run e remove. Nada de uma ferramenta pra agendar, outra pra listar e outra pra remover, é tudo a mesma porta de entrada

Bora ver como monta isso na prática?

O que precisa estar pronto antes de agendar a primeira rotina

Antes de sair criando job, vale conferir cinco itens, porque quase todo "não disparou" mora aqui

• Gateway rodando: quem executa o cron é o gateway daemon, com hermes gateway em primeiro plano ou hermes gateway start como serviço instalado
• Arquivo ~/.hermes/cron/jobs.json legível e gravável pelo usuário: é ali que os jobs agendados ficam gravados, e se o arquivo não estiver acessível o scheduler falha em silêncio (o pior tipo de falha, porque não grita)
• Relógio e fuso horário certos na máquina: relógio errado ou fuso diferente do esperado faz os jobs dispararem em horários errados
• Skill já instalada, se o job for usar uma: hermes skills install <skill-name> ou /skills no CLI
• Permissão do bot na plataforma de entrega: bot do Telegram precisa ser admin nos grupos e canais alvo, bot do Discord precisa de permissão de enviar no canal, bot do Slack precisa estar no workspace com escopo chat:write

Que gateway? É o processo que fica de olho no relógio por você: ele ticka o scheduler a cada 60 segundos e roda os jobs vencidos em sessões de agente isoladas

Ou seja: se o gateway está desligado, o job pode estar lindo no arquivo e mesmo assim ninguém aperta o play. Se você ainda está decidindo deixar o gateway sempre ligado ou não, essa é a variável que pesa mais na conta

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Como criar uma tarefa recorrente no Hermes Agent passo a passo

1. Escreva um prompt autocontido

O agente dentro de um job de cron não tem memória das suas conversas. A sessão é nova, do zero, sem o fio do chat de ontem

Então o prompt precisa carregar tudo: URLs, nomes de repositório, preferências de formato e instruções de entrega, tudo escrito ali dentro

É diferente do papo normal, onde a memória persistente do Hermes segura o contexto pra você

O erro comum deste passo: escrever "me manda igual ao que combinamos ontem". Ontem não existe pra sessão de cron

2. Escolha o formato do schedule

O campo schedule aceita quatro formatos:

O erro comum deste passo: escrever daily at 9am achando que o campo entende linguagem natural. Não entende, o formato suportado ali é a expressão cron padrão, ou seja 0 9 *

Detalhe que confunde: você PODE falar em linguagem simples com o agente pra ele criar o job, o que não vale é linguagem natural dentro do campo schedule

3. Anexe uma skill, se a rotina precisar

Um job de cron pode carregar uma ou mais skills antes de rodar o prompt. Exemplo da própria documentação:

cronjob(action="create", skill="blogwatcher", prompt="Check the configured feeds and summarize anything new.", schedule="0 9 * * *", name="Morning feeds")

O erro comum deste passo: escrever o nome da skill com a caixa errada. Nomes de skill são case-sensitive e precisam bater com a pasta da skill instalada

E claro: skill não instalada não é anexada, instale antes com hermes skills install <skill-name>

4. Defina o destino no campo deliver

A resposta final do agente é entregue automaticamente ao destino configurado no campo deliver

• nome puro da plataforma (slack, telegram) entrega no canal padrão configurado
• platform:<target> manda pra um destino específico
• all envia pra todos os canais de mensagem configurados

cronjob(action="create", prompt="Resuma os PRs abertos no repositório X e liste o que está parado há mais de 3 dias.", schedule="0 9 * * *", deliver="telegram", name="PR daily")

O erro comum deste passo: alvo escrito com a caixa errada. Alvos de entrega são case-sensitive e um alvo mal configurado derruba a resposta em silêncio, o job roda bonitinho e você não recebe nada

5. Use repeat quando a rotina tem fim

Jobs recorrentes se re-armam a cada disparo, ou seja, rodam até você mandar parar. Já jobs com contagem definida param quando a contagem acaba:

cronjob(action="create", prompt="Cheque o status do deploy e me avise o resultado.", schedule="every 2h", repeat=5)

Ótimo pra acompanhar uma migração, um deploy longo, uma janela de manutenção e por aí vai

6. Teste sem esperar o horário

Ninguém merece esperar até as 9h da manhã pra descobrir que errou o nome do canal, né? 😀

hermes cron tick
hermes cron run <job_id>

hermes cron tick faz um disparo manual pontual, bom pra depuração. Já hermes cron run <job_id> dispara no próximo tick do gateway, e como o scheduler ticka a cada 60 segundos, é questão de esperar um minutinho

Três rotinas que valem a pena automatizar (e como cada uma é montada)

O desenho é sempre o mesmo: prompt autocontido + schedule + destino. O que muda é a cadência e o que você pede

Relatório diário

Schedule 0 9 *, que é todo dia às 9h

Aqui o prompt precisa ser específico no formato, porque relatório vago vira parede de texto que ninguém lê. Diga quantos itens, em que ordem, o que ignorar

Checagem periódica

Schedule every 2h

Esse é o caso de "me avisa se mudou". O prompt tem que deixar claro o que conta como novidade, senão você recebe a mesma informação oito vezes por dia

Resumo semanal

Schedule 0 9 1, que é 9h de toda segunda-feira

Aqui a entrega costuma ser mais coletiva, então é o job que mais se beneficia de mandar pra um canal de equipe em vez do seu privado

E quando nem precisa acordar o LLM?

Se liga nisso: nem toda rotina precisa de raciocínio

Watchdog, alerta de disco ou memória, heartbeat e ping de CI são scripts, não pensamento. Pra esses casos existe o no_agent=True na criação: roda só o script na agenda, a stdout é entregue literalmente, com zero envolvimento do LLM

Agora atenção, porque aqui são DOIS padrões diferentes e é fácil misturar os dois

O no_agent=True é o extremo: o LLM não entra na jogada em momento nenhum, o que chega pra você é a stdout crua do script

Já o padrão de economia que a própria documentação recomenda é outra coisa: nele o agente CONTINUA no circuito, só que o script é quem faz a coleta de dados (requisições HTTP, I/O de arquivo, controle de estado) e o agente vê só a stdout do script

Ou seja, no segundo caso o agente pensa em cima do resultado já pronto, em vez de gastar turno pra ir buscar o dado

Como gerenciar, pausar e editar os jobs já criados

O ciclo de vida completo está disponível pro agente: criar, listar, editar, pausar, retomar, rodar agora e remover, tudo pedindo em linguagem simples, sem abrir CLI nenhum

Se você preferir a linha de comando, os verbos são estes:

hermes cron list
hermes cron create        # alias: add
hermes cron edit <job_id>
hermes cron pause <job_id>
hermes cron resume <job_id>
hermes cron run <job_id>
hermes cron remove <job_id>

Um detalhe prático que salva a vida: os verbos de mutação e a ferramenta cronjob aceitam o NOME do job no lugar do ID hexadecimal

O nome é aceito de forma case-insensitive, o ID exato tem precedência e, se o nome casar com mais de um job, o comando recusa e imprime os IDs candidatos. Ou seja, ele não chuta por você, o que é ótimo 🙂

Dois pontos que costumam pegar de surpresa:

• skills=[] em um update remove TODAS as skills anexadas ao job, não é "deixa como está"
• dentro de uma execução de cron, os toolsets cronjob, messaging e clarify ficam desabilitados

Esse segundo é um guardrail: impede criação recursiva de cron, impede envio direto de mensagens (a entrega é responsabilidade do scheduler) e impede perguntas interativas, porque não tem ninguém do outro lado pra responder às 9h da manhã

A rotina não disparou: causas comuns e como resolver

E onde olhar quando nada disso explica? Dois arquivos: ~/.hermes/logs/agent.log traz as mensagens do scheduler e ~/.hermes/logs/errors.log traz os avisos

Só não trate log limpo como prova de que está tudo certo: a falha de permissão do jobs.json é justamente do tipo silencioso, então se os dois arquivos não te disserem nada e mesmo assim o job não roda, vá conferir a permissão na mão

Tome cuidado com o combo mais traiçoeiro da lista: permissão de arquivo e alvo de entrega errado falham CALADOS. Você jura que está tudo certo porque não apareceu erro, e o problema é justamente esse

Quando a recorrência atrapalha mais do que ajuda

Agora o outro lado, porque agendar tudo não é vitória

Rotina frequente demais vira ruído: notificação que você aprende a ignorar é pior que notificação nenhuma, e ainda tem o custo de acordar o agente pra ele descobrir que não mudou nada

Pra isso existe um gate bem elegante: um script anexado via script= emite {"wakeAgent": false} como última linha da stdout e o cron pula a execução do agente naquele tick, sem gastar tokens e sem tocar a camada de inferência

{"wakeAgent": false}

Quando o campo wakeAgent é omitido, o padrão é true, ou seja, o agente roda normal

A documentação recomenda esse gate justamente pros polls frequentes, de 1 a 5 minutos: o script checa, e só quando tem conteúdo de verdade é que o agente entra em cena

E não, o script não vira caixa preta: saída com código diferente de zero ou timeout dispara um alerta de erro entregue a você

Se a ideia de escrever sintaxe de cron já te deu preguiça, tem os Automation Blueprints: automações prontas pra rodar, você preenche alguns campos e o Hermes agenda como cron job, sem você escrever * nenhum

Conclusão

Recapitulando o que faz uma rotina rodar sozinha de verdade:

• prompt autocontido, porque a sessão de cron nasce sem memória do seu chat
• schedule em um dos quatro formatos aceitos, e daily at 9am não é um deles
• gateway vivo, que é quem ticka o scheduler a cada 60 segundos
• destino de entrega correto e com a caixa certa, senão a resposta some sem avisar

O próximo passo que eu sugiro: cria um job simples com repeat pequeno, testa com um tick manual, confere se chegou no canal certo e só DEPOIS promove pra agenda definitiva

É muito mais fácil descobrir que o nome do canal estava errado num job de 5 execuções do que num job diário que você só vai perceber semana que vem 😀

até o próximo post!