Orchestrations

Le workflow dit quoi enchaîner. L’orchestration dit qui le fait et avec quelle marge de manœuvre. Deux leviers structurent la réponse : à qui on délègue (sous-agents) et combien on lâche la bride (autonomie).

Les deux se règlent en miroir. Plus la boucle de feedback est fiable, plus on peut déléguer et lâcher du mou ; plus elle est faible, plus on garde la main.

Délégation & sous-agent

Un sous-agent est un agent scopé, lancé par l’orchestrateur avec son propre system prompt, son toolset et sa file map. Il vit à part du contexte de l’orchestrateur : seul son résultat (ou son résumé) remonte. La communication entre agents passe par les artefacts (chapitre 5.1).

• Pourquoi :
  • éviter la pollution croisée : chaque sous-agent part d’un contexte propre
  • libérer la fenêtre de l’orchestrateur : seul le résultat remonte
  • paralléliser : worktrees git, instances multiples
  • séparer builder / checker : un agent produit, un autre vérifie
• Patterns : sous-agents focalisés sur Plan (réfléchit), Explore (lit), Implement (écrit), Review (vérifie).
• Bonus coût : des sous-agents qui enchaînent des appels autonomes maximisent le prompt caching, souvent moins cher qu’une longue session unique. On adapte aussi le modèle à la tâche (Plan = raisonnement = Opus, Implement = code = Haiku).
• Limite : coût de coordination. L’orchestrateur doit cadrer chaque délégation (un sous-agent mal briefé dérive) et le résumé qui remonte peut perdre du contexte. Trop de sous-agents = overhead.

Workflows dynamiques

Quand une tâche demande plus d’agents qu’une seule conversation ne peut coordonner (audit d’une codebase entière, migration de centaines de fichiers, recherche dont les sources doivent se recouper, etc.) l’orchestration elle-même devient du code. Un workflow dynamique est un script que l’agent écrit pour la tâche et qui s’exécute en arrière-plan, pendant que la session reste disponible.

Le point clé : le plan passe dans le code. Le script porte la boucle, les branchements et les résultats intermédiaire, puis remonte le résultat final dans le contexte de l’appellant. C’est ce qui permet de passer de quelques délégations à des dizaines, voire des centaines d’agents par exécution.

• Quand l’utiliser : quand la tâche demande un volume de traitements inférentiels élevé avec ordonnancement entre les tâches.
• Qualité, pas seulement quantité : le script peut appliquer un pattern reproductible, ex. : faire relire les conclusions d’un agent par d’autres de façon adversariale avant de les rapporter, ou produire un plan sous plusieurs angles puis les pondérer, etc.. Ce mécanisme est plus fiable qu’une passe unique.
• Déclenchement : un workflow fourni comme /deep-research, le mot-clé ultracode (ou « utilise un workflow ») dans le prompt, ou /effort ultracode pour que l’agent en planifie un à chaque tâche conséquente. Une exécution satisfaisante se sauvegarde en commande (/<nom> dans .claude/workflows/) et se rejoue à l’identique.
• Exécution : en arrière-plan et reprenable dans la même session (les agents déjà terminés rendent leur résultat en cache) ; on suit l’avancement via /workflows.
• Limites : le script coordonne mais ne touche ni au système de fichiers ni au shell, ce sont les agents qui lisent, écrivent et exécutent. Il n’y pas d’interruption humaine en cours de route (pour un point de validation entre étapes, faire de chaque étape un workflow distinct). Plafonds : jusqu’à 16 agents concurrents, et 1 000 agents au total par exécution. Et comme chaque agent consomme des tokens, une exécution coûte sensiblement plus qu’un traitement en conversation — d’où l’intérêt de tester d’abord sur une tranche réduite.

→ Doc Claude Code — Dynamic workflows

Pilotage & autonomie

L’autonomie d’un agent n’est pas un trait fixe, c’est un curseur. Le spectre va du supervisé (confirmation à chaque action) au full-unattended (agent isolé, aucune confirmation), en passant par le semi-autonome (plan validé puis exécution) et l’autonome encadré (sandbox + checks déterministes).

• Ce qui détermine le bon niveau :
  • réversibilité de l’action : un commit sur une branche se défait, un rm -rf non
  • fiabilité de la boucle de feedback : plus les feedbacks sont automatisés (tests, lint, build), plus on peut lâcher du mou
  • isolation de l’environnement : la sandbox / devbox autorise à retirer les prompts de confirmation sans risque
• Garde-fous : plafonner les boucles pour éviter les rendements décroissants. Imposer un checkpoint humain dès qu’une décision est irréversible.
• Loi : l’autonomie dérive de la qualité de la boucle de feedback et de l’isolation. Autonomie sans feedback fiable → l’agent s’auto-évalue mal. Sans isolation → rayon d’explosion incontrôlé.