Automatiser avec Hermes Agent

Introduction

Hermes Agent n'est pas seulement un assistant conversationnel : c'est un moteur d'automatisation capable d'executer des taches planifiees, de reagir a des evenements externes et de coordonner des workflows multi-agents. Cette page couvre les trois piliers de l'automatisation Hermes Agent : les crons agentiques (taches planifiees), les webhooks (declencheurs evenementiels) et les files de taches (workflows durables avec kanban).

Ces trois mecanismes sont complementaires. Un cron execute une tache a heure fixe, un webhook reagit a un evenement externe, et une file de taches orchestre un processus multi-etapes avec etat persistant. Savoir lequel choisir est la premiere competence d'un operateur Hermes Agent.

Les trois moteurs d'automatisation

Questions couvertes

q-101: Comment creer une tache planifiee avec Hermes Agent ?

Hermes Agent propose trois interfaces pour creer une tache planifiee, toutes equivalentes :

1. Commande CLI hermes cron create

hermes cron create "0 9 * * *" \
  "Genere un rapport des taches terminees aujourd'hui et envoie-le sur Telegram" \
  --name "rapport-quotidien" \
  --deliver "telegram:-100123456789"

2. Outil cronjob en session

Dans une session Hermes, l'agent peut utiliser l'outil cronjob pour creer, lister, modifier ou supprimer des crons. C'est la methode recommandee quand vous voulez que l'agent configure lui-meme ses propres taches planifiees.

3. Slash command /cron

/cron add "0 9 * * *" "Genere un rapport quotidien" --name "rapport-quotidien"

Formats d'horaire acceptes :

• Duree : "30m", "2h", "90s" (intervalle regulier)
• Phrase naturelle : "every monday 9am", "every 6 hours"
• Cron 5 champs : "0 9 * * *" (chaque jour a 9h00)
• Timestamp ISO : "2026-08-01T14:00:00Z" (execution unique)

Options par job :

| --workdir | Repertoire de travail avec son AGENTS.md | | --deliver | Plateforme de livraison du resultat (telegram, discord, etc.) |

Gerer les crons existants :

hermes cron list              # lister tous les crons
hermes cron runs <nom>        # historique durable des executions
hermes cron edit <nom>        # modifier un cron
hermes cron pause <nom>      # mettre en pause
hermes cron resume <nom>      # reprendre
hermes cron run <nom>         # executer manuellement maintenant
hermes cron remove <nom>      # supprimer

q-102: Quelle difference entre un cron agentique et un script no-agent ?

Un cron Hermes Agent peut fonctionner selon deux modes fondamentalement differents :

Mode agentique (par defaut)

Le prompt est envoye a un LLM qui raisonne, utilise des outils, et produit une reponse. C'est le mode standard : l'agent recoit le prompt, execute les actions necessaires (recherche web, lecture de fichiers, appels API), puis livre le resultat.

hermes cron create "0 8 * * 1" \
  "Analyse les annonces des 3 principaux concurrents cette semaine et resume les tendances" \
  --name "veille-concurrents"

Ce mode a un cout LLM (tokens) mais offre toute la puissance de l'agent : raisonnement, outils, adaptabilite.

Mode script sans agent (no_agent=True)

Le script designe par --script est execute directement, sans passer par un LLM. C'est un script shell ou Python classique. Le resultat (sortie stdout) est livre tel quel sur la plateforme de livraison.

hermes cron create "0 * * * *" \
  --script "check-disk.sh" \
  --no-agent \
  --deliver "telegram:-100123456789" \
  --name "check-disque"

Pour que le script soit le job entier (pas un pre-traitement), ajoutez --no-agent en CLI. L'equivalent de l'outil cronjob est no_agent=True. Le script s'execute, sa sortie est capturee et elle est livree directement, sans cout LLM.

Quand utiliser chaque mode :

q-103: Comment rendre un cron Hermes Agent idempotent ?

L'idempotence est la propriete qui garantit qu'executer un cron plusieurs fois produit le meme resultat qu'une seule execution. Hermes Agent fournit des garde-fous integres, mais la responsabilite finale repose sur la conception du prompt.

Garde-fous integres

