Profils Hermes ou workspaces : ne pas confondre identité d’agent et dossier de travail
Tu lances une tâche Kanban pour ton agent « rédacteur ». Tu lui files un dossier partagé. Et là, tu te demandes : est-ce que j’aurais dû créer un profil séparé pour ça ?
La question revient souvent chez ceux qui commencent à orchestrer plusieurs agents Hermes. Et la confusion est normale : les deux notions touchent à l’isolation, mais elles ne protègent pas la même chose.
Un profil, c’est l’identité d’un agent. Un workspace, c’est son plan de travail pour une tâche donnée. Les mélanger, c’est comme confondre le bureau d’un collègue avec la feuille qu’il a devant lui.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Ce qu’est un profil Hermes (et ce qu’il n’est pas)
Un profil Hermes, c’est un répertoire séparé qui contient tout l’état d’un agent : sa config, ses clés API, sa mémoire, ses sessions, ses skills, ses cron jobs et l’état de sa gateway.
Concrètement, quand tu crées un profil redacteur avec hermes profile create redacteur, tu obtiens un répertoire ~/.hermes/profiles/redacteur/ avec son propre config.yaml, son .env, son SOUL.md, et tout son état. Tu peux ensuite lancer redacteur chat comme une commande à part entière.
Chaque profil a son propre modèle, ses propres outils, sa propre mémoire. Deux profils peuvent tourner en parallèle sur la même machine sans que leurs sessions ou leurs skills se mélangent.
Ce qu’un profil ne fait pas : isoler le système de fichiers. Sur le backend local, l’agent a le même accès au disque que ton compte utilisateur. Un profil n’est pas un bac à sable. Si tu veux restreindre l’accès aux fichiers, c’est un autre mécanisme.
La doc est claire là-dessus : un profil donne à Hermes son propre répertoire d’état. Un workspace ou répertoire de travail, c’est là où les commandes terminal démarrent. Un sandbox, c’est ce qui limite l’accès au système de fichiers. Les profils ne sandboxent pas l’agent.
Ce qu’est un workspace Kanban
Quand tu crées une tâche Kanban, tu peux choisir un type de workspace. C’est le dossier dans lequel l’agent va travailler pendant l’exécution de cette tâche.
Trois options existent :
- Scratch : un dossier temporaire créé pour la tâche, nettoyé automatiquement à la fin. C’est le choix par défaut, et le bon pour la plupart des tâches isolées.
- Dir : un dossier partagé que tu désignes par un chemin absolu. Utile quand plusieurs tâches doivent travailler sur les mêmes fichiers, ou quand tu veux que le résultat reste accessible après la tâche.
- Worktree : un git worktree isolé, créé automatiquement à partir du dépôt principal. Parfait pour les tâches de code qui doivent être isolées sur une branche sans cloner tout le repo.
Le workspace, c’est le « où » de la tâche. Le profil, c’est le « qui ».
Tableau comparatif : profil vs workspace
| Critère | Profil | Workspace |
|---|---|---|
| Ce que c’est | L’identité complète d’un agent | Le dossier de travail d’une tâche |
| Ce qu’il isole | Config, clés API, mémoire, sessions, skills, gateway | Les fichiers manipulés pendant une tâche |
| Durée de vie | Permanent (tant que le profil existe) | Lié à la tâche (scratch : temporaire ; dir : persistant ; worktree : durée de la branche) |
| Quand le créer | Quand tu veux un agent avec un rôle, des outils ou une mémoire distincts | Quand tu crées une tâche Kanban (choix implicite ou explicite) |
| Sandboxing | Aucun (l’agent a le même accès disque que l’utilisateur) | Aucun (le workspace ne restreint pas l’accès aux autres dossiers) |
| Commande type | hermes profile create redacteur |
kanban_create(workspace_kind="scratch") |
Quand utiliser quoi
Crée un profil quand tu veux un agent différent
Tu as besoin d’un profil séparé quand l’agent doit avoir une identité, des outils ou une mémoire qui lui sont propres. Par exemple :
- Un agent
redacteuravec un SOUL.md orienté écriture, des skills de copywriting, et un modèle optimisé pour la rédaction. - Un agent
devavec des skills de code, un accès GitHub, et un modèle différent. - Un agent
reviewerqui ne fait que relire et valider le travail des autres.
Chaque profil a sa propre gateway, donc tu peux même exposer chaque agent sur un canal différent (Telegram, Discord, etc.) avec des tokens distincts.
Choisis un workspace quand tu veux isoler une tâche
Le workspace se choisit au moment de créer une tâche Kanban, pas avant.
- Scratch : ta tâche est autonome, elle n’a pas besoin de partager des fichiers avec d’autres tâches. C’est le cas le plus fréquent.
- Dir : plusieurs tâches doivent travailler sur le même dossier. Par exemple, une tâche de recherche qui produit des notes, puis une tâche de synthèse qui les lit.
- Worktree : ta tâche modifie du code dans un dépôt git, et tu veux une branche isolée sans affecter le travail en cours.
Les trois erreurs classiques
1. Créer un profil par projet au lieu d’un profil par rôle. Tu n’as pas besoin d’un profil projet-client-a et d’un profil projet-client-b. Tu as besoin d’un profil redacteur qui travaille sur les deux projets, chacun dans son workspace. Le profil, c’est la compétence. Le workspace, c’est le contexte.
2. Utiliser un workspace dir partagé sans gérer la concurrence. Si deux tâches écrivent dans le même dossier en parallèle, rien n’empêche les conflits. Le workspace dir donne un accès partagé, pas une coordination. Si tu as besoin que la tâche B attende que la tâche A ait fini, utilise les dépendances Kanban (parents), pas juste un dossier commun.
3. Confondre terminal.cwd et workspace. terminal.cwd dans la config d’un profil définit le répertoire de départ des commandes terminal pour ce profil. Le workspace Kanban est défini au niveau de la tâche et surcharge ce réglage pour la durée de la tâche. Ce sont deux mécanismes différents qui peuvent coexister.
Choisir la séparation avant de créer des tâches
La bonne question à te poser avant de lancer ton premier Kanban multi-agents n’est pas « quel dossier je leur donne ? ». C’est « quels rôles j’ai besoin d’isoler ? ».
Si tes agents partagent les mêmes outils, le même modèle et la même mémoire, un seul profil suffit. Tu joues sur les workspaces pour isoler les tâches.
Si tu veux qu’un agent ait une mémoire distincte, des skills différents, ou un modèle optimisé pour une tâche spécifique, crée un profil.
C’est cette séparation claire entre identité et espace de travail qui rend le pilotage d’une équipe d’agents vraiment fluide. Une fois que tu as tes profils en place, tu peux orchestrer tes tâches sans te poser la question à chaque fois. C’est exactement ce qu’on couvre dans la formation Hermes Agent : poser les bonnes fondations avant de lancer tes premiers workflows multi-agents.
Si tu veux comprendre comment piloter une équipe d’agents avec Kanban, j’ai écrit un article complet sur le pilotage d’équipe d’agents IA avec Hermes Kanban. Et si tu veux apprendre à configurer tout ça correctement du premier coup, tu peux faire une demande d’accès à la formation Hermes Agent.