Seu job de briefing das 9h te contou os mesmos três itens de novo esta manhã — igual ontem e anteontem. Não porque ele seja burro: toda execução começava do zero, sem ideia do que já te tinha contado, então um job que vigiava uma página e reportava mudanças ficava re-reportando a história inteira. Jobs agendados eram peixes dourados. A v0.21.0 conserta o lado da memória dessa história: agentes de cron agora carregam e atualizam memória persistente como qualquer outro agente, uma nova flag --continuity injeta a saída anterior da própria execução na próxima, cada job ganha um bloco de notas durável que você pode ler e escrever pela CLI, e jobs em monitor mode podem pular o LLM inteiramente quando nada mudou.

O que mudou, em três partes

1. A memória é carregada, não ignorada. Agentes de cron agora leem MEMORY.md / USER.md no system prompt e podem atualizar memória persistente entre execuções — o mesmo mecanismo que agentes interativos usam. Um job que aprende algo num dia sabe disso no dia seguinte.

2. --continuity leva a última execução adiante. O scheduler injeta a saída anterior do próprio job no prompt da nova execução: “use isso para continuity — evite repetir o que já foi reportado.” É exatamente o que um monitor precisa para deduplicar. Adicione na criação ou altere depois:

hermes cron create --schedule "0 9 * * *" \
  --prompt "Summarize new activity on the status page" \
  --continuity
hermes cron edit <job_id> --continuity     # ou --no-continuity para desligar

A primeira execução não muda; a partir da segunda, o job acorda sabendo o que disse da última vez. O texto de ajuda resume os casos de uso: scouts, monitors, digests incrementais.

3. Um bloco de notas que o job — e você — pode ler e escrever. Cada job ganha um scratchpad durável de chave-valor:

hermes cron notepad <job_id> list
hermes cron notepad <job_id> set last_sync "2026-09-01"
hermes cron notepad <job_id> get last_sync
hermes cron notepad <job_id> delete last_sync

O conteúdo do bloco é injetado no prompt do job a cada execução, então o próprio agente pode atualizar o próprio estado entre execuções — um checkpoint do que já processou, sem a semântica do sistema de memória atrapalhar.

Monitor mode: sem mudanças, sem conta de LLM

A peça complementar é o refinamento do monitor mode: jobs que vigiam um script ou URL em busca de mudanças usam detecção de mudanças com hash suprimido, e quando nada mudou o job pode pular o LLM inteiramente — nenhum token queimado para reportar “continua igual.” É a diferença entre um watchdog que custa alguns centavos por verificação e um que não custa nada até algo realmente se mexer.

Melhorias de apoio nas bordas

A janela também trouxe vizinhos práticos: validação de config pré-dispatch (um job quebrado falha antes de disparar, não durante), assinaturas de falha com ack (reconheça um incidente uma vez e o job para de te avisar sobre ele), fixação de reasoning-effort por job (--reasoning-effort none|low|medium|… sobrescreve a configuração global só para aquele job) e “Trigger now” executa imediatamente em vez de enfileirar. Combinados com os health checks do cron doctor da mesma janela, os jobs agendados saíram do “configurar e torcer” para um sistema que lembra, deduplica e te avisa quando está quebrado.

Juntando tudo

Um padrão realista: um job noturno vigia a página de changelog de um concorrente com --monitor-url, mantém no bloco de notas o último commit visto e roda com --continuity — assim ele só reporta itens genuinamente novos, e se perder uma execução, a próxima ainda sabe o que viu por último. Para o resto da superfície de cron — schedules, entrega, jobs só de script — nosso guia de automação de cron tem o tour completo, e o mergulho em monitor + bloco de notas cobre a mecânica de preflight.