1. Fichier .tick.lock : un verrou global empeche deux ticks du scheduler de reclamer simultanement le meme lot de jobs.

2. Sessions fraiches : chaque execution agentique demarre dans une session isolee du chat qui a cree le job.

3. Delai des scripts : les scripts ont un delai configurable distinct, fixe a une heure par defaut. Les jobs agentiques utilisent leur propre budget d'inactivite.

Conception de prompt idempotente

Pour rendre un cron reellement idempotent, votre prompt doit inclure une verification d'etat avant d'agir :

Verifie d'abord si le rapport du {date} existe deja dans ~/rapports/.
S'il existe, termine sans rien faire.
Sinon, genere le rapport et sauvegarde-le dans ~/rapports/rapport-{date}.md.

Chainage avec context_from

Le parametre context_from de l'outil cronjob permet d'injecter la derniere sortie terminee d'un job A au demarrage du job B (voir q-105). Il ne synchronise pas deux jobs lances pendant le meme tick.

Bonnes pratiques :

• Utilisez des noms de fichiers horodates pour les sorties de cron
• Verifiez l'existence du resultat avant de le produire
• Preferez les operations idempotentes (UPSERT, PUT) aux operations non idempotentes (INSERT, POST)
• Pour les crons critiques, utilisez hermes cron run <nom> pour tester l'idempotence manuellement

q-104: Comment recevoir le resultat d'un cron sur Telegram ou Discord ?

Hermes Agent supporte la livraison multi-plateforme des resultats de cron. La configuration se fait au moment de la creation du cron avec --deliver.

Livraison sur Telegram

hermes cron create "0 8 * * *" \
  "Resume les taches planifiees pour aujourd'hui" \
  --name "rapport-matin" \
  --deliver "telegram:-100123456789"

La cible --deliver accepte le format plateforme:chat_id, et plateforme:chat_id:thread_id pour un topic pris en charge.

Livraison sur Discord

hermes cron create "*/30 * * * *" \
  "Verifie la sante des serveurs et alerte si anomalie" \
  --name "alerte-serveur" \
  --deliver "discord:123456789012345678"

Livraison multi-plateforme

Un meme cron peut livrer sur plusieurs plateformes simultanement en separant les cibles par des virgules :

hermes cron create "*/5 * * * *" \
  "Surveille les logs d'erreur et alerte si critique" \
  --name "incident-critique" \
  --deliver "telegram:-100111111111,discord:222222222222222222,slack:C03ABCDEFGH"

Format des livraisons

Les livraisons de cron sont encadrees par un header et un footer qui preservent l'alternance des roles dans la conversation. Le message apparait comme une notification structuree, pas comme un message miroir de la session agent.

Plateformes supportees : Telegram, Discord, Slack, WhatsApp, iMessage, Signal, Matrix, Teams, Email, et GitHub comment (pour les webhooks). La liste complete depend de la version de Hermes Agent et des plateformes activees dans votre gateway.

q-105: Comment chainer plusieurs jobs Hermes Agent sans course de donnees ?

Le chainage de jobs permet d'executer des workflows ou le job B reutilise la derniere sortie terminee du job A. Hermes Agent expose cette fonction via le parametre context_from de l'outil cronjob.

Chainage simple avec context_from

cronjob(action="create", schedule="0 6 * * *", prompt="Extrais les metriques", name="collecte")
cronjob(
    action="create",
    schedule="0 7 * * *",
    prompt="Analyse les metriques collectees",
    name="analyse",
    context_from=["<job-id-collecte>"],
)

Avec context_from, la derniere sortie complete du job A est injectee dans le contexte du job B avant son execution. Pour une dependance stricte sur une execution precise, utilisez plutot le Kanban et ses liens parent-enfant.

Prevention des courses de donnees

1. .tick.lock global : le verrou empeche deux ticks du scheduler de reclamer le meme lot. Il ne remplace pas une dependance explicite entre deux jobs distincts.

2. Decalage des horaires : decaler les horaires reduit le risque de chevauchement, mais ne garantit pas que le job A est termine. Pour une dependance stricte, utilisez des cartes Kanban liees.

3. Sessions separees : chaque job s'execute dans une session fraiche. Passez les donnees necessaires explicitement par les fichiers, un script ou context_from.

