Comment je suis passé de 22 agents à 17

À force de faire tourner plusieurs projets avec Claude Code, le nombre de sous-agents n’a cessé d’augmenter.
J’en ai créé un à chaque fois que j’en avais besoin, et j’en suis arrivé à 22.

Le mois dernier, je les ai ramenés à 17.

Mais au moment de les retirer, je n’ai pas noté pourquoi je le faisais.
Quand j’ai rouvert le dossier d’archives trois mois plus tard, impossible de savoir pourquoi ils avaient été abandonnés.
Sur les cinq, un seul avait une raison consignée.

Et pourtant, j’étais le seul à les avoir créés.

Pourquoi je suis monté jusqu’à 22

Quand on en ajoute, la raison est toujours claire. On les crée parce qu’on en a besoin.

Le problème, c’est l’autre sens. Au moment d’en retirer un, l’idée « et si j’en avais encore besoin plus tard ? » reste toujours en tête.
Comme je n’étais jamais totalement sûr qu’il ne servirait plus à rien, je les laissais en place. C’est ainsi que je suis arrivé à 22.

Avec le recul, il n’y avait qu’une seule vraie cause à cette prolifération.
Je n’avais aucun garde-fou pour décider : « ça ne devrait pas être un agent, mais un outil ».

Si c’est une tâche répétitive, avec une procédure figée et sans besoin de jugement contextuel, alors ce n’est pas un agent.
Il suffit d’en faire une skill ou un script. Cela ne consomme pas de tokens, la reproductibilité est de 100 %, et cela n’oublie rien quand la session change.

Sans ce garde-fou, tout devient un agent.

Les cinq retirés

En remontant le fil, j’ai vu que les suppressions se répartissaient en quatre catégories. Cette distinction était importante.

L’un d’eux n’aurait jamais dû être un agent dès le départ.
Il s’occupait de la rédaction de contenu, mais la procédure était entièrement figée.
Je l’ai remplacé par deux skills puis je l’ai retiré. J’ai explicitement indiqué qu’il ne devait pas être restauré.
Sinon, quelqu’un finira par le recréer un jour.

Trois autres faisaient doublon avec d’autres rôles.
Le contrôle de sécurité recoupait l’audit de code, la surveillance cron recoupait le health check, et la planification recoupait l’exécution.
Ils opéraient tous sur le même périmètre avec les mêmes autorisations.

J’en ai tiré un critère.

Si deux agents se recouvrent sur le même périmètre avec les mêmes autorisations,
le coût du maintien de cette séparation (charge de gestion, délai dans les décisions de délégation) dépasse ses bénéfices.

L’impression que « les deux sont quand même nécessaires » m’a longtemps bloqué,
mais la vraie question n’était pas de savoir s’ils étaient utiles, plutôt s’il valait la peine de les garder séparés.

L’un d’eux n’était tout simplement utilisé par personne.
Le trafic de cette fonction était à 0 pendant 70 jours.
Je ne l’ai pas considéré comme supprimé, mais comme dormant. Si le service redémarre, je le restaurerai tel quel.

Ce que j’ai appris en écrivant les chiffres

En notant 22 → 17 dans la documentation, j’ai réalisé une chose.

Ce chiffre n’est pas le nombre de fichiers. C’est le nombre d’agents en exploitation.
Comme l’un d’eux est défini hors du répertoire, si on compte seulement les fichiers, on obtient 21 et 16.

J’ai donc commencé le document en précisant ce que ce chiffre comptait exactement.
Et j’y ai ajouté le résultat de la vérification avec git ls-tree.

Sinon, plus tard, quelqu’un comptera les fichiers et s’arrêtera à « ça ne correspond pas ».
Quand on écrit des chiffres, il faut aussi écrire leur définition et la méthode de vérification.

Ce que j’ai décidé de respecter quand je retire un agent

Cette fois, la leçon m’a valu quatre règles.

• Au moment de la suppression, écrire la raison dans le fichier. Sinon, il faut reconstituer l’historique trois mois plus tard. C’est exactement ce qui s’est passé.

• Ne pas supprimer, mais déplacer par rename. Le contenu est conservé à 100 %, ce qui permet une restauration à l’identique.

• Indiquer explicitement les éléments qui ne doivent pas être restaurés. Sinon, quelqu’un les remettra en service un jour.

• Inclure dans la procédure de restauration « suppression des rôles en doublon dans l’élément absorbant ». Sans cela, après restauration, les deux feront le même travail.

Autres points que j’ai regroupés

J’en ai profité pour publier un ensemble de règles accumulées sur quatre ans. En voici quelques-unes.

Interdiction de contourner en douce

C’est une règle qui force un agent à signaler un blocage au lieu de le forcer.
Si le blocage est légitime, seule cette étape est mise en attente et le reste continue.
Même si le blocage semble être une erreur de jugement, on ne le contourne pas arbitrairement. On rassemble les éléments, on les remonte, puis on attend confirmation.

Et si ce blocage révèle en réalité un défaut de la règle elle-même, la réponse doit aussi inclure la correction de ce défaut.

En fait, cette règle elle-même est née ainsi. Je l’ai créée après avoir rencontré un blocage.

Ne pas écrire PASS quand c’est FAIL

Même lorsqu’un sujet est clos par instruction, on consigne l’état observé tel quel et on laisse les conditions de réouverture.
Le reporting se fait avec des mesures Before/After, et les éléments restants ainsi que les risques sont écrits avant les résultats.

Les agents subissent naturellement une pression pour produire des rapports de réussite. Si on ne l’empêche pas par des règles, ils continueront à le faire.

Définir l’autonomie par des seuils quantifiés

Au lieu d’une simple dichotomie « modification autorisée/interdite », j’ai défini en chiffres l’étendue des corrections qu’un agent d’analyse peut faire de lui-même.

• un seul fichier

• moins de 5 lignes

• pas un fichier de niveau supérieur

• en dessous du seuil de score d’impact

Il faut que toutes les conditions soient remplies (AND) ; si une seule bloque, l’agent doit faire remonter le sujet.
Et la dernière clause est essentielle — en cas d’ambiguïté, demander une délégation. La valeur par défaut doit être conservatrice, sinon la règle finit par se déliter.

Séparer la décision et l’exécution

La vérification et l’investigation sont réparties en parallèle entre des sous-agents en lecture seule,
et les opérations sur les fichiers ou la base de données sont exécutées en série de façon centralisée par l’orchestrateur.

Parce que si plusieurs agents modifient un fichier partagé en même temps, cela casse inévitablement.

Il y a un coût. Sur les gros travaux, cette exécution centralisée en série devient un goulot d’étranglement.
C’est un choix assumé : mieux vaut cela que des conflits.

Dépôt

https://github.com/YoungChulMoon/claude-agent-harness

Il s’agit simplement de quelques fichiers Markdown. Il n’y a rien à installer.
Il suffit de placer les templates sous .claude/agents/ et de ne remplir que les parties nécessaires.

Ce n’est pas une réponse universelle, mais une manière de faire qui a fonctionné dans cet environnement pendant quatre ans.
Selon la taille de l’équipe ou la nature du projet, cela peut ne pas convenir.

On trouve beaucoup de récits sur la manière d’augmenter le nombre d’agents, mais rarement sur la manière de le réduire.
J’espère que cela pourra servir de référence à ceux qui voient leurs agents se multiplier de façon similaire.