Avez-vous déjà confié une longue tâche à Hermes, puis vérifié toutes les dix minutes pour taper « continue » ? Avez-vous déjà vu l’agent déclarer « terminé » — sans vraiment lui faire confiance, au point de relancer vous-même les tests pour vérifier ? Avez-vous déjà souhaité qu’Hermes transforme ce qu’il vient de faire en skill réutilisable, sans attendre que son compteur interne décide que le moment est venu ?

Le 6 août 2026, trois nouvelles commandes ont atterri sur la branche main d’Hermes Agent, qui répondent exactement à ces points douloureux :

• /heartbeat — attache une « alarme » récurrente à la session en cours. Lorsque la session est inactive et que l’intervalle s’est écoulé, le prompt est injecté comme un tour utilisateur normal, si bien que l’agent continue de surveiller tout seul.
• /refine — déclenche à la demande la revue d’auto-amélioration mémoire/skill (fini l’attente des compteurs automatiques), avec des instructions focus optionnelles.
• /goal gate — attache des quality gates déterministes à un objectif persistant : une commande shell doit renvoyer un code de sortie 0 avant que l’objectif puisse être jugé terminé. Le « c’est fini » d’un LLM n’est plus le dernier mot.

Les trois sont adaptés de Prime-Agent de Prime Intellect (/heartbeat, le Continual Harness et --autonomous-gate), mais les implémentations Hermes se branchent sur son propre état durable — les memory + skill stores et la SessionDB. Important : ces commandes ont été fusionnées dans main le 2026-08-06 et la documentation officielle les couvre déjà, mais elles ne figurent encore dans aucune version formelle (la dernière version est toujours v0.20.0). Tout dans cet article est vérifié contre la documentation officielle et les messages de commit ; vous pouvez les essayer dès aujourd’hui sur une nightly build ou attendre la prochaine version.

Si vous n’avez pas encore utilisé /goal, commencez par notre plongée dans la release Herald et le tour d’horizon des astuces cachées, qui couvre les bases de /goal.

1. /heartbeat : laisser la session se réveiller et travailler toute seule

/heartbeat donne à la session en cours une instruction récurrente unique. Chaque fois que la session est inactive et que l’intervalle s’est écoulé, l’instruction est injectée comme un simple message de rôle utilisateur — même conversation, même contexte, même prompt cache. Rien n’est remplacé.

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

Une fois défini, la session « se réveille » dix minutes plus tard et l’exécute. La documentation officielle donne un exemple très parlant : vous codez dans la même session pendant qu’Hermes surveille la 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.

Commandes et sous-commandes

Commande	Ce qu’elle fait
/heartbeat every <interval> <prompt>	Définit (ou remplace) le heartbeat de la session. Intervalles : 90s, 10m, 2h, 1d (minimum 60 s).
/heartbeat ou /heartbeat status	Affiche le heartbeat, son intervalle et le temps avant le prochain déclenchement.
/heartbeat pause	Arrête le déclenchement sans l’effacer.
/heartbeat resume	Reprend (ré-ancré le minuteur — pas de déclenchement périmé immédiat).
/heartbeat clear	Supprime le heartbeat.

/hb est un alias. Il fonctionne sur le CLI et sur toutes les plateformes gateway (Telegram, Discord, Slack, …) ; sur Slack, écrivez /hermes heartbeat ....

Détails de comportement clés

• Uniquement en inactivité. Un heartbeat n’interrompt jamais un tour en cours ; une impulsion qui arrive à échéance pendant que l’agent est occupé se déclenche au prochain poll d’inactivité.
• Les impulsions manquées fusionnent. Si la session était occupée (ou que le processus ne tournait pas) pendant plusieurs intervalles, vous obtenez un seul tour de heartbeat, jamais un backlog.
• Les messages utilisateur gagnent. Un vrai message utilisateur en file d’attente a toujours la priorité ; le heartbeat attend que la file d’entrée se vide.
• Sans risque pour le cache. Le prompt injecté est un message utilisateur ordinaire — aucune mutation du system prompt, aucun changement d’outils, le prompt caching reste intact.
• Garde-fou anti-travail inutile. Le prompt injecté demande à l’agent de répondre brièvement et de s’arrêter quand rien de significatif n’a changé, pour qu’un heartbeat inactif ne génère pas d’activité artificielle.
• Persistance. L’état vit dans SessionDB.state_meta, indexé par heartbeat:<session_id> — il survit à /resume et à la rotation de context compression. Le déclenchement exige que le processus propriétaire (session CLI ou gateway) soit actif ; pour des plannings qui doivent survivre à tout, utilisez cron.