Workflows complexes avec Kanban

Pour des chainages plus complexes (branchements conditionnels, reessais, etat intermediaire), utilisez le systeme kanban (voir q-110). Kanban offre une file de taches durable avec etat persistant, ideale pour les workflows multi-etapes.

# Creer un workflow kanban
hermes kanban create "pipeline-donnees" \
  --board "production" \
  --prompt "Etape 1: Collecter les donnees. Etape 2: Les analyser. Etape 3: Produire le rapport."

# Le dispatcher kanban gere l'enchainement, les reessais et la persistance

q-106: Comment declencher Hermes Agent depuis un webhook ?

Les webhooks permettent a des services externes (GitHub, GitLab, Stripe, CI/CD, monitoring) de declencher une execution de Hermes Agent en envoyant une requete HTTP POST.

Etape 1 : Activer la plateforme webhook

hermes gateway setup

Suivez les instructions pour activer les webhooks, definir le port (defaut 8644) et configurer un secret HMAC global.

Ou manuellement dans ~/.hermes/config.yaml :

platforms:
  webhook:
    enabled: true
    extra:
      port: 8644
      secret: "votre-secret-hmac-genere"

Puis demarrez le gateway :

hermes gateway run

Verifiez que le serveur webhook ecoute :

curl http://localhost:8644/health
# Retourne {"status": "ok"}

Etape 2 : Creer un abonnement webhook

hermes webhook subscribe github-issues \
  --events "issues" \
  --prompt "Nouvelle issue GitHub #{issue.number}: {issue.title}\n\nAction: {action}\nAuteur: {issue.user.login}\n\n{issue.body}\n\nAnalyse cette issue et propose un triage." \
  --deliver telegram \
  --deliver-chat-id "-100123456789"

La commande retourne une URL de webhook et un secret HMAC. Configurez votre service externe (GitHub, GitLab, etc.) pour envoyer des POST a cette URL avec le secret.

Templates de prompt

Les prompts supportent la notation {payload.champ} pour acceder aux champs du JSON recu :

• {issue.title} -- titre d'une issue GitHub
• {pull_request.user.login} -- auteur d'une PR
• {data.object.amount} -- montant d'un paiement Stripe
• {alert.severity} -- severite d'une alerte monitoring

Si aucun prompt n'est specifie, le JSON complet est injecte dans le prompt de l'agent.

Securite

Chaque abonnement recoit un secret HMAC-SHA256 genere automatiquement. Le gateway valide la signature de chaque requete entrante. Les abonnements sont persistes dans ~/.hermes/webhook_subscriptions.json.

Filtrage des evenements

Pour les services qui emettent beaucoup d'evenements (Todoist, GitHub), vous pouvez filtrer les payloads avant qu'ils n'atteignent l'agent :

hermes webhook subscribe todoist-hermes \
  --prompt "Tache modifiee: {payload.content}" \
  --script "filtre-todoist.py" \
  --deliver telegram --deliver-chat-id "12345"

Le script (dans ~/.hermes/scripts/) recoit le JSON sur stdin. S'il retourne une sortie vide, [SILENT], ou un code de sortie non nul, le webhook est ignore silencieusement.

Livraison directe sans agent (--deliver-only)

Pour les cas ou vous voulez simplement transmettre une notification sans cout LLM :

hermes webhook subscribe alerte-monitoring \
  --deliver telegram \
  --deliver-chat-id "123456789" \
  --deliver-only \
  --prompt "🚨 Alerte: {alert.name}\nSeverite: {alert.severity}\n{alert.message}"

Le prompt est rendu comme message litteral et livre directement, sans passer par l'agent.

q-107: Comment executer une tache autonome longue sans perdre son etat ?

Les taches longues (plusieurs minutes a plusieurs heures) posent un defi de durabilite : si le processus parent s'arrete, l'etat de la tache est perdu. Hermes Agent propose trois strategies, classees par durabilite croissante.

Strategie 1 : delegate_task avec background=true (non durable)

delegate_task(goal="Analyser les 500 PRs du depot et produire un rapport", background=true)

Le sous-agent s'execute en arriere-plan et son resultat reentre dans la conversation a la fin. Mais c'est process-local : si le processus parent s'arrete, le sous-agent est perdu. Utilisez cette approche pour les taches de quelques minutes ou quand la perte est acceptable.

