Já entregou uma tarefa longa ao Hermes e ficou voltando a cada dez minutos para digitar “continue”? Já viu o agente declarar “pronto” — mas você não confiava de todo, então rodou os testes você mesmo para verificar? Já desejou que o Hermes transformasse o que acabou de fazer em uma skill reutilizável, sem esperar que o contador interno dele decidisse que era hora?

Em 6 de agosto de 2026, três novos comandos chegaram ao branch main do Hermes Agent que atacam exatamente esses pontos de dor:

• /heartbeat — anexa um “alarme” recorrente à sessão atual. Quando a sessão está ociosa e o intervalo se esgota, o prompt é injetado como um turno de usuário normal, e o agente continua de olho por conta própria.
• /refine — dispara a revisão de autoaperfeiçoamento de memória/skill sob demanda (chega de esperar os contadores automáticos), com instruções opcionais de focus.
• /goal gate — anexa quality gates determinísticos a um goal persistente: um comando de shell precisa sair com exit code 0 antes que o goal possa ser considerado concluído. O “está pronto” de um LLM deixou de ser a palavra final.

Os três são adaptados do Prime-Agent da Prime Intellect (/heartbeat, o Continual Harness e o --autonomous-gate), mas as implementações do Hermes se conectam ao estado durável do próprio Hermes — os memory stores + skill stores e a SessionDB. Importante: esses comandos foram integrados ao main em 2026-08-06 e a documentação oficial já os cobre, mas eles ainda não estão em nenhum release formal (o release mais recente continua sendo o v0.20.0). Tudo neste artigo foi verificado contra a documentação oficial e as mensagens de commit; você pode experimentá-los hoje em uma nightly build ou esperar o próximo release.

Se você ainda não usou o /goal, comece pelo nosso mergulho no release Herald e pelo apanhado de truques escondidos, que cobre o básico do /goal.

1. /heartbeat: deixe a sessão acordar sozinha e trabalhar

/heartbeat dá à sessão atual uma instrução recorrente. Sempre que a sessão está ociosa e o intervalo se passou, a instrução é injetada como uma mensagem comum com papel de usuário — mesma conversa, mesmo contexto, mesmo prompt cache. Nada é trocado.

/heartbeat every 10m Check the deployment and report meaningful changes

Uma vez definido, a sessão “acorda” dez minutos depois e executa a instrução. A documentação oficial traz um exemplo muito familiar: você está codando na mesma sessão enquanto o Hermes observa o CI:

You: /heartbeat every 15m Check whether the CI run for PR #1234 finished; summarize the result when it does

  ♥ Heartbeat set (every 15m): Check whether the CI run for PR #1234 finished; ...

[15 minutes of you working on other things in the same session]

Hermes: [Heartbeat — recurring instruction, fires every 15m]
  💻 gh pr checks 1234   (1.2s)
  CI is still running (14/37 checks complete). Nothing to report yet.

Comandos e subcomandos

Comando	O que faz
/heartbeat every <interval> <prompt>	Define (ou substitui) o heartbeat da sessão. Intervalos: 90s, 10m, 2h, 1d (mínimo de 60s).
/heartbeat ou /heartbeat status	Mostra o heartbeat, o intervalo e o tempo até o próximo disparo.
/heartbeat pause	Para os disparos sem apagar a configuração.
/heartbeat resume	Retoma (reancora o timer — sem disparo imediato defasado).
/heartbeat clear	Remove o heartbeat.

/hb é um alias. Funciona na CLI e em todas as plataformas de gateway (Telegram, Discord, Slack, …); no Slack, escreva /hermes heartbeat ....

Detalhes importantes de comportamento

• Somente quando ocioso. Um heartbeat nunca interrompe um turno em andamento; um tick que vence enquanto o agente está ocupado dispara na próxima checagem ociosa.
• Ticks perdidos se consolidam. Se a sessão esteve ocupada (ou o processo não estava rodando) por vários intervalos, você recebe um turno de heartbeat, nunca um acúmulo.
• Mensagens de usuário têm prioridade. Uma mensagem real de usuário na fila sempre tem prioridade; o heartbeat espera a fila de entrada esvaziar.
• Seguro para o cache. O prompt injetado é uma mensagem de usuário comum — sem mutação do system prompt, sem mudança no toolset, o prompt caching permanece intacto.
• Proteção contra trabalho inventado. O prompt injetado instrui o agente a responder de forma breve e parar quando nada de relevante mudou, para que um heartbeat ocioso não gere trabalho desnecessário.
• Persistência. O estado fica em SessionDB.state_meta na chave heartbeat:<session_id> — ele sobrevive ao /resume e à rotação de context compression. Para disparar, é preciso que o processo dono (sessão CLI ou gateway) esteja rodando; para agendamentos que precisam sobreviver a qualquer coisa, use o cron.

