Subagent-First · 主代理不下场

Que fait Subagent-First · 主代理不下场 ?

L'attention de l'agent principal appartient à l'utilisateur, pas à la tâche.
Dès qu'une tâche nécessite plusieurs tours, déléguez-la systématiquement à un sous-agent en arrière-plan. L'agent principal se contente de décomposer, déléguer, valider et synthétiser, et reste toujours disponible pour répondre à l'utilisateur.

Beaucoup d'agents sont mal utilisés, non pas parce que le modèle n'est pas assez puissant, mais parce que l'agent principal est accaparé par une tâche lourde : l'utilisateur envoie une phrase, l'agent principal s'engage dans vingt tours d'appels d'outils sans pouvoir répondre ni changer de direction, et l'utilisateur n'a qu'à attendre. Quand il revient enfin, les besoins ont peut-être changé.

Ce skill fournit une discipline opérationnelle qui transforme les décisions « quand déléguer, comment déléguer, comment valider » en règles vérifiables, plutôt que de se fier à l'intuition. Cette discipline est indépendante de la plateforme : tout agent IA supportant les sous-agents / tâches d'arrière-plan (Claude Code, Codex, Cursor, WorkBuddy, Hermes et autres outils similaires) peut l'appliquer, seules les différences de noms d'outils changent — voir la table de correspondance dans la section « Table de correspondance des noms d'outils ».

Différences d'exécution selon la plateforme : Les noms de champs, limites de concurrence, sémantiques d'arrière-plan et coûts spécifiques à Hermes sont détaillés dans references/hermes-runtime-reality.md (exemple d'implémentation, les autres plateformes peuvent l'ignorer). Le corps du texte ne parle que de la discipline, sans dépendre de cette page.

---

Conditions de déclenchement

Lorsqu'une ou plusieurs des situations suivantes se présentent, vous devez appliquer ce skill (plutôt que de faire vous-même) :

