Automatiser avec Hermes Agent

Cette page fait partie du guide pratique francophone consacré à Hermes Agent. Elle répond à l'intention de recherche : comprendre les automatisations.

Le contenu s'appuie sur la documentation officielle Hermes Agent associée à cette page. L'objectif n'est pas de remplacer la documentation de Nous Research, mais de fournir une lecture claire en français, structurée pour aller vite, avec un maillage logique vers les pages complémentaires du même site.

À retenir

Sujet principal : hermes agent automatisation.
Type de page : hub.
Cluster : automatisation.
Source canonique : documentation officielle Hermes Agent.
Aucun lien vers l'autre domaine n'est utilisé dans cette page.

Comment utiliser cette section

Cette section regroupe les pages du cluster automatisation. Commencez par cette page si vous voulez comprendre le sujet dans son ensemble, puis ouvrez les guides détaillés selon votre contexte.

Chaque page interne contient des liens vers les prérequis, les pages voisines et les suites logiques. Le but est de créer un parcours utile, pas une liste brute de pages SEO.

Base officielle

Schedule tasks to run automatically with natural language or cron expressions. Hermes exposes cron management through a single cronjob tool with action-style operations instead of separate schedule/list/remove tools.

What cron can do now

Cron jobs can:

schedule one-shot or recurring tasks
pause, resume, edit, trigger, and remove jobs
attach zero, one, or multiple skills to a job
deliver results back to the origin chat, local files, or configured platform targets
run in fresh agent sessions with the normal static tool list
run in no-agent mode — a script on a schedule, its stdout delivered verbatim, zero LLM involvement (see the no-agent mode section below)

All of this is available to Hermes itself through the cronjob tool, so you can create, pause, edit, and remove jobs by asking in plain language — no CLI required.