/heartbeat vs cron: qual usar?

	/heartbeat	hermes cron
Roda em	Nesta conversa — contexto completo, memória da discussão	Uma sessão isolada nova a cada tick
Sobrevive a reinício do processo	O estado sobrevive (SessionDB); os disparos retomam na próxima vez que a sessão for usada	Sim — agendador totalmente durável
Quantidade	Um por sessão	Jobs ilimitados
Melhor para	“Ficar de olho em X nesta thread enquanto trabalhamos”	Jobs contínuos, relatórios, watchdogs, entregas

Regra prática: se o prompt recorrente precisa do contexto da conversa, use o /heartbeat. Se for um job autocontido, use o cron. Eles se complementam.

2. /refine: rode a revisão de autoaperfeiçoamento quando você quiser

O Hermes traz um mecanismo de autoaperfeiçoamento em background: a cada N turnos (cerca de 10 turnos no lado da memória, 10 iterações no lado das skills), ele inicia uma background review entre turnos que destila a conversa em entradas duráveis no memory store ou em skills no skill store. Ótimo mecanismo — mas o ritmo é fixo. Você não pode dizer “faça isso agora, imediatamente”.

/refine é esse “agora”:

/refine

Sem argumentos, ele dispara exatamente a mesma background review do gatilho automático — mas sobre um snapshot, deixando sua conversa ao vivo e o prompt cache intactos, e reporta os resultados ao terminar.

A variante mais interessante aceita instruções de focus:

/refine save the deploy workflow as a skill

O texto de focus é anexado ao prompt da revisão, para que o processo em background priorize o que você pediu. A revisão roda em uma thread em background sobre um snapshot do histórico da conversa — “aprender enquanto você continua conversando” funciona muito bem.

Esse é o conceito de Continual Harness do Prime-Agent mapeado no Hermes: o estado durável equivalente do Hermes são os memory stores + skill stores, então o fork de revisão é o ponto de aterrissagem natural. As revisões automáticas pós-turno passam None como focus e seus prompts são byte a byte idênticos aos de antes — o novo comando não muda nada nas revisões automáticas, apenas adiciona um ponto de entrada manual.

Casos de uso práticos:

• Acabou de fazer um fluxo de deploy complexo funcionar: /refine save the deploy workflow as a skill, deixe-o destilar os passos em uma skill reutilizável em background.
• Percebeu que seu estilo de prompting continua fazendo o agente tropeçar no mesmo tipo de passo: /refine review how I phrase change requests, direcione a revisão para esse ponto de dor específico.
• Fim de uma sessão longa: rode um /refine geral para arquivar os aprendizados da conversa inteira.

3. /goal gate: transforme “pronto” em um veredito de máquina, não em um julgamento de prosa

Por padrão, a conclusão do /goal é decidida por um judge model lendo a conversa — isso já é bom, mas “prosa” é probabilística por natureza. Um quality gate é mais forte: um comando de shell determinístico que precisa sair com exit code 0, senão o goal não pode ser considerado concluído de forma alguma.

/goal Fix the flaky session tests
/goal gate add scripts/run_tests.sh tests/hermes_cli/test_goals.py

Como os gates rodam, a cada turno

1. Os gates rodam antes do judge. Se algum gate falhar, o judge não é chamado — um gate vermelho é evidência determinística de que o goal não está pronto. O exit code do gate e a cauda da saída (últimos ~3 KB) viram o prompt de continuação, então o agente itera contra a falha real em vez de um palpite.
2. Todos os gates passam → julgamento normal. O judge LLM então decide pronto/continuar/aguardar exatamente como antes.
3. Workspace inalterado → sem nova execução. Se um gate falhou e nada mudou no workspace desde então (rastreado via git fingerprint de HEAD + status da working tree), o gate não é reexecutado — a falha registrada é reproduzida e o contador de tentativas avança. Um agente travado não consegue queimar tempo de relógio reexecutando uma suíte vermelha idêntica. Fora de um repositório git, os gates simplesmente sempre reexecutam.
4. Tentativas limitadas. Cada gate tem por padrão 3 retries e um timeout de 5 minutos. Quando um gate esgota as tentativas, o goal pausa automaticamente (como no turn budget) com uma mensagem dizendo para você corrigir manualmente, remover o gate ou usar /goal resume.

