Quand utiliser Hermes profiles plutôt qu'un assistant géant
Hermes profiles séparent mémoire, sessions, skills, identité, état cron et routes gateway afin que les rôles IA récurrents restent ciblés, auditables et utiles.
Hermes profiles servent à séparer l'état, pas à jouer un rôle. Utilisez un profile lorsqu'un rôle IA récurrent a besoin de sa propre mémoire, de ses propres sessions, de skills, d'une identité SOUL.md, d'une propriété cron ou d'une route gateway.
Un assistant peut répondre à beaucoup de questions. Il ne devrait pas devenir en même temps le domicile permanent du jugement de recherche, du goût rédactionnel, des journaux shell, des règles de calendrier, des tâches planifiées et du routage des messages.
Le mode d'échec n'est pas un prompt faible. Le mode d'échec est l'état partagé. Ce guide montre quand un Hermes profile mérite d'exister, comment en créer un à partir d'une configuration fonctionnelle et comment empêcher une petite équipe de profiles de redevenir un généraliste bruyant.
Créez un profile lorsque l'état doit rester séparé. La mémoire, les sessions, les outils, cron et les routes gateway sont des raisons plus fortes que le ton.
Utilisez les prompts pour un comportement ponctuel, les skills pour une procédure réutilisable et les profiles pour des rôles durables. Mélanger ces couches crée une dette de contexte.
Commencez par un coordinateur et deux spécialistes. Ajoutez Scout pour la recherche, Scribe pour l'écriture et Forge pour le build/debug uniquement lorsque la frontière est réelle.
Rédigez SOUL.md comme une fiche de poste. Il doit définir des standards, des valeurs par défaut et des règles de refus, pas une personnalité vague.
Définissez les transmissions avant d'ajouter d'autres agents. Une équipe de profiles n'est utile que lorsque les sorties passent proprement d'un rôle à l'autre.
Si votre équipe a déjà réparti le travail IA entre prompts, chats, scripts et tâches planifiées, webvise peut aider à cartographier la première frontière de profile propre avant que le système devienne plus difficile à auditer.
L'erreur: un assistant fait cinq métiers
Le chemin habituel commence raisonnablement. Vous demandez à un assistant de rechercher un marché, rédiger un article, déboguer un script, résumer une réunion et surveiller un calendrier. Rien ne casse le premier jour.
À la troisième semaine, chaque workflow laisse des résidus. La recherche enseigne des règles de sources, l'écriture enseigne le ton, les sessions de debug stockent les commandes échouées et le travail de calendrier ajoute des hypothèses de planification. La tâche suivante doit trier tout cela.
C'est une dette de contexte. L'assistant n'est pas confus parce qu'il lui manque une instruction supplémentaire. Il est confus parce que des travaux sans rapport partagent désormais mémoire, sessions, outils et valeurs par défaut.
Hermes profiles réparent la frontière. Ils permettent à un rôle de porter l'état dont il a besoin sans obliger tous les autres rôles à en hériter.
Les profiles sont des environnements isolés, pas des costumes
Une persona change la manière dont un assistant parle. Un Hermes profile change ce que l'assistant porte, mémorise, planifie et ce à quoi il se connecte.
Hermes 0.9.0 a introduit les profiles comme environnements d'agents isolés. Un profile peut séparer configuration, sessions, mémoire, skills, personnalité, état cron et état gateway. Cela en fait une frontière d'exécution, pas un style rédactionnel.
| Couche | Ce que la séparation évite |
|---|---|
| Mémoire | Règles de recherche, hypothèses récurrentes et anciennes décisions qui se propagent dans un travail sans rapport |
| Sessions | Brouillons, journaux shell, fils stratégiques et notes de calendrier qui s'effondrent en une seule chronologie |
| Skills | Chaque rôle scanne ou charge des outils dont il n'a pas besoin |
| Identité | Une voix générique qui prétend être chercheur, éditeur, opérateur et ingénieur |
| Cron state | Plusieurs tâches planifiées tentent de posséder le même résultat |
| Gateway state | Le mauvais rôle répond à la mauvaise route Telegram ou message |
Voici le test principal: si deux rôles ne devraient pas mémoriser les mêmes erreurs, hypothèses ou travaux inachevés, ils ne devraient probablement pas être le même profile.
Profile, prompt, skill, AGENTS.md ou SOUL.md?
La plupart des configurations d'agents désordonnées viennent de l'utilisation d'une seule couche pour chaque problème. Les profiles ne sont pas la réponse à chaque besoin de personnalisation.
| Besoin | Utilisez cette couche |
|---|---|
| Changer le comportement pour une tâche | Prompt |
| Réutiliser une procédure entre plusieurs tâches | Skill |
| Donner les chemins de projet, commandes et conventions | AGENTS.md |
| Définir une identité de rôle durable et des standards | SOUL.md |
| Séparer mémoire, sessions, skills, cron ou état gateway | Profile |
| Coordonner plusieurs profiles et transmissions | TEAM.md |
Ne créez pas de profiles pour une ambiance. Créez les lorsque le rôle possède un état qui dégraderait un autre rôle.
Quand un profile mérite d'exister
Un bon profile gagne sa place en réduisant le bruit. S'il ne fait que changer le nom dans le prompt du terminal, supprimez le ou transformez l'instruction en skill.
| Créez un profile lorsque | N'en créez pas lorsque |
|---|---|
| Le rôle se répète chaque semaine ou chaque jour | La tâche est ponctuelle |
| Il a besoin d'une mémoire qui ne doit pas se répandre dans d'autres travaux | Seul le ton change |
| Il possède un gateway différent ou une tâche planifiée différente | Il utilise les mêmes outils, le même contexte et le même contrat de sortie |
| Il a un niveau de risque ou une frontière d'autorisation différente | Vous ne pouvez pas décrire ce qu'il doit produire |
| Il transmet du travail à un autre profile | Aucune transmission ou porte qualité n'existe |
La règle la plus propre est simple: un profile devrait s'améliorer dans un métier sans rendre les autres métiers plus bruyants.
Une petite équipe Hermes profile
Commencez par des rôles, pas par des noms de personnages empruntés. Gardez Hermes comme coordinateur. Ajoutez Scout pour la recherche, Scribe pour l'écriture et Forge pour le build/debug uniquement lorsque chaque rôle a une vraie frontière.
| Profile | Responsabilité | Doit produire | Ne doit pas produire |
|---|---|---|---|
| Hermes | Planifier, router, séquencer et vérifier | Découpage de tâche, délégation, synthèse finale, porte qualité | Dumps de recherche bruts ou changements de code non relus |
| Scout | Enquêter, comparer et vérifier | Affirmations avec sources, dates, confiance et réserves | Copie polie qui cache l'incertitude |
| Scribe | Transformer du matériau vérifié en communication | Brouillons, éditions, structure, adéquation à l'audience | Affirmations non étayées ou preuves inventées |
| Forge | Construire, déboguer, tester et rapporter | Diffs, commandes exécutées, résultats de tests, risques résiduels | Prose stratégique sans preuve d'implémentation |
Les noms sont des espaces réservés. La frontière est le produit. Renommez les profiles si vous le souhaitez, mais gardez les métiers séparés.
Un premier pilote utile ne comporte que deux profiles: Hermes coordonne, Scout vérifie. Une fois que Scout renvoie de façon fiable des affirmations sourcées, ajoutez Scribe pour transformer ces affirmations en texte. Ajoutez Forge seulement lorsque le travail d'implémentation commence à polluer le reste de l'assistant.
Créer des profiles à partir d'une base fonctionnelle
Ne construisez pas chaque spécialiste à partir de zéro. Assurez vous d'abord que la configuration Hermes par défaut fonctionne: provider, modèle, clés API, outils et usage normal du terminal.
Créer un profile de recherche: `hermes profile create scout --clone`
Créer un profile d'écriture: `hermes profile create scribe --clone`
Créer un profile d'ingénierie: `hermes profile create forge --clone`
Vérifier la liste: `hermes profile list`
Exécuter directement un spécialiste: `hermes -p scout`, `hermes -p scribe` ou `hermes -p forge`
Utilisez `--clone` lorsque la configuration de base est saine. Elle devrait copier la configuration utile tandis que le nouveau profile conserve une mémoire et un historique de sessions isolés.
Si vous ne pouvez pas expliquer quel état le nouveau profile possède, arrêtez. Vous avez probablement plutôt besoin d'un prompt, d'un skill ou d'une entrée AGENTS.md.
Rédigez SOUL.md comme une fiche de poste
SOUL.md est l'endroit où un profile devient un vrai rôle. Il doit définir une identité durable: valeurs par défaut, standards, goût, règles de refus et style de décision.
AGENTS.md est différent. Il doit contenir le contexte du projet: chemins du dépôt, commandes, conventions, processus de revue et règles d'outils. Mélanger identité et contexte projet est la manière dont un spécialiste propre redevient un généraliste vague.
| Fichier | À mettre ici | À garder dehors |
|---|---|---|
| SOUL.md | Identité de rôle, standards, règles de refus, style de décision | Notes temporaires de dépôt ou instructions client |
| AGENTS.md | Chemins de projet, commandes, conventions, règles de workflow | Toute la personnalité du profile |
| TEAM.md | Liste, transmissions, règles d'escalade, plafonds de politique | Chaque instruction privée de chaque profile |
Scout SOUL.md: vérifier avant de résumer, séparer preuve et interprétation, inclure les dates, signaler l'incertitude.
Scribe SOUL.md: écrire pour le lecteur cible, préserver les frontières de preuve, améliorer la structure avant le style, demander lorsque le soutien manque.
Forge SOUL.md: reproduire avant de changer, effectuer la plus petite correction sûre, lancer la vérification pertinente, rapporter les fichiers touchés et le risque restant.
Définir les transmissions avant d'ajouter plus de profiles
Les profiles ne devraient pas simplement rester côte à côte. Ils ont besoin de contrats. Une transmission n'est pas un message de chat. C'est une porte qualité entre rôles.
| Transmission | Charge utile requise | Rejeter lorsque |
|---|---|---|
| Scout to Scribe | Affirmation, URL source, date, confiance, réserve | L'entrée n'est composée que d'extraits bruts |
| Scribe to Hermes | Brouillon, lecteur visé, hypothèses, questions non résolues | Le texte cache des preuves faibles |
| Forge to Hermes | Résumé de changement, fichiers touchés, commandes exécutées, tests, risque résiduel | Le rapport dit corrigé sans preuve |
Si Scout remet à Scribe une pile de notes, Scribe devient le chercheur. Si Forge dit corrigé sans commandes ni tests, Hermes ne peut pas vérifier le travail. Les mauvaises transmissions transforment une équipe de profiles en relais de suppositions.
Si vous hésitez entre faire d'une frontière un profile, un skill ou une règle de projet, webvise peut cartographier le modèle de transmission et de propriété avant que vous encodiez la mauvaise couche.
L'état gateway et cron fait partie de l'architecture
Les profiles deviennent beaucoup plus utiles lorsque les messages et les tâches planifiées entrent dans le système. Une route Telegram, un webhook ou une tâche cron n'est pas seulement un déclencheur. C'est une propriété.
| Route ou planification | Owner profile | Sortie attendue |
|---|---|---|
| Demande Telegram générale | Hermes | Clarifier l'objectif, router le travail, renvoyer la réponse finale |
| Demande de revue de source | Scout | Affirmations classées avec sources et réserves |
| Demande de rédaction | Scribe | Brouillon structuré ou passe d'édition |
| Alerte build ou debug | Forge | Reproduction, diff, résultat de test, note de risque |
| Audit hebdomadaire des profiles | Hermes | Revue de dérive, mémoire, cron et transmission |
Si chaque tâche planifiée reste sous le profile par défaut, l'équipe se replie lentement vers un seul assistant. Placez la tâche sous le rôle qui possède le résultat, puis routez les résumés vers Hermes.
La configuration de la première semaine et l'audit jour-30
La première semaine ne consiste pas à construire une grande équipe. Elle consiste à prouver une frontière propre.
Choisissez le workflow qui crée le plus de pollution de contexte.
Créez un profile spécialiste avec `--clone`.
Rédigez un court SOUL.md pour ce rôle.
Définissez une transmission d'entrée et une transmission de sortie.
Exécutez le profile directement avec `hermes -p <profile>`.
Attribuez délibérément toute propriété gateway ou cron.
| Contrôle jour-30 | Signal d'échec | Correction |
|---|---|---|
| Profile drift | Le spécialiste commence à accepter du travail sans rapport | Resserrer SOUL.md et déplacer les nouvelles règles vers AGENTS.md ou TEAM.md |
| Memory rot | Les anciennes hypothèses deviennent des valeurs par défaut | Revoir les notes obsolètes et supprimer les contradictions |
| Handoff rot | Les profiles transmettent du matériau brut au lieu d'une sortie façonnée | Faire bloquer l'étape suivante par les transmissions mal formées |
| Cron collision | Deux profiles planifient un travail pour le même résultat | Garder un registre commun de propriété cron |
| Gateway confusion | Le mauvais profile répond à une route entrante | Documenter propriétaire, déclencheur, sortie et chemin d'escalade |
| Skill sprawl | Chaque profile charge chaque workflow | Déplacer les procédures dans des skills propres au rôle |
Hermes 0.12.0 a ajouté Curator pour la maintenance des skills, ce qui renvoie à la règle plus large: les systèmes d'agents ont besoin d'entretien. Les profiles réduisent le bruit, mais ils ont toujours besoin d'audits.
La règle d'exploitation
Ne mesurez pas le succès au nombre de profiles. Mesurez le à la capacité de chaque rôle à devenir plus précis sans rendre le reste du système plus difficile à faire confiance.
La meilleure équipe Hermes profile n'est pas la plus grande. C'est celle où chaque rôle possède un état distinct, envoie des transmissions propres et reste assez étroit pour être auditable.
webvise aide les équipes à transformer un usage IA désordonné en systèmes fondés sur des rôles avec un contexte clair, des transmissions sûres et une propriété mesurable. Apportez un assistant surchargé et un workflow récurrent, et nous cartographierons les deux premiers profiles avec vous.
Les pratiques de webvise sont alignées sur les normes ISO 27001 et ISO 42001.