Sub-agents, équipes d'agents et workflows

Vue d'ensemble

Un sub-agent est un agent frais que vous lancez pour une tâche délimitée. Il fait le travail dans son propre context window propre et ne rapporte que le résultat, si bien que votre agent principal reste focalisé et n'atteint jamais le performance cliff par le fait de tout porter d'un coup. Cette leçon explique pourquoi cela compte, vous donne l'analogie du labyrinthe qui rend la bonne délégation évidente, et couvre les décisions pratiques - séquentiel versus parallèle, quel modèle, comment délimiter la tâche - qui décident si une équipe aide ou ne fait que brûler de l'argent.

Ce que vous allez apprendre

Vous allez apprendre pourquoi les sub-agents existent et quel problème de context cliff ils résolvent, l'analogie du labyrinthe pour délimiter le travail délégué, comment écrire un brief propre pour un sub-agent afin qu'il rapporte une conclusion nette plutôt qu'un fouillis, quand lancer les agents en séquentiel versus en parallèle et comment garder les coûts en vue pour qu'une équipe d'agents ne gonfle pas silencieusement votre facture d'un multiple.

Prérequis

La leçon sur les tokens, le contexte et le performance cliff du Cours 1 et un workflow single-agent confortable. Le multi-agent ne paie qu'une fois que vous avez vraiment maîtrisé un agent, car ici tout tourne autour de la gestion des limites que vous avez d'abord rencontrées au Cours 1 - désormais sur plusieurs agents au lieu d'un.

Le problème

Vous donnez à votre agent une grosse tâche. À mi-chemin, son context window est bourré de contenus de fichiers, de sorties de commandes, d'impasses qu'il a explorées et d'historique de conversation. Le performance cliff frappe : il commence à oublier l'objectif initial, à contredire des décisions antérieures et à devenir flou sur des détails limpides il y a une heure. Le travail de la seconde moitié est moins bon que celui de la première, non parce que le modèle a empiré, mais parce que son bureau est encombré. Vous ne pouvez pas corriger cela en promptant mieux. La fenêtre est simplement pleine du bruit que la tâche a généré en chemin.

Pourquoi les sub-agents existent

Un sub-agent résout le problème du bureau encombré en faisant l'exploration désordonnée ailleurs. Vous lancez un agent frais au contexte vide, lui donnez une tâche autonome, et il se fraie un chemin dans toute la lecture de fichiers, l'exécution de commandes et les impasses dans sa propre fenêtre. Quand il a fini, il ne rapporte que la conclusion à votre agent principal. Tout ce bruit - les douze fichiers qu'il a lus, les approches ratées, la sortie brute des commandes - reste dans le contexte du sub-agent et ne touche jamais le vôtre. Le bureau de votre agent principal reste propre, donc il reste tranchant pour toute la tâche. C'est tout l'intérêt : les sub-agents sont d'abord un outil de gestion de contexte, un outil de parallélisme seulement ensuite.

L'analogie du labyrinthe

Imaginez votre agent principal avançant dans un labyrinthe vers un objectif, tenant le fil qui marque le chemin du retour. Chaque couloir latéral qu'il explore lui-même risque de lui faire perdre sa place et d'oublier la route. Imaginez maintenant qu'il puisse à la place envoyer un éclaireur dans un couloir latéral. L'éclaireur explore toute la branche - lit tout, rencontre les impasses, trouve la réponse - et revient rapporter une seule phrase : « ce couloir mène à la salle au trésor, prends la deuxième à gauche ». L'agent principal n'a jamais quitté le chemin principal, jamais perdu le fil et a gagné exactement le savoir dont il avait besoin. C'est un sub-agent. Vous déléguez une branche du travail, le sub-agent absorbe tout le désordre de l'exploration, et votre contexte principal ne reçoit que la conclusion propre.

• Les bonnes tâches de sub-agent sont autonomes : « trouve quel fichier définit la middleware d'auth et résume comment elle fonctionne ».
• Le sub-agent fait tout le travail bruyant : lire beaucoup de fichiers, lancer des recherches, essayer des approches.
• Il rapporte une conclusion, pas une transcription : un résumé net auquel l'agent principal peut réagir.
• Votre contexte principal ne grandit que de cette conclusion, pas de tout ce que le sub-agent a touché.

Séquentiel versus parallèle

Une fois que vous avez des sub-agents, vous pouvez les lancer de deux façons, et bien choisir compte pour la justesse et les coûts. Lancez-les en séquentiel quand chaque étape dépend de la précédente - explorer, puis construire à partir de ce qui a été trouvé, puis tester à partir du build. L'ordre est la logique. Lancez-les en parallèle quand les tâches sont vraiment indépendantes : résumer cinq fichiers distincts, ou inspecter trois sous-systèmes non liés. Le parallèle est plus rapide, mais sûr seulement s'il n'y a pas d'état partagé sur lequel les agents trébucheraient. Le défaut honnête est le séquentiel : plus facile à raisonner, plus facile à déboguer, et la plupart du vrai travail a des dépendances entre les étapes. Ne saisissez le parallèle que quand l'indépendance est évidente.