/heartbeat vs cron : lequel choisir ?

	/heartbeat	hermes cron
S’exécute dans	Cette conversation — contexte complet, mémoire de la discussion	Une nouvelle session isolée à chaque impulsion
Survit au redémarrage du processus	L’état survit (SessionDB) ; le déclenchement reprend à la prochaine utilisation de la session	Oui — planificateur entièrement durable
Combien	Un par session	Jobs illimités
Idéal pour	« Surveiller X dans ce fil pendant qu’on travaille »	Jobs permanents, rapports, watchdogs, livraisons

Règle empirique : si le prompt récurrent a besoin du contexte de la conversation, utilisez /heartbeat. S’il s’agit d’un job autonome, utilisez cron. Ils se complètent.

2. /refine : lancer la revue d’auto-amélioration quand vous le voulez

Hermes embarque un mécanisme d’auto-amélioration en arrière-plan : tous les N tours (environ 10 tours côté mémoire, 10 itérations côté skill), il lance une revue en arrière-plan entre les tours, qui distille la conversation en entrées durables du memory store ou en skills du skill store. Excellent mécanisme — mais le rythme est fixe. Impossible de lui dire « fais-le maintenant, immédiatement ».

/refine, c’est ce « maintenant » :

/refine

Sans argument, il déclenche exactement la même revue en arrière-plan que le déclencheur automatique — mais sur un snapshot, sans toucher à votre conversation en cours ni au prompt cache, et rapporte les résultats une fois terminé.

La variante la plus intéressante accepte des instructions focus :

/refine save the deploy workflow as a skill

Le texte de focus est ajouté au prompt de la revue, afin que le fork en arrière-plan privilégie ce que vous avez demandé. La revue s’exécute dans un thread d’arrière-plan sur un snapshot de l’historique de la conversation — « apprenez pendant que vous continuez à discuter » fonctionne très bien.

C’est le concept de Continual Harness de Prime-Agent transposé sur Hermes : l’état durable équivalent de Hermes, ce sont les memory + skill stores, donc le fork de revue est le point d’atterrissage naturel. Les revues automatiques post-tour passent None comme focus et leurs prompts sont octet pour octet identiques à avant — la nouvelle commande ne change rien aux revues automatiques, elle ajoute simplement un point d’entrée manuel.

Cas d’usage pratiques :

• Vous venez de faire fonctionner un flux de déploiement complexe : /refine save the deploy workflow as a skill, laissez-le distiller les étapes en skill réutilisable en arrière-plan.
• Vous remarquez que votre façon de formuler les prompts fait trébucher l’agent au même type d’étape : /refine review how I phrase change requests, orientez la revue vers ce point douloureux précis.
• Fin d’une longue session : lancez un /refine général pour archiver tout ce qu’il faut retenir de la conversation.

3. /goal gate : faire de « terminé » un verdict machine, pas un jugement en prose

Par défaut, la complétion de /goal est décidée par un judge model qui lit la conversation — c’est déjà bien, mais la « prose » est probabiliste par nature. Une quality gate est plus forte : une commande shell déterministe qui doit renvoyer un code de sortie 0, sinon l’objectif ne peut tout simplement pas être jugé terminé.

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

Comment les gates s’exécutent, à chaque tour

1. Les gates s’exécutent avant le judge. Si une gate échoue, le judge n’est pas appelé — une gate rouge est une preuve déterministe que l’objectif n’est pas terminé. Le exit code et la fin de sortie (les ~3 derniers Ko) de la gate deviennent le prompt de continuation, si bien que l’agent itère sur l’échec réel plutôt que sur une impression.
2. Toutes les gates passent → jugement normal. Le judge LLM décide alors terminé/continuer/attendre exactement comme avant.
3. Workspace inchangé → pas de relance. Si une gate a échoué et que rien n’a changé dans le workspace depuis (suivi via un git fingerprint de HEAD + l’état de l’arbre de travail), la gate n’est pas relancée — l’échec enregistré est rejoué et le compteur de tentatives avance. Un agent coincé ne peut pas brûler du temps réel à relancer une suite rouge identique. Hors d’un dépôt git, les gates se relancent simplement à chaque tour.
4. Les nouvelles tentatives sont bornées. Chaque gate a par défaut 3 nouvelles tentatives et un timeout de 5 minutes. Quand une gate épuise ses tentatives, l’objectif se met en pause automatiquement (comme le turn budget) avec un message vous invitant à le corriger manuellement, à retirer la gate, ou à faire /goal resume.

