Si vous suivez l’écosystème des agents IA, vous avez probablement déjà vu la mascotte d’OpenClaw : un homard 🦞. Derrière se cache Lobster, un moteur de workflow déterministe. Son concept est simple : écrire des tâches multi-étapes sous forme de pipelines pausables, reprises et dotées de points de validation explicites, pour que le LLM n’ait pas à replanifier à chaque exécution.

De l’autre côté, Hermes Agent de Nous Research est un agent de raisonnement autonome. Il réfléchit, appelle des outils, itère et écrit même ses propres skills. À première vue, ils sont opposés : l’un veut des pipelines rigides, l’autre de l’improvisation.

Mais dans le domaine de l’automatisation des tâches répétitives, Hermes peut couvrir bon nombre des cas d’usage les plus forts de Lobster. Non en étant plus rigide, mais en étant plus flexible de trois manières spécifiques.

---

1. Mode cron no-agent : des tâches planifiées vraiment sans LLM

La promesse centrale de Lobster est de sortir l’orchestration du LLM. Au lieu que le modèle enchaîne les outils en de nombreux allers-retours, un appel Lobster exécute un pipeline prédéfini et renvoie un résultat structuré.

Hermes a un équivalent direct : les tâches planifiées (Cron) en mode no-agent.

hermes cron create "every 5m"   --no-agent   --script memory-watchdog.sh   --deliver telegram   --name "memory-watchdog"

Les règles sont simples :

• Le script s’exécute selon la planification.
• Sa sortie standard est livrée textuellement.
• Une sortie vide signifie un cycle silencieux.
• Une sortie non nulle ou un timeout déclenchent une alerte.

C’est essentiellement la même idée qu’un pipeline Lobster : déterministe, auditable et peu coûteux. Mais Hermes ne vous demande pas d’apprendre un nouveau DSL. Vous écrivez des scripts shell ou Python ordinaires, et Hermes gère la planification, la livraison et la gestion des erreurs.

Pour la surveillance disque, les heartbeats d’API, les notifications CI et l’extraction de données, le cron no-agent d’Hermes est plus léger que la maintenance d’un fichier .lobster.

---

2. Skills : des workflows répétables comme des cartes réutilisables

Lobster encode les pipelines dans des fichiers .lobster. Hermes encode les workflows répétables et les connaissances dans des Skills.

Les skills sont utiles car elles :

• Se chargent à la demande avec une divulgation progressive — sans gonfler le contexte.
• Sont gérées par l’agent — Hermes peut écrire et mettre à jour des skills après avoir terminé une tâche.
• Respectent la norme agentskills.io, ce qui permet de les partager entre équipes et communautés.
• Fonctionnent comme des commandes slash telles que /deploy-k8s ou /daily-report.

Par exemple, un workflow de “vérification de l’état du serveur et envoi d’un résumé” peut devenir une skill :

---
# k8s-health-check/SKILL.md
---

## Utilisation
/k8s-health-check

## Étapes
1. Exécuter `kubectl get nodes --all-namespaces`.
2. Vérifier les statuts anormaux des pods.
3. Utiliser web_search pour trouver des informations pertinentes sur les incidents.
4. Générer un résumé Markdown et l'envoyer sur Telegram.

Une fois écrite, l’appel /k8s-health-check est aussi stable qu’un pipeline Lobster. Mais vous n’avez pas eu à définir une chaîne d’outils JSON ni des points de validation explicites. Hermes dispose déjà de garde-fous au moment de l’exécution pour les commandes dangereuses et les écritures mémoire, donc les validations se font dans la couche d’outils plutôt que dans le langage de workflow.

---

3. Tool Search + MCP : des workflows qui ne codent pas les outils en dur

L’inconvénient du déterminisme de Lobster est sa rigidité. Une fois le pipeline défini, les étapes sont figées. Si la forme des entrées change ou qu’un outil est mis à jour, le workflow peut devoir être réécrit.

Hermes résout cela avec Tool Search.

Lorsque de nombreux serveurs MCP ou outils plugin sont attachés, Hermes ne déverse pas tous les schémas dans la fenêtre de contexte. À la place, il expose trois outils de pont :

