Un nouveau modèle attire votre attention. Les résultats annoncés donnent envie de le tester, mais vous voulez surtout savoir s’il peut vous être utile. Un bon classement ne répond pas à toutes vos questions : les tâches évaluées ressemblent-elles aux vôtres ? Le modèle est-il accessible de la manière qui vous convient ? Sa licence et ses contraintes techniques permettent-elles l’usage envisagé ?
Hermes peut répartir ces recherches entre deux sous-agents : des conversations distinctes, chacune chargée d’un angle précis. Vous continuez à échanger avec l’agent principal, appelé ici le parent. Il prépare les missions, reçoit les conclusions et doit les vérifier avant de vous conseiller.
Le scénario qui suit est illustratif. Il ne porte sur aucun modèle précis et ne rapporte ni essai de modèle ni résultat de performance obtenu par TekBrut. Il propose une façon de poser les questions, à adapter au modèle que vous souhaitez examiner.
Deux recherches au service du même choix
Le premier sous-agent examine ce que les performances annoncées permettent de conclure. Il part des sources officielles et distingue les résultats publiés par l’auteur du modèle des mesures indépendantes qu’il peut trouver. Il relève les conditions des tests, leurs limites et leur proximité avec votre besoin.
Si vous cherchez une aide à la rédaction en français, par exemple, demandez-lui ce que les évaluations consultées disent réellement de cet usage. Il doit pouvoir répondre qu’elles ne suffisent pas. Empiler les scores ne comblera pas cette lacune.
Le second sous-agent étudie les possibilités d’utilisation. Les poids du modèle, autrement dit ses paramètres appris, sont-ils réellement téléchargeables pour une utilisation locale ? Existe-t-il une API pour l’utiliser depuis un logiciel via un service distant ? Que permet la licence ? Quels logiciels d’exécution et quels formats sont documentés pour votre configuration ?
Pour un usage local, il cherche les contraintes matérielles pertinentes sans transformer une estimation en certitude. Si la mémoire entre en jeu, demandez-lui de distinguer l’espace de stockage, la mémoire vive de l’ordinateur (RAM) et celle de la carte graphique (VRAM). Ces indications doivent concerner la variante et les conditions d’exécution envisagées ; une donnée manquante reste une donnée manquante.
Ces deux recherches peuvent avancer séparément. La première évalue l’intérêt du modèle pour votre besoin ; la seconde examine la possibilité de l’utiliser dans votre situation. Leur rencontre est utile : une performance séduisante peut ne rien changer à votre choix si l’accès ou la licence ne convient pas. À l’inverse, un modèle accessible reste à évaluer pour votre tâche.
Donner à chacun de quoi travailler
Ce guide suppose un Hermes fonctionnel, avec delegate_task et des outils de consultation disponibles pour les recherches demandées. Leur présence et les accès autorisés dépendent de votre installation. Une consigne ne rend pas disponible un outil absent.
Les sous-agents n’ont pas l’historique de votre conversation avec le parent. Si vous lui avez déjà décrit votre ordinateur ou vos contraintes, demandez-lui de les transmettre dans chaque mission. « Étudie ce dont nous parlions » ne suffit pas.
Donnez aussi un point de départ commun : liens de l’annonce, de la fiche du modèle et de sa licence, si vous les avez. Cela permet de viser la même version et d’éviter de comparer des informations qui concernent des variantes différentes. Chaque mission doit préciser la question, les sources à privilégier, les limites de l’action et ce qui doit revenir dans la réponse.
Vous pouvez ensuite donner à Hermes cette consigne illustrative, en remplaçant les éléments entre crochets et en ajoutant vos liens :
Je veux savoir si [modèle] mérite un essai pour [usage], avec [configuration]. Utilise réellement ton outil delegate_task pour lancer deux tâches indépendantes en parallèle, sans simuler leurs réponses.
Confie à A les performances : sources officielles, résultats annoncés ou mesurés indépendamment, conditions des tests et limites pour mon usage. Confie à B l’utilisation possible : accès réel aux poids ou à l’API, licence, formats, logiciels d’exécution et contraintes matérielles documentées.
Transmets à chacun mon besoin, ma configuration et les liens fournis. Demande une recherche sans installation ni modification de fichiers. Chacun doit rendre ses constats complets, ses sources et ses incertitudes dans sa réponse finale. Puis vérifie les points décisifs dans les sources, rapproche les conclusions et recommande ou non un essai, en expliquant les conditions et les inconnues.
Vous demandez ici à Hermes d’utiliser son outil natif. Vous n’avez pas à appeler une fonction Python ni à préparer un objet technique. Dans les appels d’outils affichés par votre interface, vérifiez qu’il a bien utilisé delegate_task pour les deux missions : raconter ce que deux agents pourraient répondre ne vaut pas une délégation réelle. Si l’outil ou les accès nécessaires manquent, demandez à Hermes de le signaler plutôt que de présenter la recherche comme effectuée.
Le parent rapproche les preuves, pas les votes
À réception des analyses, demandez au parent de vérifier qu’elles parlent du même modèle et de la même variante, puis de relier chaque conclusion importante à sa source. Une annonce de disponibilité ne prouve pas à elle seule que la configuration qui vous intéresse est prise en charge.
Le désaccord peut signaler une différence de périmètre. Une analyse porte-t-elle sur l’accès distant tandis que l’autre envisage une exécution locale ? Les performances citées concernent-elles la version que vous pouvez utiliser ? Le parent doit résoudre ces écarts ou les laisser explicitement ouverts, sans faire une moyenne des avis. Deux agents qui reprennent la même annonce n’apportent pas deux confirmations indépendantes.
Pour la synthèse, une structure possible consiste à expliquer ce qui justifierait l’essai pour votre besoin, ce qui pourrait l’empêcher et ce qu’il reste à vérifier. Il s’agit d’une proposition de présentation, pas d’un résultat obtenu. La recommandation doit être conditionnelle et motivée : les raisons de tester, d’attendre une précision ou de renoncer doivent rester visibles.
La qualité de la restitution compte aussi. Lors d’une démonstration antérieure de TekBrut, distincte de ce scénario, le dernier résumé d’un sous-agent se limitait à « Livrable terminé », sans ses constats. Une reprise avait donné des retours plus complets. D’où l’intérêt de demander dès le départ les conclusions et leurs sources dans la réponse finale : selon la documentation, c’est ce résumé qui revient au parent, pas l’ensemble des étapes intermédiaires.
Quand garder un seul agent
Déléguer ajoute des consignes à préparer et des retours à contrôler. Pour retrouver une licence sur une page ou répondre à une question simple, le parent seul peut suffire. La séparation devient plus intéressante lorsque chaque angle demande assez de recherche et de jugement pour mériter sa propre conversation. Si la seconde tâche a besoin du résultat de la première, attendez ce résultat plutôt que de les lancer ensemble.
Plusieurs agents ne signifient ni plusieurs modèles ni un gain garanti de temps, de coût ou de qualité. Le contexte distinct ne constitue pas non plus une isolation des fichiers et des permissions : « ne rien modifier » reste une consigne, pas une protection du système.
Pour un premier essai, choisissez donc un modèle qui vous intéresse déjà, précisez votre usage et votre configuration, puis confiez ces deux questions à Hermes. Jugez la délégation à ce qu’elle vous permet de décider : les performances citées répondent-elles à votre besoin, et les conditions d’utilisation rendent-elles l’essai pertinent ? Si une réponse décisive manque, la synthèse doit vous le dire.
Sources
- Documentation officielle de la délégation Hermes : outil
delegate_task, tâches parallèles, contexte des enfants et restitution au parent. - Guide officiel de la délégation et du travail parallèle : choix des missions, consignes autonomes et vérification des retours.
Informations vérifiées le 26 octobre 2026.