La plupart des gens qui tentent de construire un agent multi-étapes aboutissent à une ligne droite. Étape un, étape deux, étape trois — chacune attendant poliment que la précédente termine avant de commencer.
9/10 remarquent que la moitié de ces étapes n'avaient jamais besoin d'attendre du tout.
Elles ne routent pas. Elles ne bifurquent pas. Elles ne parallélisent pas. Elles font simplement la queue — une tête, un contexte, une chose à la fois, jusqu'à ce que la fenêtre se remplisse et que l'agent oublie ce qu'il faisait.
Suivez mon Substack pour obtenir de l'alpha IA fraîche :
Voici le plan en 14 étapes qui transforme cette file d'attente en graphe : un graphe qui se déploie sur une flotte, vérifie ses propres résultats et converge vers un résultat qu'un agent seul ne pourrait jamais contenir.
Voici le changement que personne ne formule explicitement. Une invite est une phrase. Une boucle est un cycle. Un harnais est le sol sur lequel l'agent se tient.
Mais la forme du travail lui-même — ce qui s'exécute avant quoi, ce qui peut s'exécuter en même temps, ce qui doit attendre tout le reste — cette forme est un graphe. Les nœuds font la réflexion. Les arêtes transportent les résultats.
Claude Code a livré les outils pour construire ces graphes directement : les workflows dynamiques.
Claude écrit un script d'orchestration en JavaScript pur, puis génère une flotte coordonnée de sous-agents pour l'exécuter — et la coordination elle-même ne coûte aucun token de modèle, car c'est du code, pas une conversation.
01. Les nœuds sont des tâches. Les arêtes sont ce qui circule.
Un graphe a exactement deux choses, et les comprendre clairement élimine la plupart des confusions. Un nœud est une unité de travail — un agent, une tâche délimitée, une entrée et une sortie.
Une arête est une dépendance : elle dit la sortie de ce nœud alimente l'entrée de ce nœud. Rien de plus.
L'erreur est de traiter « et puis » comme une arête. « Résume le fichier et puis donne-moi la météo » n'a pas d'arête entre les deux — la météo ne consomme pas le résumé.
Ce sont deux nœuds déconnectés qu'un script linéaire enchaîne inutilement. L'arête n'existe que lorsque des données se déplacent réellement à travers elle.
Apprenez à vous demander, pour chaque « et puis » dans votre agent : l'étape suivante lit-elle la sortie de l'étape précédente ? Si non, il n'y a pas d'arête, et l'attente est gaspillée.
1Dessinez-le comme des boîtes et des flèches. Une boîte est un appel agent().2Une flèche est une variable passée du retour d'un appel dans l'invite3d'un autre. Si vous ne pouvez pas dessiner la flèche - si aucune variable4ne traverse - les deux boîtes sont indépendantes, et l'indépendance est5ce que vous exploiterez pour le reste de ce cours.
02. Votre script linéaire est un graphe dégénéré
Lorsque vous écrivez un agent comme « fais A, puis B, puis C, puis D », vous avez dessiné un graphe — une chaîne unique sans branchement. Chaque nœud a exactement une arête entrante et une arête sortante.
Il s'exécute correctement. Mais il s'exécute aussi lentement et de manière fragile, car une chaîne n'a pas de redondance : si C bloque, D ne se produit jamais, et le travail de A est piégé en amont sans issue.
La première vraie compétence de l'ingénierie des graphes est de redessiner la chaîne. Prenez votre agent linéaire et, pour chaque arête, posez la question de l'Étape 1.
La plupart des chaînes ont deux ou trois arêtes qui ne transportent pas de données — elles sont simplement l'ordre dans lequel vous avez tapé les choses.
Coupez ces arêtes et la chaîne s'effondre en quelque chose de plus large : quelques nœuds indépendants qui pourraient tous s'exécuter en même temps, alimentant un seul nœud qui a besoin d'eux tous.
03. Donnez à chaque nœud un contrat
Un nœud sur lequel vous ne pouvez pas raisonner est un nœud que vous ne pouvez pas paralléliser. La solution est un contrat : entrée délimitée, sortie délimitée, exactement une tâche.
L'entrée est ce que le nœud lit — passé explicitement, jamais supposé à partir d'une fenêtre partagée. La sortie est une forme définie, idéalement validée, afin que le nœud suivant puisse la consommer sans deviner.
Dans un workflow, ce contrat est appliqué via un schéma. Lorsque vous passez à Claude un appel agent() avec un schéma JSON, le sous-agent que Claude génère est obligé de retourner des données structurées validées — la validation se produit au niveau de l'appel d'outil, donc Claude réessaie en cas d'inadéquation au lieu de vous donner du texte libre que vous devez analyser et espérer.
C'est la différence entre un nœud que Claude peut câbler dans un graphe et un nœud qui ne fonctionne que lorsqu'un humain lit sa sortie.
1// Un nœud avec un vrai contrat : entrée délimitée, sortie validée, une tâche.2const ITEM = {3 type: 'object', additionalProperties: false,4 properties: {5 title: { type: 'string' },6 url: { type: 'string' },7 impact: { type: 'string', enum: ['high', 'medium', 'low'] },8 },9 required: ['title', 'url', 'impact'],10};1112const result = await agent(source.prompt, {13 label: `research:${source.key}`,14 schema: ITEM, // force une sortie structurée validée15 agentType: 'general-purpose',16});17// result est maintenant une forme que le nœud suivant peut utiliser — pas du texte libre.
04. Traitez l'arête comme un contrat de données
Une arête n'est pas seulement « B vient après A ». C'est une promesse sur ce qui traverse : A produit cette forme, et B est conçu pour consommer cette forme. Lorsque vous nommez l'arête par ses données — pas par son ordre — deux choses deviennent plus faciles.
Vous pouvez voir instantanément si l'arête est réelle (est-ce que des données se déplacent réellement ?), et vous pouvez échanger le nœud à chaque extrémité sans casser le graphe, tant que la forme tient.
En pratique, l'arête vit en JavaScript pur. L'étape de réduction entre le déploiement et la synthèse — aplatir, dédupliquer, filtrer — est simplement du code opérant sur les formes que vos nœuds ont retournées.
Aucun agent nécessaire. L'un des gains discrets de la pensée graphe : une énorme quantité de ce pour quoi les gens brûlent des tokens de modèle est en réalité une arête, et les arêtes sont gratuites.
1La tentation est de générer un agent pour « combiner les résultats ». Résistez-y.2Si combiner signifie aplatir-et-dédupliquer, c'est results.flatMap(...)3et un Set — déterministe, instantané, zéro token. Réservez les agents pour4le jugement, pas pour la plomberie. Un graphe où chaque arête est un agent5est un graphe qui paie un loyer sur son propre câblage.
05. Déployez-vous avec parallel()
C'est la manœuvre qui paie pour tout le reste. Lorsque vous avez N nœuds indépendants — N sources à vérifier, N fichiers à examiner, N routes à auditer — vous ne les enchaînez pas.
Vous dites à Claude de les déployer et de les exécuter en même temps. Dans un workflow, c'est parallel() : Claude prend un tableau de thunks et génère un sous-agent par thunk, tous s'exécutant simultanément, puis vous renvoie le tableau des résultats.
Deux détails le rendent robuste. Premièrement, parallel() est une barrière — il attend que chaque thunk se termine avant de retourner, donc l'étape suivante voit l'ensemble complet. Deuxièmement, un thunk qui échoue se résout à null au lieu de rejeter tout le lot, donc un agent défaillant ne peut pas couler l'exécution.
Filtrez toujours avec .filter(Boolean) les résultats. La concurrence est plafonnée autour de votre nombre de cœurs et l'excédent fait la queue, donc vous pouvez passer une centaine de thunks et ils finiront tous — juste quelques-uns à la fois.
1phase('Research');23// Neuf sources, neuf agents, tous en même temps.4const raw = await parallel(5 SOURCES.map((s) => () =>6 agent(s.prompt, {7 label: `research:${s.key}`,8 phase: 'Research',9 schema: ITEM_SCHEMA, // chaque nœud retourne du JSON validé10 agentType: 'general-purpose',11 }),12 ),13);1415const collected = raw.filter(Boolean); // élimine les null des agents ayant échoué
Le déploiement vit dans le code écrit par Claude, pas dans une conversation de modèle. Le contexte de Claude lui-même ne contient jamais neuf sources à la fois — chaque sous-agent porte la sienne, et seule la réponse finale revient.
C'est ce qui permet à Claude de faire évoluer un workflow vers des dizaines ou des centaines de sous-agents sans noyer la session. La couche d'orchestration coûte zéro token car ce n'est pas un autre tour de réflexion de Claude.
06. Repliez-vous à une barrière
Un déploiement n'est utile que si quelque chose le rassemble. Le repli est le nœud où les arêtes convergent — où un agent (ou un morceau de code) voit tous les résultats amont à la fois et fait quelque chose qui nécessite l'ensemble : dédupliquer entre sources, classer par impact, sortie anticipée si le total est revenu vide. C'est le seul endroit où une barrière mérite son coût en temps réel.
La règle qui maintient les graphes rapides : utilisez une barrière uniquement lorsqu'une étape a vraiment besoin de tous les résultats précédents ensemble. Dédupliquer sur toutes les sources ? Barrière — correct.
1// L'arête : JS pur, pas d'agent, zéro token.2const flat = collected.flatMap((c) => c.items);3log(`Collected ${flat.length} items`);45phase('Curate');6// Le nœud barrière : a besoin de l'ensemble POUR dédupliquer + classer.7const curated = await agent(8 `Dedupe and rank these by impact:\n${JSON.stringify(flat)}`,9 { phase: 'Curate', schema: CURATED_SCHEMA },10);
Simplement aplatir une liste ? C'est une arête, faites-le en ligne. Le test de détection est brutal et simple : si vous avez écrit parallel → transform → parallel, et que cette transformation du milieu n'a pas de dépendance entre éléments, vous auriez dû utiliser un pipeline et sauter la barrière complètement.
07. Le losange : diviser → travailler → fusionner
Mettez ensemble le déploiement et le repli et vous obtenez la topologie de travail de tout graphe d'agent sérieux : le losange.
Un nœud divise la tâche, plusieurs nœuds font le travail en parallèle, un nœud fusionne. C'est la forme derrière un scan de marché, un audit de dépendances, une revue de code, un rapport de recherche — échangez les sources et les invites et le même squelette s'adapte.
La forme canonique a un nom qui mérite d'être mémorisé : déployer → réduire → synthétiser. Déployez pour obtenir de l'ampleur, réduisez avec du code pur pour la compresser, synthétisez avec un agent final pour écrire la réponse.
Une fois que vous voyez le losange, vous arrêtez de demander « comment faire faire plus d'étapes à mon agent » et commencez à demander « où est la division, où est la fusion » — ce qui est la question qui fait réellement évoluer.
08. Routez l'arête à l'exécution avec un conditionnel
Tous les graphes ne sont pas fixes. Parfois, l'arête à prendre dépend de ce qu'un nœud a trouvé. Un nœud routeur inspecte un résultat et décide quel chemin aval s'active — classifiez le ticket, puis bifurquez vers le bon gestionnaire ; vérifiez la taille du diff, puis soit faites une revue rapide, soit lancez un audit complet.
Dans un workflow, c'est simplement un if ou un switch JavaScript sur la sortie validée d'un nœud, car le flux de contrôle vit dans le code.
C'est là que le déterminisme devient une fonctionnalité, pas une limitation. La décision du routeur peut être alimentée par Claude (un sous-agent classifie), mais le routage est du code écrit par Claude — donc il s'exécute de la même manière à chaque fois pour la même classification.
Vous obtenez le jugement de Claude au nœud et la fiabilité du script à l'arête. Pas de surprise émergente « Claude a décidé de sauter l'audit » — car le saut devrait être écrit dans le graphe, et il ne l'est pas.
1// Nœud routeur : un agent classifie, le code choisit l'arête.2const { severity } = await agent(3 `Classify this diff's risk:\n${diff}`,4 { schema: { type: 'object',5 properties: { severity: { enum: ['low', 'high'] } },6 required: ['severity'] } },7);89let review;10if (severity === 'high') {11 // chemin lourd : audit parallèle complet12 review = await parallel(FILES.map((f) => () => agent(`Audit ${f}`)));13} else {14 // chemin léger : un passage rapide15 review = await agent(`Quick review of ${diff}`);16}
09. Mettez un vérificateur sur l'arête
Le vrai levier d'un graphe n'est pas plus d'agents — c'est la structure que vous pouvez mettre autour d'eux pour produire de la confiance.
Un nœud vérificateur se place sur l'arête avant qu'un résultat ne soit autorisé en aval, et son seul travail est d'essayer de tuer la découverte. Si elle survit, elle passe. Sinon, elle n'atteint jamais la réponse.
Trois modèles valent la peine d'être en main.
- Vérification antagoniste : pour chaque découverte, générez N sceptiques indépendants invités à la réfuter ; ne la gardez que si une majorité survit.
- Vérification à perspectives diverses : donnez à chaque vérificateur une lentille distincte — exactitude, sécurité, reproductibilité — car la diversité attrape les modes de défaillance que N vérifications identiques ne détecteront jamais.
- Panel de juges : générez N tentatives sous différents angles, notez-les avec des juges en parallèle, synthétisez à partir du gagnant tout en greffant le meilleur des finalistes.
C'est exactement le modèle qui a permis à une vraie équipe de porter le runtime Bun avec une revue de code antagoniste intégrée dans la boucle.
10. Isolez les nœuds pour qu'un échec ne puisse pas empoisonner le graphe
Dans une chaîne, un échec cascade — C meurt, D ne tourne jamais, tout s'arrête. Dans un graphe, l'échec doit être confiné à son nœud.
C'est déjà partiellement vrai : un thunk qui échoue à l'intérieur de parallel() se résout à null, donc huit bons agents retournent encore tandis qu'un mauvais tombe. Votre .filter(Boolean) est le confinement.
Concevez chaque repli pour tolérer des entrées manquantes plutôt que de supposer un ensemble complet.
L'échec plus subtil est celui des nœuds qui se marchent sur les pieds. Lorsque les agents écrivent des fichiers en parallèle, ils peuvent entrer en collision.
La solution est l'isolement : "worktree" — chaque agent s'exécute dans son propre worktree git, fait son travail dans un bac à sable, et fusionne proprement.
Utilisez-le uniquement lorsque les nœuds écrivent réellement en parallèle. C'est la ceinture de sécurité pour la seule topologie qui en a besoin, pas une taxe par défaut sur chaque exécution.
11. Ajoutez un cycle — mais faites-le converger
Parfois, vous ne savez pas quelle est la taille de la tâche avant d'être dedans : découverte de taille inconnue, une chasse aux bugs où trouver un bug en révèle trois autres. Cela nécessite un cycle — une arête contrôlée vers un nœud antérieur.
Le danger est évident : un cycle qui ne converge pas est une boucle infinie qui génère des agents jusqu'à épuisement de votre budget.
Le modèle qui converge est boucle-jusqu'à-épuisement : continuez à générer des chercheurs jusqu'à ce que K tours consécutifs ne remontent rien de nouveau, puis arrêtez. Le détail qui fait ou défait tout — et l'erreur que presque tout le monde fait la première fois — est ce contre quoi vous dédupliquez.
Dédupliquez contre tout ce qui a été vu, pas seulement contre les résultats confirmés. Sinon, les découvertes rejetées réapparaissent à chaque tour, la boucle ne s'épuise jamais, et vous avez construit une machine qui paie pour redécouvrir les mêmes impasses pour toujours.
1const seen = new Set(); const confirmed = []; let dry = 0;23while (dry < 2) { // s'arrête après 2 tours vides4 const found = (await parallel(5 FINDERS.map((f) => () => agent(f.prompt, { schema: BUGS }))6 )).filter(Boolean).flatMap((r) => r.bugs);78 const fresh = found.filter((b) => !seen.has(key(b)));9 if (!fresh.length) { dry++; continue; } // rien de nouveau → vers l'épuisement10 dry = 0;11 fresh.forEach((b) => seen.add(key(b))); // déduplique contre VU, pas confirmé1213 // vérification à lentilles diverses pour chaque nouvelle découverte avant qu'elle compte14 const judged = await parallel(fresh.map((b) => () =>15 parallel(['correctness', 'security', 'repro'].map((lens) => () =>16 agent(`Judge "${b.desc}" via ${lens} — real?`, { schema: VERDICT })))17 .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))));1819 confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));20}
12. Hiérarchisez les modèles à travers les nœuds
Tous les nœuds n'ont pas besoin de votre meilleur modèle. Un graphe rend cela évident d'une manière qu'un agent unique ne fait jamais : certains nœuds sont délimités et répétitifs (extraire ce champ, classer ce ticket), et d'autres portent le vrai jugement (synthétiser le rapport, trancher la découverte).
Exécutez les nœuds ennuyeux sur un modèle moins cher et dépensez vos tokens coûteux là où le jugement vit réellement.
Dans un workflow, chaque sous-agent que Claude génère hérite du modèle de votre session, sauf si le script le remplace — donc par défaut, une grande exécution facture entièrement au niveau de votre session. L'option model sur un seul appel agent() dit à Claude de router juste ce nœud ailleurs.
Vérifiez /model avant une grande exécution, puis faites router par Claude les nœuds répétitifs du déploiement vers un modèle moins cher et gardez le nœud de fusion en haut. C'est le levier qui transforme un graphe gourmand en tokens de coûteux à économique sans toucher à sa forme.
13. La topologie est votre coût et votre latence
La forme du graphe n'est pas cosmétique — c'est le levier le plus important sur le temps réel. Le choix qui bloque tout le monde : parallel() contre pipeline(). Une barrière parallel() fait tout attendre le nœud le plus lent avant que l'étape suivante ne commence.
Un pipeline() fait passer chaque élément à travers toutes les étapes indépendamment, sans barrière — l'élément A peut être à l'étape 3 pendant que l'élément B est encore à l'étape 1. Les éléments rapides finissent tôt au lieu de rester inactifs derrière les lents.
Par défaut, utilisez pipeline(). N'utilisez une barrière que lorsqu'une étape a vraiment besoin de tous les résultats précédents à la fois — une déduplication croisée, une sortie anticipée sur le total, une invite qui compare avec « les autres résultats ». « C'est du code plus propre » et « les étapes semblent séparées » ne sont pas des raisons ; la latence de barrière est réelle, mesurable, du temps perdu. Séparé n'est pas la même chose que synchronisé.
14. Laissez Claude dessiner le graphe — auto-routage
La manœuvre finale est d'arrêter de dessiner le graphe à la main pour les tâches que vous ne pouvez pas planifier à l'avance.
Avec les workflows dynamiques, vous décrivez l'objectif et Claude écrit lui-même le script d'orchestration — décomposant la tâche, choisissant le déploiement, générant une flotte coordonnée de sous-agents, et synthétisant le résultat. Vous obtenez un graphe adapté à cette exécution au lieu d'un graphe fixe que vous espériez convenir.
Il y a trois façons d'entrer. Dites le mot "workflow" dans votre invite et Claude en écrit un pour la tâche. Exécutez-en un sauvegardé ou intégré — /deep-research est un vrai graphe en production : portée → recherche parallèle → récupération → vérification antagoniste → synthétiser, exactement le squelette de ce cours.
Ou activez l'ultracode et Claude planifie un workflow pour chaque tâche substantielle dans la session. Lorsqu'une exécution est bonne, appuyez sur s pour sauvegarder son script dans .claude/workflows/ — versionné, réexécutable par nom, un graphe que quiconque clone le dépôt peut lancer.
1› Exécutez un workflow pour auditer chaque route sous src/routes/ pour2l'absence d'authentification. Générez un agent par fichier de route, puis3vérifiez chaque découverte avant de rapporter. ● Claude a écrit un script4d'orchestration · lancement en arrière-plan… /workflows — auth-audit ·5en cours ✓ Scope 1/1 2.1k tok · 4s ✓ Déploiement 18/18 un agent par6fichier de route ◯ Vérification 11/18 3 votes sceptiques par découverte…7○ Synthèse 0/1 en attente de vérification la session reste réactive —8continuez à travailler pendant que la flotte s'exécute
Six graphes à construire avec Claude cette semaine
- Balayage de sécurité sur chaque route. Claude génère un sous-agent par fichier de route, chacun à la recherche de vérifications d'authentification manquantes, puis un passage de vérificateur confirme chaque découverte avant qu'elle n'atteigne le rapport. Une ampleur qu'aucun contexte unique ne pourrait contenir.
- Rapport cité avec /deep-research. Un graphe qui est déjà livré dans Claude Code. Claude décompose votre question en angles distincts, exécute des recherches parallèles, déduplique les sources, puis vérifie de manière antagoniste chaque affirmation avec trois votes sceptiques avant d'écrire.
- Portez un module, fichier par fichier. Le plafond Bun, adapté à votre dépôt. Claude déploie la traduction sur les fichiers, exécute la suite de tests comme porte sur chacun, et renvoie les échecs en boucle — la revue antagoniste attrape ce qu'un seul passage livrerait cassé.
- Revue antagoniste d'un diff. Claude route en fonction de la taille du diff : un petit changement reçoit un passage rapide, un grand déclenche un audit parallèle complet avec des réviseurs sur des lentilles distinctes — exactitude, sécurité, performance — puis un panel de juges synthétise.
- Scan d'écosystème sur un calendrier. Sauvegardez-le une fois, réexécutez-le pour toujours. Claude vérifie de nombreuses sources en parallèle — versions, blogs, discussions — classe par impact à une barrière, et écrit le digest. Versionné dans .claude/workflows/, lançable par nom.
- Découverte de taille inconnue. Vous ne savez pas combien de bugs il y a. Claude exécute des chercheurs en parallèle, déduplique chaque nouvelle découverte contre tout ce qui a été vu, vérifie les survivants, et continue à boucler jusqu'à ce que deux tours ne remontent rien de nouveau — puis s'arrête.
Conclusion :
Un prompteur pose une question. Un architecte dessine un graphe.
L'agent linéaire n'a jamais été le plafond — c'était juste la première forme, celle que tout le monde utilise parce qu'elle correspond à la façon dont on tape. Une ligne, une tête, une chose à la fois.
Une fois que vous pouvez voir les nœuds et les arêtes, vous arrêtez de demander à l'agent d'en faire plus et commencez à demander au graphe de le faire plus large : déployez là où le travail est indépendant, verrouillez les arêtes là où la confiance compte, hiérarchisez les modèles là où le jugement n'est pas nécessaire.
La plupart des gens continueront à mettre les étapes en file d'attente. Ceux qui apprennent à dessiner le graphe piloteront une flotte — et ne remarqueront jamais le plafond sous lequel les autres sont coincés.