Commandes

Commande	Ce qu’elle fait
/goal gate add <command>	Ajoute une quality gate.
/goal gate ou /goal gate list	Liste les gates de l’objectif et leur état réussite/échec.
/goal gate remove <N>	Supprime la Nième gate (indexée à partir de 1).
/goal gate clear	Supprime toutes les gates.

Les gates persistent avec l’objectif dans SessionDB.state_meta (elles survivent à /resume et à la context compression), et la gestion des gates est sûre en cours d’exécution — les gates ne s’exécutent qu’aux frontières de tour.

Comment les gates se combinent-elles avec les Completion Contracts ?

Les Completion Contracts (introduits en v0.18.0) font que l’agent déclare ses propres critères de complétion et prouve qu’il les a satisfaits — ils façonnent ce à quoi l’agent vise. Les quality gates agissent au niveau du mécanisme : elles rendent « terminé » vérifiable mécaniquement. Les deux se combinent :

• utilisez un contrat pour façonner ce à quoi l’agent vise,
• utilisez des gates pour rendre « terminé » mécaniquement vérifiable,
• quand les deux sont définis, les gates s’exécutent en premier — les vérifications mécaniques l’emportent toujours sur les verdicts en prose.

Combinée avec /subgoal et /goal wait <pid> [reason] (garer la boucle sur un processus d’arrière-plan et reprendre automatiquement à sa sortie), la famille /goal est désormais un système complet « exécuter de façon autonome + vérifier de façon autonome ».

4. Tout assembler : un workflow mains libres complet

Assemblez les trois et une session classique « dormez maintenant, relisez au matin » ressemble à ceci :

# ① 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

La session se déroule ensuite toute seule : travail → vérification de la gate → en cas d’échec, itération sur la sortie d’erreur réelle → une fois au vert, le judge déclare terminé → le heartbeat fait son rapport toutes les 30 minutes (vous jetez un œil quand vous voulez) → enfin, /refine transforme l’expérience de débogage en skill. Vous n’avez plus qu’à lire les résultats le lendemain matin.

Pour aller plus loin, attachez la même combinaison à une gateway (par exemple Telegram) et associez-la à notre guide des notifications métier par webhook pour pousser les événements « terminé/échec » vers votre équipe — un compagnon CI mains libres complet.

5. Mises en garde et limites

• Le processus doit être vivant. Les boucles /heartbeat comme /goal dépendent de leur processus propriétaire (session CLI ou gateway). Pour une planification entièrement durable et inter-processus, utilisez hermes cron.
• Les gates ont besoin d’un workspace qu’elles peuvent empreinter. Le saut en cas de workspace inchangé repose sur le git fingerprint ; hors d’un dépôt git, les gates se relancent simplement à chaque tour.
• N’utilisez pas le heartbeat comme substitut de cron. C’est « surveille ce fil avec du contexte », pas un planificateur général ; un heartbeat par session est un choix délibéré.
• Statut de release. Les trois commandes sont sur main (fusionnées le 2026-08-06), pas encore dans une release formelle. Tant que vous n’aurez pas mis à niveau vers un build qui les inclut, /heartbeat, /refine et /goal gate signaleront des commandes inconnues — comportement attendu.

Conclusion

Prises individuellement, /heartbeat, /refine et /goal gate sont petites. Ensemble, elles complètent les trois dernières pièces du puzzle de l’autonomie mains libres : surveiller, apprendre, vérifier. Combiné aux /goal, /subgoal, Completion Contracts et cron existants, Hermes passe de « vous commandez, il exécute » à « vous définissez les règles, il travaille, s’améliore et prouve tout seul que c’est terminé ».

Pour plus de couverture de fonctionnalités de pointe comme celle-ci, suivez notre blog ; pour la cartographie complète des capacités, la documentation officielle est la source faisant autorité.