Le schéma qu'on voit partout
Vous avez sûrement vu passer le schéma. Un agent principal découpe la tâche et envoie des subagents travailler chacun sur un morceau. Ensuite, il recolle les résultats. Un agent pour le front, un pour le back, un pour les tests, un pour la doc.
Sur un tableau blanc, c'est beau. On dirait une vraie équipe. En pratique, c'est souvent moins bien qu'un seul agent.
Le problème, c'est le contexte
Un subagent démarre avec une fenêtre de contexte presque vide. Il reçoit un résumé de ce qu'on attend de lui, pas tout ce qui s'est dit avant. Les échanges avec vous, les fichiers déjà lus, les essais ratés, les petites décisions prises en route : tout ça reste dans la tête de l'agent principal.
Même si vous donnez la tâche complète à chaque subagent, ils ne voient pas ce que fait l'autre. Chacun fait ses propres choix de style, de structure et de nommage. Et ces choix finissent par se contredire.
Anthropic arrive à la même conclusion
C'est ce qui m'a donné l'idée d'écrire cet article. Anthropic vient de publier à peu près la même chose [lien à compléter]. Leur équipe a comparé plusieurs déploiements en entreprise. Résultat : un seul agent avec des skills fait souvent mieux qu'une architecture à subagents. La qualité est meilleure, et c'est souvent moins cher et plus rapide. Un client a mesuré un temps d'exécution environ deux fois plus court avec un seul agent.
Ils parlent aussi d'un travers que je trouve vraiment drôle. Chaque équipe de l'entreprise veut son propre subagent, donc l'architecture finit par copier l'organigramme. On se retrouve avec des centaines de subagents qui se chevauchent et un prompt système où chaque équipe a ajouté sa phrase. Et l'info se perd à chaque passage d'un agent à l'autre, comme au jeu du téléphone.
Leur solution, c'est la divulgation progressive. L'agent voit une courte description de chaque skill et de chaque outil, et il charge le détail seulement quand il en a besoin. Ça évite de saturer le contexte, qui était justement la principale raison de découper le travail en subagents. En plus, les modèles récents tiennent beaucoup plus de choses dans une seule boucle qu'on le pensait.
Comment je travaille
J'utilise un agent principal, avec une seule conversation par morceau de travail. Il lit le code, le modifie, lance les tests et corrige. Tout ce qu'il apprend reste au même endroit. Si je reviens sur un détail une demi-heure plus tard, il sait encore pourquoi on a fait tel choix, parce que c'est lui qui l'a fait.
Je n'ai pas de subagent pour la revue, ni pour la planification, ni pour la doc. Honnêtement, je n'en ai jamais ressenti le besoin.
Une conversation par morceau
Ça ne veut pas dire qu'un projet entier tient dans le même chat. Sur un gros projet, j'ouvre une nouvelle conversation pour chaque morceau. Je reste dedans jusqu'à ce que le morceau soit fini, puis je repars à neuf.
Si un morceau s'étire et que la conversation devient lourde, je demande à l'agent d'écrire une documentation ou bien un petit fichier AVANCEMENT.md. J'ai un prompt juste pour ça. Le fichier contient ce qui est décidé, ce qui est réglé et ce qui reste à faire. La conversation suivante reprend là où l'autre s'est arrêtée, sans que j'aie à tout réexpliquer. Une fois la partie terminée, je supprime le fichier.
Mais le vrai truc, c'est d'avancer par petits bouts. Une petite tâche tient facilement dans une seule conversation, et l'agent garde tout son contexte du début à la fin.
Je laisse mon agent gérer les subagents
Je ne lance pas de subagents moi-même. Je ne les configure pas et je ne leur donne pas de rôle. C'est mon agent principal qui décide d'en créer un quand il en a besoin.
Dans les faits, ça arrive surtout sur les gros projets dont le code est réparti dans plusieurs repos. Par exemple, un projet qui repose sur plusieurs packages npm, chacun dans son propre repo. Mon agent principal envoie alors des subagents travailler dans les repos des différents packages pendant qu'il continue de son côté.
Et ça marche bien, parce que c'est le cas idéal. Chaque package a son propre code, dans son propre repo. Les tâches ont très peu de contexte en commun, et chaque subagent rend un résultat court. Il n'y a pas deux agents qui prennent des décisions contradictoires dans le même code. C'est du vrai travail en parallèle, pas une équipe qui se pile sur les pieds.
Quand les subagents valent le coup
Je ne dis pas que les subagents sont inutiles. Anthropic donne trois cas où ils ont leur place, et je suis plutôt d'accord :
- un seul agent perd en qualité de façon mesurable parce que son contexte déborde ;
- plusieurs tâches indépendantes peuvent tourner en parallèle, chacune avec un contexte neuf qu'on jette une fois le travail fini ;
- un seul agent n'arrive plus à choisir les bons outils, ou son prompt contient des consignes qui se contredisent.
Si vous devez découper, découpez par contexte et pas par métier. Donnez à chaque subagent un morceau qui a besoin de très peu du reste, et demandez-lui un résultat court. Une recherche isolée ou une vérification indépendante, oui. Un « agent du front » et un « agent du back » qui doivent se mettre d'accord, non.
Commencez avec un seul agent
Commencez avec un seul agent et avancez par petits bouts pour qu'il garde tout son contexte. Ajoutez un subagent quand vous avez une raison concrète, pas parce que le schéma est joli. Dans mon cas, je laisse l'agent décider lui-même quand il en a besoin. Et le plus souvent, c'est quand un projet se divise en plusieurs repos, comme des packages npm.