Strategie 2 : terminal avec background=true et notify_on_complete=true (semi-durable)

hermes chat -q "Execute une analyse complete du codebase" &

Le processus Hermes est independant du parent. Si le terminal est ferme, le processus continue (s'il a ete lance avec nohup ou dans un tmux). Utilisez notify_on_complete=true pour etre averti quand la tache se termine.

Pour les sessions interactives longues, utilisez tmux :

tmux new-session -d -s analyse-longue -x 120 -y 40 'hermes'
tmux send-keys -t analyse-longue 'Analyse les 500 PRs et produis un rapport' Enter
# Plus tard...
tmux capture-pane -t analyse-longue -p | tail -50

Strategie 3 : Cron ou Kanban (durable)

Pour les taches qui doivent survivre aux arrets de processus et aux redemarrages :

• Cron : planifiez la tache avec hermes cron create. L'etat est persiste dans la configuration du cron. Utilisez context_from dans l'outil cronjob pour reutiliser une sortie precedente, sans le confondre avec une dependance stricte.

• Kanban : creez une tache kanban pour un workflow multi-etapes durable. L'etat est persiste dans une base SQLite. Le dispatcher gere les reclamations, les timeouts et les reessais automatiquement.

hermes kanban create "analyse-500-prs" \
  --board "production" \
  --prompt "Etape 1: Lister les 500 PRs. Etape 2: Les analyser par lot de 50. Etape 3: Produire le rapport final."

Reprise de session

Si une tache longue est interrompue, vous pouvez reprendre la session :

hermes --resume                    # reprend la session la plus recente
hermes --resume 20260730_143052_abc123  # reprend une session specifique

q-108: Comment empecher un cron de lancer une commande necessitant une approbation ?

Les crons s'executent de maniere non interactive : il n'y a personne pour approuver une commande dangereuse. Hermes Agent integre plusieurs mecanismes pour eviter qu'un cron ne se bloque en attente d'une approbation.

1. Les sessions cron sont non interactives par defaut

Les crons ne passent pas par le mode interactif standard. L'agent sait qu'il est dans un contexte cron et adapte son comportement : il evite les commandes qui necessiteraient une approbation.

2. Restreindre les toolsets du cron

Au moment de la creation du cron, specifiez un toolset restreint qui exclut les outils dangereux :

hermes cron create "0 * * * *" \
  "Verifie l'etat du systeme" \
  --skill "system-check" \
  --name "tache-securisee"

Dans le skill system-check, definissez les outils autorises. Vous pouvez aussi configurer le cron pour utiliser un toolset limite :

# Dans la configuration du cron (config.yaml ou via hermes cron edit)
cron:
  jobs:
    tache-securisee:
      toolsets:
        - file
        - web

3. Utiliser le mode script sans agent

Pour les taches purement deterministes, utilisez --script avec --no-agent en CLI (voir q-102). Le script s'execute sans LLM, donc sans possibilite de generer une commande dangereuse.

4. Restreindre les toolsets avec l'outil cronjob

L'outil permet de limiter explicitement les familles d'outils accessibles au job :

cronjob(
    action="create",
    schedule="0 * * * *",
    prompt="Verifie les logs en lecture seule",
    name="tache-safe",
    enabled_toolsets=["file"],
)

5. Principe de conception : ecrire des prompts sans action destructive

Concevez vos prompts de cron pour qu'ils evitent les actions destructives. Par exemple :

Analyse les logs d'erreur et PROPOSE des corrections.
N'execute AUCUNE commande de modification.
Limite-toi a la lecture et a l'analyse.

L'agent, dans un contexte cron, interprete ces instructions et s'abstient de lancer des commandes necessitant approbation.

q-109: Comment surveiller les echecs et relancer un job Hermes Agent ?

La surveillance des echecs combine les outils integres de Hermes Agent avec les notifications de livraison.

Surveillance integree

1. Lister l'etat des crons

hermes cron list

Affiche le statut de chaque cron (actif, en pause, derniere execution, dernier resultat).

2. Consulter les logs du gateway

grep cron ~/.hermes/logs/gateway.log | tail -30

Les logs du gateway enregistrent chaque execution de cron, son statut (succes ou echec) et les erreurs rencontrees.

3. Notifications de livraison

Configurez vos crons avec --deliver pour recevoir les resultats (et les echecs) directement sur Telegram ou Discord. Si un cron echoue, l'erreur est livree sur la plateforme configuree.

Relance manuelle

Pour reexecuter un cron immediatement :

hermes cron run <nom>

Cela declenche une execution unique sans attendre le prochain tick planifie.

Relance automatique avec Kanban

Pour les workflows ou la relance automatique est critique, utilisez le systeme kanban. Le dispatcher kanban gere automatiquement :

• Reclamations de taches stale : si un worker ne renouvelle pas son heartbeat, la tache est reclaim et reassignee
• Reessais sur echec : le dispatcher reessaie une tache echouee jusqu'a failure_limit fois (defaut 2, configurable par tache avec max_retries)
• Blocage automatique : apres failure_limit echecs consecutifs, la tache est bloquee pour eviter les boucles infinies

hermes kanban create "job-critique" \
  --board "production" \
  --max-retries 5 \
  --prompt "Execute cette tache critique. Si elle echoue, elle sera reessayee automatiquement."

Pattern de surveillance avancee : cron de surveillance

Creez un cron dedie a la surveillance des autres crons :

hermes cron create "*/15 * * * *" \
  "Verifie le statut de tous les crons. Si un cron a echoue, analyse l'erreur et propose une correction sans mutation." \
  --name "surveillance-crons" \
  --deliver "telegram:-100123456789"

q-110: Quand utiliser un webhook, un cron ou une file de taches ?

Le choix du mecanisme d'automatisation depend de la nature du declencheur et des exigences de durabilite.

Utilisez un webhook quand :

• Le declencheur est un evenement externe (push GitHub, paiement Stripe, alerte monitoring)
• La tache est ponctuelle (une execution par evenement)
• Vous avez besoin d'une reaction en temps reel (quelques secondes apres l'evenement)
• La durabilite n'est pas critique (si le gateway est arrete, l'evenement est perdu -- sauf si le service emetteur reessaie)

