Profils et delegation dans Hermes Agent : isolation, sous-agents et orchestration

Introduction

Hermes Agent n'est pas un agent unique : c'est une plateforme multi-agents. Vous pouvez creer plusieurs profils isoles, chacun avec sa propre configuration, ses propres competences (skills), sa propre memoire et ses propres secrets. Vous pouvez ensuite deleguer des sous-taches a des sous-agents ephemeres, ou orchestrer des profils persistants via le systeme Kanban.

Cette page couvre l'ensemble du cycle de vie multi-agents : creation et clonage de profils, delegation de sous-taches, differences entre delegation courte et taches Kanban durables, transmission de contexte, limitation de la concurrence, verification du travail retourne, et prevention des conflits de fichiers.

Les profils : des agents isoles dans un meme Hermes

Qu'est-ce qu'un profil ?

Un profil est une instance independante de Hermes Agent, stockee dans ~/.hermes/profiles/<nom>/. Chaque profil possede sa propre arborescence complete :

~/.hermes/profiles/monprofil/
├── config.yaml     # Configuration du profil
├── .env            # Secrets (cles API)
├── auth.json       # Jetons OAuth
├── SOUL.md         # Personnalite de l'agent
├── memories/       # Memoire persistante (MEMORY.md, USER.md)
├── skills/         # Skills installees
├── cron/           # Taches planifiees
├── sessions/       # Historique des conversations
├── state.db        # Base de sessions (SQLite + FTS5)
└── logs/           # Journaux

Le profil default correspond au repertoire ~/.hermes/ lui-meme. Tous les autres profils vivent dans ~/.hermes/profiles/.

Commandes essentielles

hermes profile list                  # Lister tous les profils
hermes profile create <nom>          # Creer un profil vierge
hermes profile use <nom>             # Activer un profil
hermes profile show <nom>            # Afficher les details d'un profil
hermes profile delete <nom>          # Supprimer un profil
hermes profile rename <ancien> <nouveau>  # Renommer un profil

Pour lancer une session avec un profil specifique sans changer le profil actif par defaut :

hermes -p <nom>                      # Option globale --profile
hermes chat -p <nom> -q "Question"   # One-shot avec un profil specifique

Chaque profil cree automatiquement un alias shell dans ~/.local/bin/<nom> qui equivaut a hermes -p <nom>.

Questions couvertes

q-111: Comment creer plusieurs profils isoles dans Hermes Agent ?

Utilisez la commande hermes profile create. Quatre modes de creation sont disponibles :

Profil vierge (aucun heritage) :

hermes profile create dev

Cree un profil dev avec une configuration minimale. Vous devrez configurer le modele, les toolsets et les secrets manuellement.

Clonage partiel (config, skills, SOUL.md) :

hermes profile create travail --clone

Copie config.yaml, .env, SOUL.md et les skills du profil actif. Les sessions, la memoire et l'historique ne sont pas copies.