Comandos

Comando	O que faz
/goal gate add <command>	Adiciona um quality gate.
/goal gate ou /goal gate list	Lista os gates do goal e o estado de aprovação/falha deles.
/goal gate remove <N>	Remove o N-ésimo gate (baseado em 1).
/goal gate clear	Remove todos os gates.

Os gates persistem junto com o goal em SessionDB.state_meta (sobrevivem ao /resume e à context compression), e a gestão de gates é segura durante a execução — os gates só rodam nas fronteiras de turno.

Como os gates se combinam com os Completion Contracts?

Completion Contracts (introduzidos na v0.18.0) fazem o agente declarar seus próprios critérios de conclusão e provar que os cumpriu — eles moldam o que o agente almeja. Os quality gates atuam no nível do mecanismo: tornam o “pronto” verificável mecanicamente. Os dois se combinam:

• use um contract para moldar o que o agente almeja,
• use os gates para tornar o “pronto” verificável mecanicamente,
• quando ambos estão configurados, os gates rodam primeiro — verificações mecânicas sempre vencem vereditos em prosa.

Combinada com /subgoal e /goal wait <pid> [reason] (estaciona o loop em um processo em background e retoma automaticamente quando ele sai), a família /goal agora é um sistema completo de “executar autonomamente + verificar autonomamente”.

4. Juntando tudo: um workflow mãos-livres completo

Costure os três juntos e uma clássica sessão de “dormir agora, revisar de manhã” fica assim:

# ① Set the goal: make the test suite green and add a regression test
/goal Make scripts/run_tests.sh fully green and add a regression test for the session-close bug

# ② Attach quality gates: not done until the suite passes
/goal gate add scripts/run_tests.sh
/goal gate add git diff --exit-code --stat   # and require actual changes

# ③ Heartbeat: report progress every 30 minutes on its own
/heartbeat every 30m Summarize current goal progress and what you will do next; if nothing changed, reply briefly

# ④ At the end, distill the experience into a skill
/refine save the troubleshooting steps for session-close bugs as a skill

A sessão então se executa sozinha: trabalho → checagem do gate → em caso de falha, itera contra a saída de erro real → quando fica verde, o judge declara pronto → o heartbeat reporta a cada 30 minutos (você dá uma olhada quando quiser) → por fim, o /refine transforma a experiência de debug em uma skill. Você só lê os resultados na manhã seguinte.

Para ir além, anexe a mesma combinação a um gateway (digamos, Telegram) e combine com nosso guia de webhook para notificações de negócio para empurrar eventos de “pronto/falhou” para o seu time — um companheiro de CI totalmente mãos-livres.

5. Ressalvas e limites

• O processo precisa estar vivo. Os loops de /heartbeat e /goal dependem do processo dono (sessão CLI ou gateway). Para agendamento totalmente durável e entre processos, use hermes cron.
• Os gates precisam de um workspace que possam identificar por fingerprint. O pulo de workspace inalterado depende do git fingerprint; fora de um repositório git, os gates simplesmente reexecutam a cada turno.
• Não use o heartbeat como substituto do cron. Ele é “observar esta thread com contexto”, não um agendador geral; um heartbeat por sessão é intencional.
• Status de release. Os três comandos estão no main (integrados em 2026-08-06), ainda sem release formal. Até você atualizar para uma build que os inclua, /heartbeat, /refine e /goal gate reportarão comandos desconhecidos — comportamento esperado.

Conclusão

Individualmente, /heartbeat, /refine e /goal gate são pequenos. Juntos, completam as três últimas peças do quebra-cabeça da autonomia mãos-livres: observar, aprender, verificar. Combinados com o /goal, o /subgoal, os Completion Contracts e o cron existentes, o Hermes passa de “você comanda, ele executa” para “você define as regras, ele trabalha, melhora e prova que está pronto por conta própria”.

Para mais cobertura de recursos de fronteira como esta, acompanhe nosso blog; para o mapa completo de capacidades, a documentação oficial é a fonte autoritativa.