Exemples : triage d'une nouvelle issue GitHub, notification de paiement, alerte de build CI.

Utilisez un cron quand :

• Le declencheur est temporel (tous les jours a 9h, toutes les 30 minutes)
• La tache est recurrente et previsible
• Vous avez besoin d'une planification persistante geree par le gateway
• La tache respecte les budgets d'execution du scheduler et de ses outils

Exemples : rapport quotidien, nettoyage de fichiers temporaires, veille concurrentielle, verification de sante.

Utilisez une file de taches (kanban) quand :

• Le workflow comporte plusieurs etapes avec etat intermediaire
• Vous avez besoin de coordination multi-agents (plusieurs workers sur le meme board)
• La durabilite est critique (l'etat survit aux arrets et redemarrages)
• Vous voulez des reessais automatiques avec backoff
• La tache est longue (plusieurs heures, divisee en sous-taches)

Exemples : pipeline de traitement de donnees, revision de code multi-etapes, migration de base de donnees par lots.

Tableau de decision

Combinaison des trois mecanismes

Les trois systemes ne sont pas exclusifs. Un pattern courant :

1. Un webhook recoit un evenement externe (ex: nouveau commit)
2. Le webhook cree une tache kanban pour un workflow multi-etapes
3. Un cron de surveillance verifie que les taches kanban ne stagnent pas

Cette architecture combine la reactivite du webhook, la durabilite de kanban et la securite du cron de surveillance.

Sources

• Documentation officielle Hermes Agent (https://hermes-agent.nousresearch.com/docs/)
• Guide Cron (https://hermes-agent.nousresearch.com/docs/user-guide/features/cron)
• Guide Webhooks (https://hermes-agent.nousresearch.com/docs/user-guide/messaging/webhooks)
• CLI commands reference (https://hermes-agent.nousresearch.com/docs/reference/cli-commands)
• Depot NousResearch/hermes-agent, commit b4f8c491

Liens internes proposes

• Configurer Hermes Agent
• Outils et MCP
• Skills
• Memoire
• FAQ
• Methodologie
• Sources