• tool_search(query) — recherche dans le catalogue d’outils différés.
• tool_describe(name) — charge le schéma complet d’un outil à la demande.
• tool_call(name, arguments) — invoque l’outil cible.

Un tour typique ressemble à ceci :

Model: tool_search("create a GitHub issue")
→ { matches: [{ name: "mcp_github_create_issue" }, ...] }
Model: tool_describe("mcp_github_create_issue")
→ { parameters: { ... } }
Model: tool_call("mcp_github_create_issue", { title: "...", body: "..." })
→ { ok: true, issue_number: 42 }

Cela signifie que les workflows Hermes ne sont pas codés en dur. Ils peuvent découvrir l’outil approprié au moment de l’exécution. Les serveurs MCP peuvent être remplacés ou mis à jour sans réécrire la skill. Cela rend Hermes plus durable dans des environnements où les exigences changent rapidement et où l’écosystème d’outils est dense.

---

Mais Hermes n’essaye pas vraiment de “tuer” Lobster

Honnêtement, les deux outils jouent des rôles différents :

Dimension	Lobster	Hermes Agent
Philosophie centrale	Déterministe, prévisible, auditable	Autonome, flexible, itératif
Meilleures tâches	Flux répétitifs, critiques, à étapes fixes	Tâches exploratoires, complexes, changeantes
Courbe d’apprentissage	Apprendre le DSL .lobster	Langage naturel + appels d’outils
Modèle d’approbation	Intégré au workflow	Intégré à la couche d’outils
Reprise	jeton de reprise	checkpoint + réessai cron

L’affirmation juste est donc : Hermes offre une réponse différente au même problème des tâches répétitives. Il ne vous demande pas d’apprendre un langage de workflow. Vous pouvez décrire, planifier et réutiliser l’automatisation quotidienne — surveillance, rapports, scraping, alertes — dans le même agent que vous utilisez déjà pour des travaux ouverts.

Si vos flux Lobster sont extrêmement stables et fortement auditables, Lobster reste un bon choix. Mais si vous voulez un seul agent capable à la fois d’improviser et d’automatiser l’ennuyeux, le combo de trois coups d’Hermes vaut la peine d’être essayé.

---

En pratique : transformez le triage d’e-mails de Lobster en flux Hermes

La documentation de Lobster utilise le triage d’e-mails comme exemple classique. Voici comment le répliquer dans Hermes.

1. Déclencher avec cron (avec ou sans LLM)

# Entièrement sans LLM : le script gère catégorisation et brouillons
hermes cron create "every 1h"   --no-agent   --script email-triage.sh   --deliver telegram

# Ou avec LLM : laisser Hermes lire et résumer les e-mails
hermes cron create "every 1h"   --skill email-triage   --prompt "Check unread emails, categorize them, draft replies, and ask for approval before sending."

2. Coder le flux comme skill

---
# email-triage/SKILL.md
---

## Déclencheur
/email-triage

## Flux
1. Utiliser l'outil `gmail` pour lister les e-mails non lus.
2. Catégoriser par objet et expéditeur : urgent / newsletter / needs-reply / ignore.
3. Rédiger des réponses pour les e-mails qui en ont besoin.
4. Envoyer la liste des brouillons à l'utilisateur et attendre confirmation avant l'envoi.

3. Utiliser Tool Search pour s’adapter sans réécrire

Si vous passez plus tard de Gmail à Outlook ou aux notifications Slack, il suffit de mettre à jour la configuration MCP. La skill n’a pas besoin d’être modifiée, car les appels d’outils sont résolus au moment de l’exécution via recherche et description.

---

Conclusion

Hermes Agent peut-il vraiment tuer le homard ?

Au sens strict, non — ce sont des outils de types différents. Mais sur la voie de l’automatisation des tâches répétitives, le mode cron no-agent, les Skills et Tool Search d’Hermes couvrent déjà la majorité des cas d’usage communs de Lobster. Et cela avec moins de configuration, moins d’apprentissage de DSL et plus de langage naturel.

Si vous en avez assez d’écrire des scripts de workflow pour chaque tâche récurrente, essayez le combo de trois coups d’Hermes. Vous constaterez peut-être que le homard peut se détendre un peu.