• Séquentiel : chaque étape a besoin du résultat de la précédente. Plus facile à raisonner et déboguer. Le défaut sûr.
• Parallèle : les tâches sont totalement indépendantes sans état partagé. Plus rapide, mais juste seulement si vraiment indépendantes.
• Dans le doute, séquentiel - un mauvais découpage parallèle cause des bugs subtils, difficiles à traquer.
• Remarquez que les axiomes CLAUDE.md de ce projet précis exigent un travail de sub-agents séquentiel pour exactement cette raison.

Contrôle des coûts

Chaque agent coûte des tokens, et une équipe multiplie cela vite. Trois sub-agents plus un agent principal, ce sont quatre context windows remplis et facturés, et si vous les lancez sans soin, la facture grimpe en silence. Trois habitudes gardent cela raisonnable. Premièrement, ne lancez un sub-agent que si le focus qu'il achète vaut la dépense - un unique agent fait beaucoup de travail bien, et tout ne doit pas être délégué. Deuxièmement, adaptez le modèle à la tâche : une sous-tâche étroite d'extraction ou de résumé peut tourner sur un petit modèle bon marché, tandis que l'agent principal en utilise un puissant pour le reasoning. Troisièmement, délimitez étroitement les tâches de sub-agent pour qu'elles finissent vite sans divaguer, car un brief vague transforme un éclaireur bon marché en explorateur cher. Le but est d'acheter du focus là où le focus vaut le coup, pas de mener une armée permanente d'agents.

Erreurs fréquentes

Les coûteuses : lancer des sub-agents pour un travail qu'un unique agent ferait bien, si bien que vous payez une coordination non nécessaire ; lancer en parallèle des tâches qui partagent secrètement de l'état et se corrompent mutuellement ; donner à un sub-agent un brief vague, si bien qu'il rapporte une transcription pléthorique qui repollue votre contexte principal au lieu d'une conclusion propre ; et utiliser un modèle vaisseau amiral pour chaque sous-tâche quand un bon marché suffirait. Déléguez délibérément, délimitez étroitement et choisissez le modèle par job.

ROI business

Les sub-agents sont le moyen de faire passer à l'échelle la quantité de vrai travail qu'un workflow agentique peut abattre, sans que la qualité s'effondre au cliff. Une équipe qui délègue bien peut prendre des tâches bien plus grandes que ce qu'un unique context window pourrait jamais tenir, tout en gardant l'output final tranchant, parce que l'agent principal ne se noie jamais dans les détails. Fait avec discipline - ne déléguer que si ça vaut le coup, des modèles bon marché pour les jobs étroits, des délimitations étroites - vous obtenez le débit d'une équipe pour une fraction de ce que coûterait une dépense multi-agent sans soin. Pour une fondatrice, c'est la différence entre un agent qui aide sur des tâches et un système agentique qui pilote des projets entiers.

Checklist

Vous êtes prêt à avancer quand chacun de ces points est vrai. La prochaine leçon va en profondeur dans la gestion du contexte sur un ou plusieurs agents.

• Vous savez expliquer pourquoi un sub-agent protège le context window principal.
• Vous savez utiliser l'analogie du labyrinthe pour décider ce qui fait une bonne tâche déléguée.
• Vous savez quand lancer les sub-agents en séquentiel versus en parallèle et pourquoi le séquentiel est le défaut.
• Vous avez trois habitudes concrètes pour garder les coûts multi-agents sous contrôle.

Ressources

Gardez en favoris la documentation de Claude Code sur les sub-agents pour la façon à jour de les définir et de les invoquer, y compris les configurations de sub-agent sur mesure. La leçon de choix de modèle du Cours 1 est votre référence pour adapter un modèle bon marché à une sous-tâche étroite. Votre CLAUDE.md est le bon endroit pour fixer les règles d'équipe - séquentiel par défaut, quand déléguer - pour que l'agent les applique automatiquement.

Votre mission

Prenez une tâche qui boursoufle habituellement votre contexte - quelque chose qui doit explorer plusieurs fichiers avant d'agir. Faites-la tourner deux fois : une fois avec un unique agent qui fait tout, et une fois en laissant l'agent lancer un sub-agent qui explore et rapporte une conclusion avant d'agir. Remarquez à quel point la session principale reste plus propre la deuxième fois. C'est le cliff géré au lieu d'être heurté.

Prochaine leçon

Gérer le contexte sur un ou plusieurs agents est un métier à part entière. La prochaine leçon va en profondeur sur les leviers : pourquoi l'auto-compaction nuit silencieusement, comment réinjecter vos objectifs après, écrire des documents de passation, quand réinitialiser complètement un chat et adapter le thinking effort à la tâche.