Clonage complet (tout sauf l'historique) :

hermes profile create backup --clone-all

Copie la configuration, les skills, la memoire, le cron et les plugins. Exclut les sessions, state.db, les sauvegardes et les checkpoints.

Clonage depuis un profil specifique :

hermes profile create dev2 --clone-from dev
hermes profile create dev2-full --clone-from dev --clone-all

Utile pour dupliquer un profil existant sans avoir a le rendre actif d'abord.

Profil sans skills (orchestrateur leger) :

hermes profile create sandbox --no-skills

Cree un profil sans aucune skill prechargee. Utile pour les profils d'orchestration ou les environnements de test qui ne doivent pas heriter du catalogue complet.

Apres creation, activez le profil avec hermes profile use <nom>, puis configurez-le avec hermes setup ou hermes model.

q-112: Quelles donnees sont separees entre les profils Hermes Agent ?

Chaque profil est totalement isole. Voici ce qui est separe entre les profils :

Ce qui est partage entre profils :

• Le binaire hermes lui-meme (une seule installation)
• La base Kanban (~/.hermes/kanban.db) -- c'est le mecanisme de collaboration inter-profils
• Les skins/themes (dans ~/.hermes/skins/)
• Les pets/mascottes (dans ~/.hermes/pets/)

Cette isolation permet des cas d'usage varies : un profil travail avec des skills de developpement et un modele puissant, un profil personnel avec des skills creatives et un modele economique, un profil veille avec des taches cron de surveillance.

q-113: Comment cloner un profil sans copier ses secrets ?

La commande hermes profile create --clone copie config.yaml, .env, SOUL.md et les skills, mais pas auth.json (les jetons OAuth). C'est le comportement par defaut du clonage partiel.

Si vous voulez un clonage encore plus strict qui exclut aussi .env :

1. Creez un profil vierge : hermes profile create nouveau
2. Copiez manuellement config.yaml et SOUL.md depuis le profil source
3. Configurez les secrets separement avec hermes -p nouveau setup

Pour un clonage complet sans aucun secret :

# 1. Creer un profil vierge
hermes profile create nouveau

# 2. Copier config.yaml et SOUL.md (pas .env, pas auth.json)
cp ~/.hermes/profiles/source/config.yaml ~/.hermes/profiles/nouveau/
cp ~/.hermes/profiles/source/SOUL.md ~/.hermes/profiles/nouveau/

# 3. Copier les skills (pas de secrets dedans)
cp -r ~/.hermes/profiles/source/skills/* ~/.hermes/profiles/nouveau/skills/

# 4. Configurer les secrets du nouveau profil
hermes -p nouveau setup

Note de securite : auth.json n'est jamais copie par --clone ni par --clone-all. Les distributions de profils (hermes profile install) excluent egalement auth.json et .env : le destinataire doit fournir ses propres secrets.

q-114: Comment deleguer une sous-tache a un autre agent ?

La delegation dans Hermes Agent passe par l'outil delegate_task, que l'agent appelle automatiquement quand il juge qu'une sous-tache justifie un contexte isole.

L'utilisateur n'a rien a faire : l'agent decide lui-meme de deleguer. Vous pouvez simplement demander a l'agent de traiter plusieurs taches en parallele, et il utilisera delegate_task si necessaire.

Tache unique :

"Debug pourquoi les tests echouent dans test_foo.py"

L'agent appelle delegate_task(goal="Debug why tests fail", context="Error: assertion in test_foo.py line 42").

Lot parallele (jusqu'a 3 taches simultanees par defaut) :

"Recherche les sujets A, B et C en parallele, puis synthetise"

L'agent appelle delegate_task(tasks=[{goal: "Research A", ...}, {goal: "Research B", ...}, {goal: "Research C", ...}]).

Ce qui se passe techniquement :

1. Le parent appelle delegate_task avec un goal (objectif) et un context (contexte)
2. Hermes cree un sous-agent avec une conversation vierge, ses propres sessions terminal, et les toolsets herites du parent
3. Le sous-agent travaille de maniere independante
4. Seul le resume final du sous-agent est reinjecte dans le contexte du parent
5. Pour les lots, les resultats sont tries par index de tache (ordre d'entree), pas par ordre d'arrivee

Delegation en arriere-plan : les appels de niveau superieur (hors sous-agents) s'executent automatiquement en arriere-plan. Hermes retourne un handle immediatement, et le resultat est poste comme un nouveau message quand le sous-agent termine.

Outils bloques pour les sous-agents : les sous-agents ne peuvent pas appeler delegate_task (sauf role orchestrateur), clarify (interaction utilisateur), memory (ecriture memoire), send_message (effets de bord inter-plateformes), ni cronjob (planification).

q-115: Quelle difference entre delegation courte et tache Kanban durable ?

Hermes Agent propose deux mecanismes de delegation, complementaires mais fondamentalement differents :

Quand utiliser delegate_task : le parent a besoin d'une reponse courte avant de continuer, pas d'intervention humaine, le resultat retourne dans le contexte du parent. Exemples : recherche parallele, revue de code, refactoring isole.

Quand utiliser Kanban : le travail traverse les frontieres d'agents, doit survivre aux redemarrages, peut necessiter une intervention humaine, peut etre repris par un role different, ou doit etre decouvrable a posteriori. Exemples : pipeline de recherche avec relecture humaine, taches planifiees recurrentes, assistants persistants specialises.

Ils coexistent : un worker Kanban peut appeler delegate_task en interne pendant son execution.

Le systeme Kanban est pilote via hermes kanban <verbe> en CLI, ou via le toolset kanban_* pour les agents. La base de donnees est ~/.hermes/kanban.db, partagee entre tous les profils. Voir la documentation Kanban officielle pour le detail complet.

q-116: Comment limiter le nombre de sous-agents simultanes ?

La limite de sous-agents simultanes est controlee par la cle de configuration delegation.max_concurrent_children. La valeur par defaut est 3, avec un plancher de 1 et aucun plafond dur.

Modifier la limite :

hermes config set delegation.max_concurrent_children 5

Ou dans config.yaml :

delegation:
  max_concurrent_children: 5

Ou via variable d'environnement :

export DELEGATION_MAX_CONCURRENT_CHILDREN=5

Comportement en cas de depassement : si l'agent tente de lancer plus de taches que la limite, l'appel retourne une erreur explicite : "Too many tasks: N provided, but max_concurrent_children is M.". L'agent voit cette erreur et reessaie generalement avec moins de taches. Il n'y a pas de troncature silencieuse.

Note importante : max_concurrent_children est un plafond par parent, pas un plafond global. Deux parents differents peuvent chacun lancer max_concurrent_children workers simultanement.

Profondeur d'arbre : la delegation est plate par defaut (delegation.max_spawn_depth: 1). Les sous-agents ne peuvent pas deleguer a leur tour. Pour autoriser la delegation imbriquee :

delegation:
  max_spawn_depth: 2    # Les orchestrateurs peuvent creer des sous-agents feuilles
  orchestrator_enabled: true

Avec max_spawn_depth: 3 et max_concurrent_children: 3, l'arbre peut atteindre 3x3x3 = 27 agents feuilles simultanes. Chaque niveau supplementaire multiplie les couts : augmentez max_spawn_depth intentionnellement.

Avertissement de cout : quand max_concurrent_children depasse 10, Hermes log un avertissement unique : chaque sous-agent consomme des tokens independamment. Ce n'est pas un blocage, juste un rappel que les couts sont lineaires.

q-117: Comment transmettre le bon contexte a un sous-agent ?

Regle fondamentale : les sous-agents ne savent rien. Ils demarrent avec une conversation completement vierge. Ils n'ont aucune connaissance de l'historique de conversation du parent, des appels d'outils precedents, ni de tout ce qui a ete discute avant la delegation.

Le parent doit transmettre tout le contexte necessaire dans les champs goal et context de l'appel delegate_task.

Mauvais exemple (le sous-agent n'a aucune idee de ce qu'est "l'erreur") :

"Repare l'erreur"

Bon exemple (le sous-agent a tout ce dont il a besoin) :

Goal: "Corriger le TypeError dans api/handlers.py"
Context: "Le fichier api/handlers.py a un TypeError ligne 47 :
'NoneType' object has no attribute 'get'.
La fonction process_request() recoit un dict de parse_body(),
mais parse_body() retourne None quand Content-Type est absent.
Le projet est dans /home/user/myproject, Python 3.11."

Ce que le sous-agent recoit : un prompt systeme cible construit a partir du goal et du context, lui demandant de completer la tache et de fournir un resume structure de ce qu'il a fait, ce qu'il a trouve, les fichiers modifies, et les problemes rencontres.

Bonnes pratiques pour le contexte :

• Inclure le chemin absolu du projet ou des fichiers concernes
• Preciser la version du langage ou de l'environnement
• Lister les fichiers specifiques a examiner ou modifier
• Decrire le comportement attendu et le comportement observe
• Mentionner les contraintes (ne pas toucher aux tests, preserver l'API publique, etc.)
• Si le sous-agent doit executer des tests, indiquer la commande exacte (ex: pytest tests/auth/)

Ce que le sous-agent herite automatiquement :

• Les toolsets actives du parent (le modele ne peut pas les elargir)
• La cle API, la configuration du provider et le pool de credentials du parent
• L'outil execute_code (appels d'outils programmatiques)

Ce que le sous-agent n'a pas : delegate_task (sauf role orchestrateur), clarify, memory, send_message, cronjob.

q-118: Comment orchestrer plusieurs profils avec des dependances ?

L'orchestration multi-profils avec dependances passe par le systeme Kanban, qui offre un tableau de taches durable partage entre tous les profils.

Principe : chaque profil est un worker specialise avec une description de ses competences. Le dispatcher Kanban attribue les taches aux profils appropries, et les taches peuvent etre liees entre elles pour exprimer des dependances.

Mise en place :

# 1. Initialiser le tableau Kanban
hermes kanban init

# 2. Creer des profils specialises avec descriptions
hermes profile create chercheur --clone
hermes -p chercheur profile describe --text "Specialiste en recherche documentaire et analyse de sources primaires"

hermes profile create redacteur --clone
hermes -p redacteur profile describe --text "Redacteur technique, synthetise les recherches en contenu structure"

hermes profile create relecteur --clone
hermes -p relecteur profile describe --text "Relecture editoriale, verification des faits et de la qualite"

# 3. Creer des taches avec dependances
hermes kanban create "Rechercher les dernieres avancees en IA agentique" --board default
# -> Retourne l'ID de la tache, ex: task-001

hermes kanban create "Rediger un article de synthese sur l'IA agentique" --board default
# -> task-002

hermes kanban create "Relire et valider l'article de synthese" --board default
# -> task-003

# 4. Lier les taches (task-002 depend de task-001, task-003 depend de task-002)
hermes kanban link task-001 task-002
hermes kanban link task-002 task-003

Fonctionnement du dispatcher :

1. Le dispatcher tourne dans la gateway (kanban.dispatch_in_gateway: true par defaut)
2. Il promeut les taches pretes (dependances satisfaites) et les attribue aux profils disponibles
3. Chaque worker recoit HERMES_KANBAN_TASK et HERMES_KANBAN_BOARD dans son environnement
4. Le worker utilise les outils kanban_show, kanban_complete, kanban_block, kanban_comment pour interagir avec le tableau
5. Quand une tache est terminee, le dispatcher verifie si des taches dependantes sont debloquees

Orchestration avec delegate_task (arbres de sous-agents) :

Pour des workflows plus legers sans Kanban, utilisez le role orchestrator :

delegation:
  max_spawn_depth: 2
  orchestrator_enabled: true

L'agent parent peut alors creer un sous-agent orchestrateur (role="orchestrator") qui delegue a son tour des sous-taches a des workers feuilles, puis synthetise leurs resultats.

Orchestration via processus independants :

Pour des missions longues (heures/jours), lancez des processus Hermes independants :

# Agent A : backend (dans un worktree isole)
hermes -w -p backend chat -q "Construire l'API REST pour la gestion utilisateurs"

# Agent B : frontend (dans un autre worktree)
hermes -w -p frontend chat -q "Construire le dashboard React pour la gestion utilisateurs"

Le flag -w (worktree) cree un worktree git isole par agent, evitant les conflits de fichiers.

q-119: Comment verifier le travail retourne par un sous-agent ?

Hermes Agent fournit plusieurs surfaces de verification du travail des sous-agents :

1. Resume structure : chaque sous-agent retourne un resume structure contenant ce qu'il a fait, ce qu'il a trouve, les fichiers modifies, et les problemes rencontres. Ce resume est injecte dans le contexte du parent.

2. Transcripts en direct (live_transcripts) : chaque delegation cree un fichier de log append-only par tache :

tail -f ~/.hermes/cache/delegation/live/<delegation_id>/task-0.log

Chaque ligne est horodatee et montre le texte de l'assistant, les snippets de raisonnement, les appels d'outils (-> tool_name({args})), les resultats d'outils, et un marqueur de statut final. Un manifest.json dans le meme repertoire decrit le lot (objectifs, nombre de taches, statut par tache).

3. Commande /agents : dans le TUI ou en CLI, /agents affiche :

• Un arbre des sous-agents en cours et recemment termines, groupes par parent
• Les cumuls de couts, tokens et fichiers modifies par branche
• L'activite en direct de chaque sous-agent (nombre d'appels API, outil en cours, dernier signal d'activite)
• Les sous-agents bloques (stalles) avec leur duree d'inactivite
• La possibilite de tuer ou mettre en pause un sous-agent specifique sans interrompre ses voisins
• L'historique tour par tour de chaque sous-agent, meme apres leur retour au parent

Exemple de sortie /agents :

Background delegations: 1 running
- deleg_ab12cd34 · running · research the delegation stall monitor
  - child 1: 4 api calls · in web_search · active 12s ago
  - child 2: 7 api calls · between turns · active 3s ago

4. Fichiers modifies : le resume du sous-agent liste explicitement les fichiers modifies. Vous pouvez verifier avec git diff ou git status dans le worktree concerne.

5. Detection de stalle : les sous-agents en arriere-plan sont surveilles par un moniteur de progression. Un sous-agent qui ne progresse plus (450s d'inactivite, 1200s si dans un outil long) est interrompu avec une fenetre de grace de 120s. S'il ne revient pas, il est finalise avec un statut stalled et des metadonnees structurees (stalled_after_quiet_seconds, stall_threshold_seconds, stall_phase).

q-120: Comment eviter que plusieurs agents modifient les memes fichiers ?

Hermes Agent propose trois mecanismes pour eviter les conflits de fichiers entre agents :

1. Mode Worktree (hermes -w) : la solution principale. Chaque agent travaille dans un worktree git isole :

# Lancer deux agents en parallele sur le meme projet
hermes -w -p agent-a chat -q "Implementer le module d'authentification"
hermes -w -p agent-b chat -q "Implementer le module de paiement"

Chaque worktree est une copie de travail independante du depot git. Les agents ne voient pas les modifications des autres. La fusion se fait via git normalement (git merge) une fois les branches pretes.

Le flag -w est recommande des que vous lancez des agents qui modifient du code en parallele.

2. Kanban avec worktrees : le systeme Kanban integre nativement les worktrees. Quand un worker Kanban prend une tache, il peut automatiquement creer un worktree dedie. Les taches liees a un meme projet utilisent des branches conventionnelles, evitant les collisions.

3. Delegation avec contexte isole : les sous-agents delegate_task ont leur propre session terminal. Ils n'operent pas dans le meme repertoire de travail que le parent, sauf si le parent le specifie explicitement dans le context. Pour eviter les conflits :

• Ne deleguez pas deux taches qui modifient le meme fichier dans le meme repertoire
• Utilisez des chemins de travail differents par sous-agent
• Preferez delegate_task pour des taches de lecture/analyse, et les worktrees pour les modifications

4. Verrous naturels : les sous-agents delegate_task sont sequentiels par defaut (le parent attend le retour). Deux sous-agents ne peuvent pas modifier le meme fichier simultanement dans le meme processus parent. Le risque de conflit n'existe que quand vous lancez des processus Hermes independants ou des workers Kanban en parallele -- et dans ces cas, le worktree est la solution.

Recommandation pratique :

Sources

• Documentation officielle Hermes Agent (https://hermes-agent.nousresearch.com/docs/)
• Page Subagent Delegation (https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation)
• Page Kanban (https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban)
• Page Configuration (https://hermes-agent.nousresearch.com/docs/user-guide/configuration)
• Reference CLI Commands (https://hermes-agent.nousresearch.com/docs/reference/cli-commands)
• Reference Profile Commands (https://hermes-agent.nousresearch.com/docs/reference/profile-commands)
• Depot NousResearch/hermes-agent (https://github.com/NousResearch/hermes-agent), commit b4f8c491

Liens internes proposes

• Configurer Hermes Agent
• Skills et plugins
• Memoire
• Outils et MCP
• Comprendre Hermes Agent
• Sources
• Methodologie