At creation, an unpinned job (one you don't give an explicit provider/model) follows the global default selected by hermes model — and Hermes snapshots that provider and model on the job. If the global default later changes, the job fails closed: it skips the run, makes no inference call, and sends an alert telling you to pin the provider/model explicitly (cronjob action=update job_id=… provider=… model=…) to proceed. This prevents an unattended job from silently inheriting a switch to a paid provider/model and spending money you didn't intend (#44585). To make a job deliberately track your global default, pin it to the new values after changing them. hermes setup --portal is the lowest-friction option for unattended runs since OAuth refresh is automatic. See Nous Portal.

Cron-run sessions cannot recursively create more cron jobs. Hermes disables cron management tools inside cron executions to prevent runaway scheduling loops.

Creating scheduled tasks

In chat with `/cron`

/cron add 30m "Remind me to check the build"
/cron add "every 2h" "Check server status"
/cron add "every 1h" "Summarize new feed items" --skill blogwatcher
/cron add "every 1h" "Use both skills and combine the result" --skill blogwatcher --skill maps

From the standalone CLI

hermes cron create "every 2h" "Check server status"
hermes cron create "every 1h" "Summarize new feed items" --skill blogwatcher
hermes cron create "every 1h" "Use both skills and combine the result" \
  --skill blogwatcher \
  --skill maps \
  --name "Skill combo"

Through natural conversation

Ask Hermes normally:

Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.

Hermes will use the unified cronjob tool internally.

Skill-backed cron jobs

A cron job can load one or more skills before it runs the prompt.

Single skill

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

Multiple skills

Skills are loaded in order. The prompt becomes the task instruction layered on top of those skills.

cronjob(
    action="create",
    skills=["blogwatcher", "maps"],
    prompt="Look for new local events and interesting nearby places, then combine them into one short brief.",
    schedule="every 6h",
    name="Local brief",
)

This is useful when you want a scheduled agent to inherit reusable workflows without stuffing the full skill text into the cron prompt itself.

Running a job inside a project directory

Cron jobs default to running detached from any repo — no AGENTS.md, CLAUDE.md, or .cursorrules is loaded, and the terminal / file / code-exec tools run from whatever working directory the gateway started in. Pass --workdir (CLI) or workdir= (tool call) to change that:

hermes cron create "every 1d at 09:00" \
  "Audit open PRs, summarize CI health, and post to #eng" \
  --workdir /home/me/projects/acme

cronjob(
    action="create",
    schedule="every 1d at 09:00",
    workdir="/home/me/projects/acme",
    prompt="Audit open PRs, summarize CI health, and post to #eng",
)

When workdir is set:

AGENTS.md, CLAUDE.md, and .cursorrules from that directory are injected into the system prompt (same discovery order as the interactive CLI)
terminal, read_file, write_file, patch, search_files, and execute_code all use that directory as their working directory
The path must be an absolute directory that exists — relative paths and missing directories are rejected at create / update time
Pass --workdir "" (or workdir="" via the tool) on edit to clear it and restore the old behaviour

Jobs with a workdir run sequentially on the scheduler tick, not in the parallel pool. This is deliberate: the cron worker applies the job workdir through process-global terminal state, so two workdir jobs running at the same time would corrupt each other's cwd. Workdir-less jobs still run in parallel as before.

Editing jobs

You do not need to delete and recreate jobs just to change them.

The <job_id> placeholder below (and in Lifecycle actions) also accepts the job's name (case-insensitive) — handy when you remember morning-digest but not the hex ID. An exact job ID takes precedence over name matches; if the reference is not an ID and a name matches more than one job, the command refuses and prints the candidate IDs so you can disambiguate.

Chat

/cron edit <job_id> --schedule "every 4h"
/cron edit <job_id> --prompt "Use the revised task"
/cron edit <job_id> --skill blogwatcher --skill maps
/cron edit <job_id> --remove-skill blogwatcher
/cron edit <job_id> --clear-skills

Standalone CLI

hermes cron edit <job_id> --schedule "every 4h"
hermes cron edit <job_id> --prompt "Use the revised task"
hermes cron edit <job_id> --skill blogwatcher --skill maps
hermes cron edit <job_id> --add-skill maps
hermes cron edit <job_id> --remove-skill blogwatcher
hermes cron edit <job_id> --clear-skills

Notes:

repeated --skill replaces the job's attached skill list
--add-skill appends to the existing list without replacing it
--remove-skill removes specific attached skills
--clear-skills removes all attached skills

Lifecycle actions

Cron jobs now have a fuller lifecycle than just create/remove.

Chat

/cron list
/cron pause <job_id>
/cron resume <job_id>
/cron run <job_id>
/cron remove <job_id>

Standalone CLI

hermes cron list
hermes cron pause <job_id_or_name>
hermes cron resume <job_id_or_name>
hermes cron run <job_id_or_name>
hermes cron remove <job_id_or_name>
hermes cron edit <job_id_or_name> [...flags]
hermes cron status
hermes cron tick

What they do:

pause — keep the job but stop scheduling it
resume — re-enable the job and compute the next future run
run — trigger the job on the next scheduler tick
remove — delete it entirely
edit — modify schedule, prompt, delivery, etc.

Name-based lookup. All four mutating verbs (pause, resume, run, remove, edit) plus the agent's cronjob tool now accept a job name (case-insensitive) in place of the hex ID. The agent and CLI both prefer an exact ID match if one exists; ambiguous name matches (multiple jobs sharing the same name) are refused with the full list of candidate IDs so you can pick one explicitly. Names are not unique, so this guard is load-bearing — it prevents silently mutating the wrong job when two share a name.

How it works

Cron execution is handled by the gateway daemon. The gateway ticks the scheduler every 60 seconds, running any due jobs in isolated agent sessions.

hermes gateway install     # Install as a user service
sudo hermes gateway install --system   # Linux: boot-time system service for servers
hermes gateway             # Or run in foreground

hermes cron list
hermes cron status

Gateway scheduler behavior

On each tick Hermes:

loads jobs from ~/.hermes/cron/jobs.json
checks next_run_at against the current time
starts a fresh AIAgent session for each due job
optionally injects one or more attached skills into that fresh session
runs the prompt to completion
delivers the final response
updates run metadata and the next scheduled time

A file lock at ~/.hermes/cron/.tick.lock prevents overlapping scheduler ticks from double-running the same job batch.

Delivery options

When scheduling jobs, you specify where the output goes:

Option — Description — Example
"origin" — Back to where the job was created — Default on messaging platforms
"local" — Save to local files only (~/.hermes/cron/output/) — Default on CLI
"telegram" — Telegram home channel — Uses `TELEGRAM

Points de vigilance

Vérifiez toujours la version active de Hermes Agent avant d'appliquer une commande ou une configuration.
Ne collez pas de clé API dans un chat public ou dans une page visible.
Gardez les secrets dans les fichiers ou gestionnaires prévus pour cela.
Si une fonctionnalité dépend d'un provider, d'un plugin ou d'une plateforme de messagerie, vérifiez que le composant est bien activé dans votre profil.
Pour une installation de production, testez d'abord le flux complet sur une machine ou un profil isolé.

Exemple de parcours logique

Lire la page courante pour comprendre hermes agent automatisation.
Ouvrir le hub parent du cluster automatisation.
Passer ensuite aux pages complémentaires proposées dans « À lire ensuite ».
Revenir à la documentation officielle si vous avez besoin du détail exact ou d'une commande récemment modifiée.

FAQ rapide

Cette page remplace-t-elle la documentation officielle ?

Non. Elle sert de guide francophone structuré. Le lien vers la source officielle est disponible en bas de page.

Les commandes sont-elles garanties à jour ?

Elles sont basées sur la documentation officielle récupérée au moment de la génération. Pour un usage critique, vérifiez toujours la page officielle liée en bas.

Pourquoi autant de liens internes ?

Hermes Agent est un système modulaire. L'installation, les providers, les outils, la mémoire, les skills, la sécurité et les plateformes se répondent. Le maillage interne aide à suivre ce chemin sans tomber sur des pages orphelines.

Comment lire cette page efficacement

Commencez par identifier votre situation : installation locale, usage serveur, configuration d'un provider, connexion à une plateforme, automatisation ou usage développeur. Hermes Agent est modulaire : une fonctionnalité dépend souvent d'un autre bloc. Par exemple, une automatisation cron devient réellement utile quand le modèle, les outils et le canal de livraison sont déjà configurés.

Pour éviter les erreurs, avancez toujours dans cet ordre : vérifier le prérequis, appliquer la commande ou la configuration, relancer une session si nécessaire, puis tester avec une action simple. Si le résultat ne correspond pas à ce qui est attendu, revenez à la page officielle liée en bas et comparez la version de votre installation avec la documentation actuelle.

Bonnes pratiques

Garder une configuration minimale tant que le premier test n'est pas validé.
Ajouter les outils et plateformes progressivement.
Séparer les profils si plusieurs usages doivent cohabiter.
Documenter les procédures répétées dans des skills plutôt que dans de longs prompts.
Vérifier les droits, tokens et scopes avant d'accuser le modèle ou Hermes Agent.
Relancer la session après un changement de configuration important.

Erreurs fréquentes

La première erreur consiste à activer trop de choses trop tôt. Plus la configuration initiale est large, plus le diagnostic devient difficile. La deuxième erreur consiste à confondre un problème de provider avec un problème Hermes : si le modèle ne répond pas, vérifiez d'abord l'authentification, la clé API, le nom du modèle et le provider sélectionné. La troisième erreur consiste à oublier que certains changements ne s'appliquent qu'à une nouvelle session ou après redémarrage du gateway.

Suite recommandée

Après cette page, ouvrez les liens internes proposés dans la section « À lire ensuite ». Ils ont été choisis pour suivre une progression logique dans le même site, sans envoyer vers l'autre domaine.

Automatiser avec Hermes Agent