Le successeur de l'Ingénierie des boucles et le workflow qui fait tourner vos agents 10x plus larges...
La plupart des gens qui construisent un agent multi-étapes aboutissent à une ligne droite
étape une, étape deux, étape trois. Chacune attend que la précédente se termine avant de commencer
Voici ce que presque personne ne vérifie :
la moitié de ces étapes n'avaient jamais besoin d'attendre
Elles font simplement la queue, un travail à la fois, jusqu'à ce que la fenêtre de contexte se remplisse et que l'agent oublie ce qu'il faisait
- Ce n'était pas lent parce que le modèle était faible
- C'était lent parce que vous avez tracé une ligne là où le travail était un graphe**
Ce guide vous mène de cette ligne à un graphe qui s'étend sur une flotte et vérifie son propre travail
Cinq étapes. À l'étape 2, vous en aurez construit un -
Il vous donne un graphe fonctionnel et nomme les pièges qui en brisent de vrais, et je signalerai où commencent les parties difficiles
avant l'alpha - abonnez-vous à mon substack pour plus d'alpha fraîche ↓
Chapitre 0 - Ce qu'est réellement l'ingénierie des graphes
Il y a un mois, le domaine parlait de boucles.
Peter Steinberger l'a résumé en neuf mots :
https://x.com/steipete/status/2078277297791189132
Une boucle est un cycle d'amélioration :
essayer quelque chose → vérifier le résultat → ajuster → recommencer
C'est l'atome : un seul agent qui améliore une chose en répétition
(Si vous avez lu mon article sur l'Ingénierie des boucles, c'est cela)
https://x.com/0xCodila/status/2072329149520232639
Mais la boucle unique a une défaillance connue - une équipe de support lie une boucle de rétroaction à une seule métrique : le taux de résolution des tickets
Le nombre monte pendant des mois tandis que la satisfaction chute. Le bot a appris à fermer les tickets rapidement au lieu de les résoudre
C'est la loi de Goodhart. Une boucle ne peut voir que sa propre métrique. Elle ne peut pas se demander si l'objectif est bon, ni remarquer que sa mesure dérive.
La réponse n'est pas une meilleure boucle. C'est un graphe de boucles - un réseau où les cycles se surveillent et se corrigent mutuellement
Pour les agents, cela signifie une seule chose :
Arrêtez d'écrire un agent qui fait tout en ligne - concevez la
forme
du travail - ce qui s'exécute avant quoi, ce qui s'exécute en même temps, ce qui attend.
Les nœuds font la réflexion. Les arêtes transportent les résultats
Et Claude Code a livré l'outillage pour construire ces graphes directement : workflows dynamiques
Étape 1 - Voir les arêtes qui ne sont pas là
Un graphe a deux parties :
- Un nœud est une unité de travail : un agent, un job, une entrée, une sortie
- Une arête est une dépendance : la sortie de ce nœud alimente l'entrée de ce nœud
L'erreur que tout le monde fait est de traiter "et ensuite" comme une arête.
"Résume ce fichier
et ensuite
dis-moi la météo"
La météo ne lit pas le résumé.
Ce sont deux jobs indépendants qu'un script linéaire enchaîne sans raison. Chacun attend l'autre pour rien
L'habitude qui lance tout :
Pour chaque "et ensuite", demandez - l'étape suivante lit-elle réellement la sortie de l'étape précédente ?
- Si oui → vraie arête. Gardez l'ordre.
- Si non → pas d'arête. L'attente est inutile. Exécutez-les côte à côte.
Si aucune donnée ne circule entre deux boîtes, elles sont indépendantes.
Cette indépendance est ce que vous exploiterez pour le reste de ce guide
Votre simple agent "fais A, puis B, puis C" est déjà un graphe - juste le plus triste : une chaîne unique où si C bloque, D n'arrive jamais.
Étape 2 - Construisez votre premier graphe (du début à la fin)
Assez de théorie. Construisez-en un et regardez-le tourner.
Avant de commencer :
- Claude Code v2.1.154+ (vérifiez avec claude --version)
- Un plan payant. Sur Max, Team ou Enterprise, les workflows sont activés par défaut. Sur Pro, activez la ligne Dynamic workflows dans /config
1. Ouvrez un dépôt que vous connaissez.
Un vrai, pour que le résultat ait du sens.
2. Collez cette invite (d'Anthropic) :
1Créez un workflow pour auditer chaque fichier de route sous src/routes/2afin de détecter les vérifications d'authentification manquantes. Lancez un agent par fichier, puis exécutez un3vérificateur indépendant sur chaque résultat avant de faire un rapport.4Analysez un maximum de 20 fichiers pour commencer.
Remplacez src/routes/ par l'endroit où se trouvent vos fichiers. La ligne "max 20" garde votre première exécution peu coûteuse.
3. Regardez "workflow" s'allumer.
Claude Code le met en évidence : "Dynamic workflow requested." C'est votre signal qu'un graphe est en cours de construction, pas une conversation normale
4. Approuvez le plan.
Claude écrit un script d'orchestration JavaScript et affiche d'abord les phases. Lisez-les, choisissez "Yes, run it."
5. Laissez la flotte tourner.
Un agent par fichier, en parallèle, pendant que votre session reste libre.
Tapez /workflows pour le regarder en direct : portée, déploiement, vérification, synthèse.
6. Lisez la réponse unique.
Pas vingt conversations séparées. Un seul rapport - parce que les résultats intermédiaires vivaient dans les variables du script, pas dans votre contexte.
C'est ça, un graphe.
Une douzaine d'agents, à partir d'une seule phrase.
À propos de l'affirmation "zéro tokens" que vous entendrez
Le script de coordination est du code
Donc passer des résultats entre agents ne re-dépense pas du contexte comme le ferait un transfert de conversation.
Mais les agents coûtent toujours de l'utilisation. Un workflow coûte significativement plus qu'une session normale.
L'économie est dans la coordination, pas dans le travail. Commencez avec une portée limitée, surveillez l'utilisation, puis élargissez.
- Personnalisez-le
Quand une exécution est bonne, appuyez sur s.
Elle est sauvegardée dans ~/.claude/workflows, ré-exécutable par nom
Maintenant, changez la tâche et gardez la forme. Remplacez "vérifications d'authentification manquantes" par "promesses non gérées", ou "fonctions de plus de 100 lignes
Jusqu'où cela s'étend (nom de l'article)
Une seule exécution de workflow peut se déployer sur 1 000 agents, avec jusqu'à 16 travaillant en même temps
C'est de là que vient "1000+ boucles dans une fenêtre" - pas une métaphore, le plafond réel de la fonctionnalité
- Et l'échelle est le point Mille agents signifient un travail qu'aucun contexte unique ne pourrait jamais contenir - une base de code entière auditée en une fois, une migration qui touche chaque fichier, une recherche qui lance mille angles en parallèle
La limite de 16 à la fois signifie simplement que la flotte se déplace par vagues, dévorant tous les mille sans que vous ayez à surveiller un seul d'entre eux
Commencez à 20 pour voir comment une exécution se comporte et ce qu'elle coûte - puis élargissez - car c'est le plafond que personne d'autre ne construit
Étape 3 - La partie qui casse vraiment
Vous avez construit un graphe. Voici où les vrais s'effondrent.
Deux défaillances comptent le plus
- Défaillance un : le graphe est d'accord avec lui-même
Quand un agent vérifie son propre travail, il se montre indulgent. Les modèles préfèrent leurs propres sorties
Donc vous placez un vérificateur sur l'arête - un nœud séparé qui confirme un résultat avant qu'il ne circule en aval.
Le piège que personne ne nomme : le vérificateur a besoin d'un contexte propre
Donnez-lui la même conversation que l'exécuteur a eue, et il ne vérifie pas. Il est d'accord avec lui-même dans une police différente
Un graphe d'agents partageant un même contexte est une boucle unique déguisée. Il échoue de la même manière - plus tard, plus cher, avec plus de feux verts sur la route de la descente
Donc le vérificateur est un nœud frais - Contexte propre - Vérifiant un signal réel - pas "l'agent a-t-il dit que c'est fait", mais "le test passe-t-il réellement"
- Défaillance deux : des agents qui se marchent dessus
Ce n'est pas hypothétique
Quand l'équipe de Bun a d'abord déployé un grand portage sur de nombreux agents, l'exécution a échoué opérationnellement et des agents ont utilisé des commandes git partagées dans un même espace de travail et se sont écrasés mutuellement
La correction a été structurelle, pas une invite astucieuse. Ils ont interdit les commandes dangereuses et donné à chaque groupe son propre worktree isolé
C'est la vraie leçon du parallélisme - deux agents qui écrivent le même fichier se font la course
Avant de vous déployer, répondez à trois questions :
- Où travaille chaque agent ?
- Comment les résultats fusionnent-ils ?
- Que se passe-t-il quand deux sont en désaccord ?
Un graphe sans ce plan ne passe pas à l'échelle - Il échoue plus vite
Étape 4 - Six graphes à construire cette semaine
La méthode : trouver les vraies arêtes → se déployer → vérifier sur un contexte indépendant → isoler les travailleurs
///
Chacun de ces graphes a la même forme, visant un nouveau travail. Changez la ligne de tâche et lancez-vous :
- Balayage de sécurité - un agent par fichier à la recherche d'authentification manquante, un vérificateur confirmant chaque résultat (celui que vous avez construit)
- Rapport cité avec /deep-research - déjà livré : divise votre question en angles, recherche en parallèle, les agents se réfutent mutuellement avant d'écrire
- Porter un module - fichier par fichier, les tests comme porte, les échecs renvoyés en boucle
- Révision de diff adversaire - routé par taille : petit changement → un passage ; grand → audit parallèle complet
- Analyse programmée de l'écosystème - sauvegardez une fois, ré-exécutez par nom
- Découverte de taille inconnue - les chercheurs tournent en parallèle, chaque résultat vérifié par rapport à tout ce qui a été vu, en boucle jusqu'à ce que deux tours ne trouvent rien de nouveau
///
À quoi ressemble le plafondhttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Le portage de Bun de Zig à Rust a fonctionné exactement sur ce mécanisme.
Environ 50 workflows, un pic de 64 agents en parallèle. Environ 535 000 lignes de Zig transformées en plus d'un million de lignes de Rust, en 11 jours.
Cela a aussi coûté environ 165 000 $ en utilisation, et a nécessité un humain pour concevoir et superviser l'ensemble.
Et cela a attiré des critiques publiques sur la possibilité de réviser en toute sécurité autant de code généré par l'IA.
L'échelle est réelle. Tout comme le prix et la supervision.
Étape 5 - Les ancres qui maintiennent un graphe honnête
La topologie seule n'achète pas la vérité
Un réseau d'agents se confirmant mutuellement, sans qu'aucun ne touche à rien de réel, échoue exactement comme la boucle unique - juste avec plus de pièces mobiles
Le graphe a besoin d'ancres : des nœuds avec lesquels on ne peut pas discuter
- Des tests qui ont réellement tourné - pas "devrait passer", a passé
- Un vérificateur sur les preuves, pas sur les impressions
- Des règles figées que les agents n'ont jamais le droit de modifier - car ce sont celles qu'un optimiseur affaiblirait
Le graphe n'est aussi honnête que les choses en lui qui refusent de bouger
Quand un graphe est le mauvais choix
La plupart des tâches ne sont pas des graphes. En utiliser un quand vous n'en avez pas besoin ne fait que brûler de l'argent et ajouter des façons d'échouer.
Évitez le graphe quand :
- La tâche est petite ou isolée. Ajouter une fonction, corriger un bug. Un workflow est ici un pur surcoût - un seul agent est plus rapide et moins cher.
- Vous avez besoin d'une supervision stricte. Si vous voulez lire et approuver chaque étape avant que la suivante ne s'exécute, l'intérêt même d'un graphe (tourner largement sans vous) joue contre vous.
- Vous ne savez pas encore ce que vous cherchez. Un travail exploratoire veut un agent que vous pouvez diriger, pas une flotte engagée dans un plan avant que vous ayez compris le problème.
- Les étapes dépendent réellement les unes des autres. Si chaque étape lit la sortie de l'étape précédente, c'est une vraie chaîne. Le parallélisme n'a rien à saisir. Forcer un graphe sur une tâche vraiment séquentielle n'ajoute qu'un coût de coordination pour une accélération nulle.
L'indice est l'Étape 1. Si vous ne trouvez pas deux boîtes sans flèche entre elles, il n'y a pas de graphe à construire. C'est une boucle, et une boucle est bien.
Un graphe est un outil pour la largeur - un travail indépendant, fait en une fois
Quand le travail n'est pas large, la ligne n'a jamais été le problème...
Le changement
Un inviteur pose une question. Un architecte dessine un graphe.
L'agent linéaire n'a jamais été le plafond.
C'était la première forme - celle que tout le monde utilise parce qu'elle correspond à la façon dont on tape : une ligne, une chose à la fois.
Une fois que vous voyez les nœuds et les arêtes, vous arrêtez de demander à l'agent de faire plus et commencez à demander au graphe de le faire plus large :
- Déployez-vous là où le travail est indépendant
- Verrouillez les arêtes là où la confiance compte
- Gelez les nœuds qui détiennent la vérité
La plupart des gens continueront à mettre les étapes en file d'attente.
Les quelques-uns qui apprennent à dessiner le graphe, et à respecter ce qui le brise, feront tourner une flotte.
Dessinez le graphe. Restez l'architecte.
Commencez par le prérequis :
- la boucle unique sur laquelle ceci est construit