1. La tâche est estimée à plus de 2–3 tours d'appels d'outils : par exemple « lire 8 fichiers et synthétiser », « faire une recherche puis organiser les résultats ».
2. Plusieurs unités indépendantes à traiter en une fois : multi-fichiers, multi-répertoires, multi-URL, plusieurs jeux de données, plusieurs options candidates.
3. Recherche longue / exploration longue : nécessite des recherches, récupérations, comparaisons répétées qui prennent plusieurs minutes.
4. Traitement par lots : appliquer la même opération (nettoyage, conversion, vérification ligne par ligne, génération ligne par ligne) à un ensemble d'entrées.
5. L'utilisateur demande explicitement le parallélisme ou de « faire plusieurs choses en même temps ».
6. L'agent principal est en pleine conversation avec l'utilisateur : l'utilisateur peut poser des questions, modifier ses besoins ou ajouter de nouvelles tâches à tout moment.
7. Les sous-tâches sont indépendantes et peuvent être lancées simultanément : typiquement « relire trois documents séparément, puis fusionner les conclusions ».
8. Pendant qu'une tâche lourde s'exécute en arrière-plan, l'utilisateur veut continuer à discuter d'autre chose (c'est le principal bénéfice de ce skill).

Condition inverse : si une tâche peut être effectuée en un seul tour d'appel d'outils et que l'utilisateur ne parle plus après avoir envoyé sa demande, alors faites-la vous-même. Forcer une délégation ne ferait que ralentir. Les critères de décision sont détaillés dans l'arbre de décision ci-dessous.

---

Principes fondamentaux

1. L'agent principal ne fait pas de travail lourd. L'agent principal ne fait que quatre choses : décomposer → déléguer → synthétiser → dialoguer avec l'utilisateur. Il doit rester dans un état de « réponse immédiate ».
2. Tâche lourde = sous-agent (obligatoire). Si les conditions ci-dessus sont remplies, déléguez. Ne vous dites pas « je suis rapide, je le fais moi-même ». La décision repose sur les attributs de la tâche, pas sur la confiance de l'agent principal.
3. Un rapport de succès n'est pas un fait. Quand un sous-agent dit « terminé », ce n'est qu'une déclaration. Sans vérification, le résultat est considéré comme non fait (voir la check-list de validation).
4. Le contexte doit être auto-suffisant. Le sous-agent ne voit pas l'historique de vos échanges avec l'utilisateur. Tout le contexte dans votre tête, il ne le reçoit pas. Si votre fiche de délégation est incomplète, il déviera inévitablement — ce n'est pas de sa faute, c'est la vôtre.
5. Le parallélisme a des limites. Seules les tâches sans dépendance sont parallélisables ; celles avec dépendance séquentielle doivent être exécutées en série, ou vous devez transmettre la sortie de l'une comme entrée de la suivante.
6. Ne déléguez pas ce qui nécessite une décision de l'utilisateur. Les tâches nécessitant une confirmation, des conséquences irréversibles, ou une validation immédiate restent entre les mains de l'agent principal.
7. Les tâches longues inter-sessions changent de mécanisme. Les tâches qui doivent survivre à la session en cours (surveillance continue, déclenchement planifié, processus permanent) utilisent le mécanisme de planification / persistance de votre plateforme (tâches planifiées, tâches programmées, processus d'arrière-plan), pas les sous-agents — la durée de vie d'un sous-agent est liée à une seule délégation.
8. En cas d'échec, dégradez, n'inventez pas. Si un sous-agent échoue, dépasse le temps imparti ou produit un résultat non conforme : dégradez en faisant vous-même, ou changez de chemin et redéléguez. Ne transformez jamais un résultat non obtenu en résultat obtenu.

Ces principes correspondent au paradigme bien connu du fork-join / fan-out-fan-in : diviser une tâche en plusieurs unités d'exécution, puis fusionner les résultats (le ForkJoinPool de Java et le MapReduce proposé par Dean et Ghemawat à l'OSDI 2004 en sont des implémentations concrètes). Ce skill n'invente pas de nouveau concept, il le traduit en une discipline opérationnelle exécutable dans le contexte d'un agent.

---

Arbre de décision : quand est-ce lourd, quand est-ce fait maison ?

Répondez aux questions suivantes dans l'ordre. La première branche où la réponse est « oui » donne la conclusion.

Question 1 : Cette tâche peut-elle être effectuée en un seul tour d'appel d'outils ?

Élément d'évaluation	Critère
Nombre d'appels d'outils	Vous pouvez les compter, et ≤ 1 tour
Nécessité de lire plusieurs fichiers	Non (0–1 fichier)
Boucle	Non (pas de « pour chaque… »)
Temps estimé	En secondes

Si les quatre sont satisfaits → faites-le vous-même. Dès qu'un seul n'est pas satisfait → passez à la question 2.

Question 2 : Cette tâche nécessite-t-elle une décision de l'utilisateur ?

• L'utilisateur doit choisir entre plusieurs options → Faites-le vous-même (ou faites d'abord une collecte d'informations, puis présentez les options).
• Opération irréversible (suppression de données, publication, paiement, envoi de message à un tiers) nécessitant une validation immédiate → Faites-le vous-même.
• Simplement « l'utilisateur doit savoir », sans décision en cours de route → Délégable, mais la synthèse doit être claire.

Question 3 : Cette tâche doit-elle survivre à la session en cours ?

• Oui (déclenchement planifié, surveillance continue, service permanent) → Utilisez le mécanisme de planification / persistance de votre plateforme (tâches planifiées, tâches programmées, processus d'arrière-plan), pas les sous-agents.
• Non, elle doit être terminée dans la session en cours → Passez à la question 4.

Question 4 : Peut-on la décomposer en plusieurs blocs indépendants ?

• Oui → Déléguez plusieurs sous-agents en parallèle, chacun responsable de son fichier / répertoire / URL / jeu de données, puis l'agent principal fusionne.
• Non, mais il y a un ordre clair → Déléguez en série, ou confiez toute la chaîne à un seul sous-agent (ça vous fera toujours gagner du temps).
• Impossible de décomposer, et ce n'est pas long → Revenez à la question 1 et reconfirmez : vous ferez probablement vous-même.

Tableau de référence rapide

Type de tâche	Temps typique	Action
Vérifier une valeur, lire un passage d'un fichier	Secondes	Faites vous-même
Modifier une phrase, exécuter une commande	Secondes	Faites vous-même
Lire 3 fichiers et synthétiser	1–2 minutes	Faisable ou déléguable ; déléguez si l'utilisateur attend
Lire 8 fichiers, résumer chacun	Plusieurs minutes	Déléguez
Recherche multi-source + comparaison croisée	Plusieurs à 15+ minutes	Déléguez (parallélisable par blocs)
Traitement par lots de N entrées (N ≥ 5)	Croît avec N	Déléguez (découpez en parallèle)
L'utilisateur doit choisir entre plusieurs options	Variable	Faites vous-même (collectez + présentez)
S'exécute une fois par jour	Inter-sessions	Tâche planifiée (pas de sous-agent)

---

Processus en 5 étapes

Étape 1 : Décomposition

Découpez la tâche en unités aux limites claires. Chaque unité doit pouvoir répondre indépendamment à trois questions :

• Quelle est l'entrée ? : Chemin de fichier, répertoire, liste d'URL, nom de jeu de données, paramètres.
• Quelle est la sortie ? : Nom de fichier, format, chemin.
• Comment savoir si c'est fait ? : Critères vérifiables, pas un « faites du bon travail ».

Respectez deux règles lors du découpage :

• Pas de collision d'écriture : Deux sous-agents ne doivent jamais écrire dans le même fichier. Soit chacun écrit dans son propre fichier et l'agent principal fusionne, soit exécutez en série.
• Les dépendances doivent être explicites : Si A produit une entrée pour B, ne les exécutez pas en parallèle — soit en série, soit confiez A+B à un seul sous-agent.

Critères d'achèvement (cocher)

• Chaque unité a une entrée claire (chemin / liste spécifique)
• Chaque unité a une sortie claire (nom de fichier + format + emplacement)
• Chaque unité a un critère d'achèvement vérifiable
• Aucune unité n'écrit dans le même fichier qu'une autre
• Toutes les dépendances sont annotées (lesquelles doivent être en série)

Étape 2 : Délégation

Utilisez l'outil de sous-agent / tâche d'arrière-plan de votre plateforme pour déléguer chaque unité (sous Hermes, c'est delegate_task ; pour les autres plateformes, voir la « Table de correspondance des noms d'outils »). Rédigez la fiche selon les « quatre éléments » (voir section suivante). Points clés :

• Un sous-agent ne reçoit qu'une seule tâche bien définie, ne mettez pas trois choses sans rapport dans une seule fiche.
• Écrivez tout le contexte dans la fiche — le sous-agent ne voit pas vos échanges avec l'utilisateur.
• Dites-lui clairement où placer la sortie et ce qu'il doit rapporter (chemin de fichier ? nombre de lignes ? sortie de commande ?).
• Exigez explicitement qu'il ne rapporte que ce qui est vérifiable : quelle commande il a exécutée, quel résultat il a obtenu ; s'il n'a pas pu faire quelque chose, qu'il le dise.
• Si votre plateforme supporte le rapport structuré / la validation de sortie (par exemple, validation JSON Schema de la réponse finale du sous-agent) — privilégiez le structuré plutôt que le texte libre.

Critères d'achèvement

• Chaque fiche contient les quatre éléments (objectif / contexte / structure de sortie / mode de validation)
• Chaque fiche spécifie le chemin de sortie
• Chaque fiche exige un rapport avec preuve vérifiable (commande + sortie réelle)
• Pas de références vagues comme « tu sais quoi faire », « comme avant »

Étape 3 : Ordonnancement parallèle

• Parallélisez ce qui peut l'être : Lancez les unités sans dépendance en une seule fois, ne les mettez pas en file d'attente.
• Sérialisez les dépendances : Attendez que la validation de l'unité amont soit réussie avant d'utiliser sa sortie comme contexte pour la fiche de l'unité avale.
• Limitez le parallélisme : Trop de sous-agents en même temps se font concurrence pour les ressources et alourdissent votre synthèse. Trois à cinq est une fourchette confortable ; au-delà, envisagez des lots (les conséquences d'un dépassement varient selon la plateforme, voir la table de correspondance et la page de détails de la plateforme).
• Une fois la délégation lancée, revenez immédiatement vers l'utilisateur : Ne restez pas à attendre les sous-agents. C'est précisément le but de cette discipline : pendant que l'utilisateur vous attend, vous devez être en mesure de répondre.
• Ne faites pas de polling, n'attendez pas : L'appel de délégation doit retourner immédiatement, les résultats sont renvoyés par la plateforme ; l'agent principal doit pouvoir prendre en compte les nouveaux messages de l'utilisateur pendant l'attente. Si votre plateforme bloque par défaut, passez l'appel de délégation en mode asynchrone / arrière-plan.
• Laissez un point de contrôle à l'utilisateur : Si votre plateforme permet de voir les sous-agents en cours, de corriger un sous-agent, ou de l'arrêter prématurément en conservant les résultats partiels, utilisez-la ; sinon, dégradez en « dans le prochain lot, incluez la correction ».

Critères d'achèvement

• Les unités sans dépendance ont été lancées simultanément (pas une par une)
• Les unités avec dépendance ont été exécutées en série, et l'unité avale a reçu la sortie de l'unité amont
• Le niveau de parallélisme est contrôlé (pas plus d'une dizaine d'un coup)
• Après la délégation, l'agent principal n'est pas bloqué et peut répondre à l'utilisateur

Étape 4 : Validation

C'est l'étape la plus facile à sauter, et la plus importante à ne pas sauter. Le « terminé » d'un sous-agent est une déclaration en attente de vérification, pas une conclusion.

Validez dans l'ordre (voir la check-list de validation) :

1. La sortie existe-t-elle ? : Le fichier est-il vraiment là ? Le chemin est-il correct ? Lisez le contenu réel.
2. La sortie est-elle conforme ? : Format, champs, nombre de lignes, gamme, tout correspond aux exigences de la fiche ?
3. Les conclusions sont-elles étayées ? : Les chiffres / conclusions clés qu'il affirme ont-ils une sortie de commande ou une source correspondante ?
4. Vérification aléatoire du texte source : Choisissez aléatoirement 1–2 éléments et retournez à la source originale pour les vérifier.

Si un point échoue → suivez la procédure d'échec de l'étape 5.

Critères d'achèvement

• La sortie de chaque sous-agent a été lue / vérifiée via les outils de votre plateforme (sous Hermes, read_file / terminal)
• Le format et les champs correspondent aux exigences de la fiche
• Les conclusions clés ont une preuve traçable
• Au moins un élément a été vérifié aléatoirement contre la source originale et correspond à ce qu'a dit le sous-agent
• Les sorties échouées / non conformes sont clairement marquées, et non mélangées dans le résultat final

Étape 5 : Synthèse

Lorsque vous synthétisez pour l'utilisateur, vous devez faire trois choses :

• Indiquer la source : Quelle partie a été faite par un sous-agent, quelle partie par vous-même. L'utilisateur a le droit de savoir.
• Indiquer l'état : Qu'est-ce qui a été validé, qu'est-ce qui ne l'a pas été, qu'est-ce qui a échoué. Ne brouillez pas les cartes avec des « à peu près », « probablement ».
• Proposer la suite : Les points nécessitant une décision de l'utilisateur doivent être explicitement listés.

Gestion des échecs (par ordre de priorité) :

1. Dégrader en faisant vous-même — la tâche n'est en fait pas si lourde, faites-la vous-même.
2. Redéléguer par un autre chemin — intégrez la raison de l'échec dans une nouvelle fiche, et réessayez avec une autre méthode.
3. Redécouper et redéléguer — la fiche était trop grande et a fait dévier le sous-agent ; découpez en plus petites unités et réessayez.
4. Rapporter honnêtement — si ça ne marche pas, dites-le, en expliquant les points bloquants et les chemins déjà exclus. Il est interdit d'inventer des résultats.

Critères d'achèvement

• La synthèse indique la source de chaque partie (sous-agent / agent principal)
• La synthèse indique l'état de validation de chaque partie
• Les tâches échouées ont été traitées (faites par vous-même / redéléguées / rapportées honnêtement), pas cachées
• Les éléments nécessitant une décision de l'utilisateur sont listés séparément
• Aucune phrase non vérifiée n'est présentée comme un fait

---

Les quatre éléments d'une fiche de délégation

Chaque fiche doit contenir ces quatre choses. S'il en manque une, la probabilité d'incident augmente considérablement.

1. Objectif (goal) — Que faire

Décrivez l'objectif en une phrase, commencez par un verbe, axée sur le résultat.

• Bien : Fusionner 3 CSV en un seul combined.csv sans doublons, en conservant l'ordre original des colonnes
• Mal : Traiter ces fichiers

2. Contexte (context) — Pourquoi et avec quoi (doit être auto-suffisant)

C'est le plus facile à rater des quatre éléments. La raison est simple :

Le sous-agent ne voit pas l'historique de vos échanges avec l'utilisateur. Il ne connaît que ce que vous écrivez dans la fiche. Tout le contexte dans votre tête — les préférences de l'utilisateur, les pièges déjà rencontrés, pourquoi telle solution ne peut pas être utilisée, les définitions des données — il ne le reçoit pas.

Le contexte doit donc explicitement inclure :

• Contexte de la tâche : À quel objectif sert cette tâche, ce qui importe à l'utilisateur.
• Contraintes strictes : Définitions, formats, règles de nommage, interdictions à respecter.
• Liste d'entrées : Chemins de fichiers / répertoires / URL / jeux de données spécifiques, pas « ces fichiers-là ».
• Pièges connus : Ce qui a été essayé et n'a pas marché, où se trouvent les pièges, les points faciles à mal interpréter.
• Informations d'environnement : Répertoire de travail, outils disponibles, dépendances déjà installées.

Méthode d'auto-vérification : Si je donne cette fiche à un collègue qui ne connaît rien du contexte, peut-il la suivre ? Si oui, elle est auto-suffisante.

3. Structure de sortie (output schema) — À quoi ressemble la sortie

Fixez la structure de la sortie, pour éviter d'avoir à la retravailler après son retour.

• Pour les fichiers : Chemin + nom de fichier + format (markdown / json / csv) + champs ou sections obligatoires.
• Pour les rapports : Exigez une structure (conclusion / preuve / source / points non résolus), pas un texte libre.
• Privilégiez le lisible par machine : Si vous pouvez donner du json, évitez le texte libre — ça vous évite une phase de re-parsing.
• Si votre plateforme supporte la validation de sortie (vérification de la réponse du sous-agent selon un schéma), activez-la ; sinon, répétez la structure dans le corps de la fiche et exigez « rapporter selon cette structure ».

4. Mode de validation — Comment prouver que c'est fait

Dites-lui à l'avance comment vous allez valider, il s'adaptera ; si vous découvrez après coup qu'il n'y a pas de preuve, vous devrez tout refaire.

• Exigez le rapport des commandes réellement exécutées et de leurs sorties (pas « j'ai vérifié »).
• Exigez que le chemin de sortie soit directement accessible.
• Exigez une liste explicite des parties non terminées / douteuses — il vaut mieux qu'il le dise que vous le découvriez.

Tableau de référence rapide des quatre éléments

Élément	En une phrase	Défaut courant
Objectif	Que faire, axée sur le résultat	Trop vague : « organise ces fichiers »
Contexte	Contexte + contraintes + liste d'entrées + pièges connus	Seulement l'objectif sans contexte, le sous-agent improvise
Structure de sortie	Chemin, format, champs	Pas de chemin spécifié, sortie éparpillée introuvable
Mode de validation	Commande / critère utilisé pour valider	Pas de critère, validé au « ça semble ok »

---

Check-list de validation

Pour chaque sortie d'un sous-agent, passez en revue chaque élément. Si un seul est « non », le travail n'est pas considéré comme fait.

A. Existence

• Le fichier de sortie existe réellement au chemin spécifié dans la fiche (vérifié en lisant / exécutant via les outils de la plateforme, pas seulement en regardant le nom)
• Le fichier n'est pas vide, son contenu n'est pas un placeholder / résidu de template / troncation évidente
• Si c'est un code ou un script : il s'exécute réellement (pas seulement « il a l'air correct »)

B. Conformité

• Le format, les champs et le nom respectent les exigences de la fiche
• La quantité correspond (demandé 10 lignes = 10 lignes, pas « environ 8 »)
• Pas de débordement : n'a pas modifié des fichiers qu'il ne devait pas modifié, n'a pas écrit en dehors de la zone spécifiée
• Les tâches parallèles ne se sont pas mutuellement écrasées (vérifiez les dates de modification / l'intégrité du contenu)

C. Authenticité

• Les commandes que le sous-agent prétend avoir exécutées ont une sortie réelle correspondante
• Les conclusions clés peuvent être retracées jusqu'à une source spécifique (fichier, URL, résultat de commande)
• Choisissez aléatoirement 1–2 éléments, retournez à la source originale et vérifiez : la conclusion est cohérente
• Pas de chiffres ou d'affirmations qui « semblent raisonnables mais n'ont pas de source »

D. Complétude

• Chaque élément demandé dans la fiche a été livré
• Les parties non terminées / douteuses sont listées explicitement, pas cachées
• Les échecs sont clairement expliqués (où ça a échoué, ce qui a été essayé)

E. Dernière vérification avant synthèse

• Dans ma réponse à l'utilisateur, j'indique la source et l'état de validation
• Je n'ai pas transformé le « rapport de succès » du sous-agent en « terminé » dans ma conclusion

---

Pattes communes et anti-patterns

12 pièges réels (et comment les éviter)

1. Le sous-agent qui rapporte « terminé » mais dont la sortie est vide. → Solution : Ne faites jamais confiance à un rapport de succès sans vérification. L'étape de validation doit systématiquement ouvrir le fichier et vérifier son contenu.

2. Un sous-agent dérive parce que le contexte est insuffisant. → Solution : La section « contexte » de la fiche doit être auto-suffisante. Testez-la en l'envoyant à un collègue qui ne connaît rien.

3. Deux sous-agents écrivent dans le même fichier et se marchent dessus. → Solution : Pendant l'étape de décomposition, assurez-vous qu'aucune unité n'écrit dans le même fichier qu'une autre. Utilisez des noms de fichiers temporaires uniques par sous-agent.

4. Une tâche qui nécessite une décision de l'utilisateur est déléguée à un sous-agent qui ne peut pas dialoguer. → Solution : La question 2 de l'arbre de décision répond à cela : si l'utilisateur doit décider, ne déléguez pas. Faites la collecte d'informations, puis présentez les options.

5. Une tâche longue inter-sessions (surveillance, tâche planifiée) est déléguée à un sous-agent, et elle s'arrête silencieusement un jour. → Solution : La question 3 de l'arbre de décision répond à cela : si la tâche doit survivre à la session, utilisez le mécanisme de planification / persistance de la plateforme, pas les sous-agents.

6. Un sous-agent produit un résultat « presque correct », mais avec de petites erreurs coûteuses qui s'accumulent. → Solution : La validation par échantillonnage aléatoire (point 4 de la validation d'authenticité) et une spécification claire de la structure de sortie minimisent ce risque.

7. Un sous-agent échoue, et l'agent principal « oublie » de le signaler à l'utilisateur. → Solution : Le dernier point de la check-list de complétude exige que les échecs soient explicitement listés dans la synthèse.

8. Un sous-agent prétend avoir exécuté une certaine commande, mais le résultat est inventé. → Solution : La validation d'authenticité vérifie les sorties de commandes réelles et croise les sources.

9. L'agent principal bloque en attendant les sous-agents, ce qui rend l'utilisateur incapable d'interagir. → Solution : Le point 3 de l'étape 3 exige que la délégation soit asynchrone et que l'agent principal reste joignable.

10. Le parallélisme est trop élevé, ce qui épuise les ressources de la plateforme ou ralentit chaque sous-agent. → Solution : Le point sur la limitation du parallélisme dans l'étape 3 recommande de regrouper les tâches en lots de 3 à 5.

11. Un sous-agent reçoit une tâche trop complexe/vague et tourne en rond ou improvise. → Solution : La règle de l'étape 2 « un sous-agent, une tâche » et des objectifs clairs minimisent ce risque.

12. L'agent principal oublie la supervision et fait confiance au rapport du sous-agent, ce qui conduit à un résultat erroné. → Solution : Principe fondamental n° 3 : ne faites jamais confiance, vérifiez toujours. L'étape de validation est obligatoire, pas optionnelle.

6 modes de délégation

1. Délégation parallèle (fan-out) : Plusieurs sous-agents indépendants exécutés simultanément, l'agent principal fusionne les résultats. Convient aux tâches de type « traiter plusieurs fichiers en parallèle ».
2. Délégation séquentielle (pipeline) : A produit l'entrée de B, B produit l'entrée de C. Exécution en série, chaque sous-agent reçoit la sortie du précédent.
3. Délégation d'exploration (recherche approfondie) : Un seul sous-agent chargé d'une exploration longue (multi-sources, multi-tours de recherche). L'agent principal supervise à distance.
4. Délégation de vérification (peer review) : Un sous-agent produit, un autre vérifie. La validation croisée est confiée à un second sous-agent.
5. Délégation de synthèse (merge) : Après exécution parallèle, un sous-agent dédié fusionne toutes les sorties. L'agent principal ne fait que superviser la fusion.
6. Délégation en mode dégradé (fallback) : Si une méthode échoue, un sous-agent spécialtâche de réessayer avec une approche différente.

Anti-patterns (à ne pas faire)

1. Déléguer une tâche qui peut être faite en un tour d'outil → Ralentit inutilement.
2. Déléguer une tâche nécessitant une décision de l'utilisateur → Bloque parce que le sous-agent ne peut pas dialoguer.
3. Donner un contexte incomplet → Le sous-agent dérive, il faut réessayer.
4. Ne pas spécifier le chemin de sortie → Impossible de retrouver les résultats.
5. Se fier au rapport de succès sans lancer la validation → Erreurs non détectées.
6. Tout paralléliser sans vérifier les dépendances → Écrasement de fichiers, ordre incorrect.
7. Ne pas limiter le paralélisme → Épuisement des ressources, ralentissement général.
8. Bloquer l'agent principal en attendant → L'utilisateur ne peut pas interagir.
9. Ne pas indiquer l'état de validation dans la synthèse → L'utilisateur ne sait pas ce qui est fiable.
10. Cacher les échecs → Perte de confiance de l'utilisateur.
11. Déléguer des tâches inter-sessions à un sous-agent → Risque d'arrêt silencieux.
12. Inventer des résultats en cas d'échec → Comportement dangereux, à proscrire absolument.

---

Table de correspondance des noms d'outils (plateformes courantes)

Cette table vous aide à mapper les noms d'outils de différentes plateformes pour appliquer ce skill. Si votre plateforme n'est pas listée, appliquez les principes généraux de ce document.

Rôle / action	Claude Code	Cursor	Codex CLI	Hermes	WorkBuddy	Générique / Description
Sous-agent	bash (dans un sous-processus) + gestion de contexte	Agent (mode agent)	Commandes dans un sous-shell	delegate_task	Subtask / Background Task	Équivalent d'un sous-agent ou tâche d'arrière-plan
Exécuter une commande	bash	Command	Commande shell directe	terminal	Run Command	Exécution de commandes système
Lire un fichier	read_file	Read File	cat, head, etc.	read_file	Read File	Lecture de contenu de fichier
Écrire un fichier	write_file	Write File	echo, tee, etc.	write_file	Write File	Écriture de contenu dans un fichier
Structure de sortie / schéma	Contrôle via l'output dans la fiche	Format demandé dans l'invite	Format défini dans l'invite	output_schema (JSON Schema)	Schéma dans la configuration	Définition du format de la sortie attendue
Limite de parallélisme	Basée sur les ressources du terminal	Basée sur le plan	Gérée par le shell	Configurable via parallelism param	Limite de sous-tâches	Nombre maximum de sous-agents simultanés
Tâche planifiée / inter-session	Cron / système de planification externe	Non natif	Cron / service système	scheduled_task	Scheduled Task	Tâche qui survit à la session

Note : Les noms ci-dessus sont génériques et peuvent différer selon la version de votre plateforme. Consultez la documentation de votre plateforme pour les noms exacts.

---

Utilitaire fourni : scripts/delegation_planner.py

Un script Python en bibliothèque standard (zéro dépendance) pour vous aider à décider automatiquement si une tâche doit être déléguée ou non. Il prend en entrée une liste de tâches (format : nombre de tours, nombre de fichiers, est-ce une recherche, est-ce un lot, nécessite-t-il une décision, est-ce irréversible, est-ce inter-session) et produit :

• La décision finale : « Déléguer à un sous-agent », « Faire soi-même », ou « Transférer vers une tâche planifiée ».
• Une suggestion de regroupement parallèle.
• Une liste des actions obligatoires pour l'agent principal.

Utilisation :

python scripts/delegation_planner.py --tasks '[
    {"name": "Analyser 10 fichiers", "tours": 8, "fichiers": 10, "recherche": false, "lot": false, "decision": false, "irreversible": false, "intersession": false},
    {"name": "Envoyer un email", "tours": 1, "fichiers": 0, "recherche": false, "lot": false, "decision": false, "irreversible": true, "intersession": false}
]'

Sortie :

{
  "decisions": [
    {
      "nom": "Analyser 10 fichiers",
      "action": "DELEGUER",
      "motif": "Tâche multi-tours (8 tours) et multi-fichiers (10 fichiers).",
      "groupe": "groupe_1",
      "ordre": 1,
      "depend_de": []
    },
    {
      "nom": "Envoyer un email",
      "action": "FAIRE_SOI_MEME",
      "motif": "Tâche nécessitant une décision ou irréversible, l'utilisateur doit superviser.",
      "groupe": "principal",
      "ordre": 0,
      "depend_de": null
    }
  ],
  "plan_action_principal": [
    "Envoyer un email : doit être fait par l'agent principal sous supervision de l'utilisateur.",
    "Analyser 10 fichiers : déléguer à un sous-agent. Après validation, fusionner les résultats dans la synthèse."
  ]
}

Le script n'exécute pas de délégation ; il fournit une aide à la décision structurée. Vous l'utilisez pour préparer vos fiches de délégation.

---

Références et détails spécifiques à la plateforme

• references/hermes-runtime-reality.md : Contient les noms de champs réels, les limites de concurrence et la sémantique d'arrière-plan pour la plateforme Hermes (et son coût). Ce fichier est un exemple d'implémentation ; les autres plateformes peuvent l'ignorer.
• scripts/delegation_planner.py : Script utilitaire d'aide à la décision (bibliothèque standard, zéro dépendance).

---

Mots-clés de déclenchement : sous-agent, délégation, delegate, orchestration de tâches, multi-agent, exécution parallèle, gestion de contexte, agent principal accaparé, IA ne répond pas, attente trop longue, interruption bloquée, traitement par lots, recherche longue, fork-join, fan-out.