Les 7 agentic workflow design patterns qui comptent en 2026

Comment nous avons choisi ces sept patterns

Il n'existe pas de liste canonique des agentic design patterns, alors le plus honnête est de dire d'où vient la nôtre. Nous n'avons gardé que les patterns qui apparaissent sous un nom stable dans plus d'une source primaire. Le billet d'ingénierie d'Anthropic, Building Effective AI Agents, fournit cinq patterns de workflow plus l'agent autonome. La documentation LangGraph utilise les mêmes cinq noms pour les mêmes formes. Le Google Agent Development Kit en livre trois comme types d'agents de première classe. Les quatre patterns très cités d'Andrew Ng recouvrent tout cela sous d'autres étiquettes, donc quand un pattern porte deux noms courants nous donnons les deux, parce que les gens cherchent les deux. Le septième, le checkpoint humain, est ici parce que l'OpenAI Agents SDK et LangGraph le livrent tous les deux comme une primitive documentée plutôt que comme un conseil.

• Nommé dans une source primaire: il apparaît sous ce nom dans les écrits d'ingénierie d'un éditeur ou dans la documentation d'un framework, pas seulement dans un article de synthèse.
• Nommé deux fois: si les praticiens l'appellent de deux façons, les deux noms sont listés, parce que les deux sont tapés dans une barre de recherche.
• Constructible aujourd'hui: une implémentation qui fonctionne existe dans un framework livré, vous pouvez donc utiliser le pattern au lieu de l'admirer.
• Il a un vrai mode de défaillance: nous pouvons nommer ce qui casse en premier, ce qui est un test plus dur que d'énoncer ce pour quoi il est bon.
• Il a une règle pour l'éviter: il existe un cas concret où une simple fonction, une file d'attente ou un cron job fait mieux, et nous le disons.
• Composable: il s'imbrique dans les six autres au lieu de les remplacer.
• Coût visible: nous pouvons dire en termes relatifs ce que le pattern fait à votre facture de tokens.

Chaque nom de pattern, chaque comportement de framework cité et chaque multiplicateur de coût ici a été lu à la source de l'éditeur en août 2026. Les API des frameworks bougent vite et les noms d'arguments vont dériver. Les noms des patterns sont stables depuis qu'Anthropic les a publiés, et c'est pour cela qu'ils sont la partie qui vaut la peine d'être mémorisée.

Les sept patterns en un coup d'oeil

De quoi sont réellement faits les agentic workflows? De sept formes: une chaîne, un aiguillage, un fan-out, un manager avec des workers, une boucle avec un juge, une boucle avec des outils, et une porte avec une personne derrière. Si vous cherchiez un schéma d'agentic AI workflow, cette liste est ce qu'il contiendrait. Prenez celle qui correspond au travail que vous avez, puis lisez sa règle d'exclusion avant d'écrire la moindre ligne de code. Apprendre à reconnaître la forme en premier, c'est l'essentiel de ce que nous enseignons dans le cours sur l'automatisation et les systèmes agentiques à Agentic School.

• Prompt chaining: une séquence fixe d'appels au modèle où chacun travaille sur la sortie du précédent.
• Routing: une étape de classification bon marché qui envoie chaque entrée vers le handler spécialisé de son type.
• Parallelization: le même travail éclaté en appels concurrents, soit découpé en sections, soit soumis à un vote.
• Orchestrator-workers: un modèle lead invente des sous-tâches à l'exécution, les délègue et fusionne les résultats.
• Evaluator-optimizer: un modèle rédige, un autre le note contre une grille, et le texte est révisé jusqu'à ce qu'il passe ou que le budget soit épuisé.
• L'autonomous tool loop: le modèle choisit lui-même ses outils dans une boucle et décide quand il a terminé.
• Human-in-the-loop checkpoint: le run se met en pause avant une action choisie et attend qu'une personne l'approuve, la modifie ou la rejette.

Prompt chaining

Prompt chaining découpe une tâche en une séquence fixe d'appels au modèle, chacun prenant la sortie précédente comme entrée. Anthropic le liste en premier, LangGraph le documente sous le même nom, et le Google Agent Development Kit le livre comme Sequential Agent, que sa documentation qualifie de déterministe et prévisible parce qu'il fixe l'ordre d'exécution sans consulter de modèle. On le cherche aussi comme sequential workflow ou LLM pipeline. Prenez-le en premier parce que l'ordre vit dans votre code: vous pouvez glisser une vérification ordinaire entre deux étapes et abandonner avant de payer l'appel suivant, ce qui est le quality gate le moins cher de cette page. Vous payez en latence et en accumulation: trois appels chaînés font trois allers-retours, et l'étape trois hérite de chaque erreur de l'étape une.

• Ce que c'est: une séquence fixe, définie dans le code, d'appels au modèle, chacun consommant la sortie du précédent.
• Utilisez-le quand: la tâche se décompose en étapes que vous pouvez nommer à l'avance, par exemple plan, puis brouillon, puis réécriture du ton.
• Évitez-le quand: un seul prompt bien écrit passe déjà votre évaluation. Le découper à ce moment-là achète de la latence et rien d'autre.
• Ce qui casse en premier: l'accumulation silencieuse. Une mauvaise étape une donne une étape trois assurée, bien formatée et fausse, donc validez entre les maillons, pas seulement à la fin.

Routing

Routing place un appel de classification bon marché devant plusieurs handlers spécialisés et envoie chaque entrée vers le bon. Anthropic et LangGraph le nomment tous les deux routing; l'OpenAI Agents SDK en implémente une version décentralisée via les handoffs, qu'il décrit comme un mécanisme pour coordonner et déléguer le travail entre plusieurs agents. L'économie est tout l'intérêt: un prompt de classification court sur un petit modèle envoie la majorité facile du trafic sur un chemin bon marché et réserve le modèle cher au reste. La contrepartie, c'est qu'une erreur de routage est silencieuse. Le handler spécialisé répond avec assurance dans la mauvaise voie, et si vous ne loguez pas la route choisie à côté du résultat, vous ne le verrez jamais arriver.

• Ce que c'est: une étape de classification qui aiguille une entrée vers un parmi plusieurs prompts, modèles ou outils spécialisés en aval.
• Utilisez-le quand: les entrées tombent dans des catégories distinctes qui demandent un traitement différent, et un prompt unique pour toutes régresse sans arrêt.
• Évitez-le quand: la catégorie se décide à partir de données structurées. Une vérification de champ ou une expression régulière est gratuite, instantanée et n'hallucine jamais une catégorie.
• Ce qui casse en premier: la mauvaise classification silencieuse. Loguez la route avec le résultat, et livrez toujours une branche par défaut pour les entrées qui ne correspondent à rien.

Parallelization

Parallelization lance plusieurs appels au modèle en même temps et combine les résultats. Anthropic le divise en deux variantes qu'il vaut la peine de séparer: sectioning, où des sous-tâches indépendantes tournent en concurrence, et voting, où la même tâche tourne plusieurs fois et vous prenez le consensus. LangGraph documente les deux sous parallelization et le Google Agent Development Kit livre la forme comme Parallel Agent. Sectioning achète du temps réel. Voting achète de la confiance sur les jugements où un seul échantillon n'est pas fiable, par exemple signaler un contenu risqué. Aucun des deux n'est gratuit: vous payez plein tarif pour chaque branche, donc un vote à cinq coûte environ cinq appels et rend une seule réponse.

• Ce que c'est: le même travail éclaté en appels concurrents, soit découpé en sections indépendantes, soit répété pour un vote.
• Utilisez-le quand: les sous-tâches ne dépendent vraiment pas les unes des autres, ou quand un seul échantillon d'un jugement n'est pas assez fiable pour agir dessus.
• Évitez-le quand: les étapes dépendent les unes des autres. Forcer une chaîne dépendante en branches parallèles produit des contradictions que vous réconciliez ensuite à la main.
• Ce qui casse en premier: la facture et le merge. Le coût suit le fan-out, et l'étape qui combine des branches en désaccord est là où vivent la plupart des vrais bugs.

Orchestrator-workers

Avec orchestrator-workers, un modèle lead découpe un travail en sous-tâches à l'exécution, les délègue à des workers et synthétise les résultats. On l'appelle aussi planner-executor, supervisor, ou lead agent et subagents, et les patterns planning et multi-agent collaboration d'Andrew Ng atterrissent tous les deux ici. La différence avec parallelization, c'est que personne ne décide des sous-tâches à l'avance; l'orchestrateur les invente à partir de l'entrée. Anthropic a utilisé exactement cela pour son système de recherche multi-agent, avec un lead agent qui coordonne pendant que des subagents spécialisés travaillent en parallèle. C'est aussi de loin le pattern le plus cher ici: Anthropic indique que les systèmes multi-agent consomment environ 15x plus de tokens que les interactions de chat, et dit clairement qu'ils ne sont économiquement justifiés que si la tâche vaut assez cher pour les payer. Anthropic nomme aussi les cas où il sous-performe, et la réponse est instructive: les domaines où chaque agent a besoin du même contexte ou où les sous-tâches ont beaucoup de dépendances, le coding étant cité comme ayant moins de sous-tâches réellement parallélisables que la recherche.

• Ce que c'est: un modèle lead décompose la tâche à l'exécution, délègue les morceaux à des workers et fusionne ce qui revient.
• Utilisez-le quand: les sous-tâches sont imprévisibles, le travail se parallélise vraiment, et la sortie vaut à peu près un ordre de grandeur de tokens en plus.
• Évitez-le quand: chaque worker a besoin du même contexte, ou les sous-tâches dépendent les unes des autres. Anthropic nomme les deux comme les conditions où multi-agent sous-performe.
• Ce qui casse en premier: le coût et la coordination. À environ 15x les tokens d'un tour de chat, déboguer un orchestrateur cassé est en soi une ligne de budget.

Evaluator-optimizer

Evaluator-optimizer met un générateur et un critique dans une boucle: un modèle rédige, un second le note contre une grille, et le brouillon est révisé jusqu'à ce qu'il passe ou que le budget soit épuisé. Anthropic et LangGraph utilisent tous les deux le nom evaluator-optimizer; la version à un seul modèle est ce qu'Andrew Ng appelle reflection, défini dans sa lettre DeepLearning.AI comme le LLM qui examine son propre travail pour trouver des façons de l'améliorer. Il vaut bien plus cher quand l'évaluateur n'est pas un modèle du tout. Une suite de tests, un type checker ou un validateur de schéma rend un passe ou échoue net au lieu d'un avis plausible, et c'est pour cela que ce pattern est la colonne vertébrale d'un agentic coding workflow. La panne est célèbre et évitable: sans borne et avec une grille vague, le duo réécrit le même paragraphe quarante fois, chaque version différente et aucune meilleure.

draft = generate(task)

for attempt in range(MAX_ROUNDS):  # borne, jamais ouvert
    verdict = evaluate(draft)      # une grille, un run de tests, un type check
    if verdict.passes:
        break
    draft = generate(task, feedback=verdict.notes)

return draft, attempt  # loguez le nombre de tours: une tendance à la hausse est le signal précoce

• Ce que c'est: une boucle générer, critiquer, réviser qui tourne jusqu'à atteindre un seuil de qualité explicite ou une limite de tours.
• Utilisez-le quand: la qualité est mesurable et le premier brouillon est régulièrement proche mais pas juste, surtout quand l'évaluateur peut être un test plutôt qu'un modèle.
• Évitez-le quand: vous ne pouvez pas écrire la grille. Un évaluateur sans critères clairs produit une agitation qui ressemble à du progrès et coûte comme du progrès.
• Ce qui casse en premier: la boucle qui ne se termine jamais. Bornez les tours, exigez que le score progresse pour en mériter un de plus, et loguez combien de tours chaque run a pris.

L'autonomous tool loop

L'autonomous tool loop est ce que la plupart des gens veulent dire quand ils disent agent: le modèle reçoit des outils et un objectif, choisit quel outil appeler, lit le résultat, et décide lui-même s'il en appelle un autre ou s'il s'arrête. On l'appelle aussi ReAct, agent loop, ou simplement tool use, ce dernier étant le nom qu'en donne Andrew Ng. Anthropic définit les agents comme des systèmes où le modèle dirige dynamiquement ses propres processus et son usage des outils, ce qui est exactement la ligne entre ce pattern et les six autres. C'est le seul où vous ne connaissez pas le chemin à l'avance, et c'est à la fois le but et le prix: Anthropic indique que les agents consomment environ 4x plus de tokens que les interactions de chat et prévient que les systèmes agentiques échangent latence et coût contre performance sur la tâche. Utilisez-le là où vous ne pouvez pas prédire la route mais pouvez encore vérifier le résultat. Construire cette boucle à la main est traité dans notre guide sur la construction d'un AI agent depuis zéro, cette page reste donc sur la question de sa place.

• Ce que c'est: un modèle avec des outils qui tourne en boucle, choisissant sa prochaine action et son propre point d'arrêt.
• Utilisez-le quand: le chemin ne peut pas être codé en dur parce qu'il dépend de ce que les étapes précédentes découvrent, et que le résultat final reste vérifiable.
• Évitez-le quand: les étapes sont connues à l'avance. Vous payez environ 4x les tokens et ajoutez du non-déterminisme pour reproduire ce qu'une chaîne scriptée fait déjà correctement.
• Ce qui casse en premier: la panne d'outil silencieuse. Un outil qui renvoie une chaîne en cas d'erreur laisse le modèle lire l'échec comme une donnée et continuer, donc rendez les échecs typés et bruyants.

Human-in-the-loop checkpoint

Le human-in-the-loop checkpoint met un run en pause avant une action choisie et attend qu'une personne l'approuve, la modifie ou la rejette. C'est un vrai pattern avec de vraies primitives, pas un avertissement: l'OpenAI Agents SDK liste human in the loop parmi ses mécanismes intégrés pour impliquer des humains pendant les runs d'agent, et LangGraph l'implémente comme un interrupt dont l'usage documenté est la pause avant des actions critiques telles que les appels API, les modifications de base de données et les transactions financières, avec l'option de modifier les arguments du tool call avant leur exécution. Cette capacité de modification est la moitié sous-estimée. Approuver un mauvais appel est un pile ou face; corriger l'argument et continuer transforme le checkpoint en un signal que vous pouvez replier dans le prompt. Le mode de défaillance ici est humain: mettez une barrière devant trop d'actions et le relecteur se met à tamponner sans lire, ce qui est pire que pas de barrière du tout parce que cela fabrique l'apparence d'un contrôle.

• Ce que c'est: une pause explicite avant une action sélectionnée, où une personne l'approuve, modifie ses arguments, ou la rejette.
• Utilisez-le quand: l'action est irréversible, financière, visible par le client ou difficile à détecter quand elle est fausse. Ajustez la barrière au coût d'une erreur.
• Évitez-le quand: l'action est bon marché, réversible et à fort volume. Une barrière là n'achète rien et entraîne le relecteur à cliquer approuver sans lire.
• Ce qui casse en premier: le tampon automatique. Mettez une barrière devant peu d'actions vraiment dangereuses, montrez les arguments exacts, et laissez le relecteur réparer l'appel plutôt que seulement l'accepter ou le refuser.

Agentic workflow ou automatisation classique

Voici le test, et il prend dix secondes: si les étapes sont connues à l'avance et les entrées structurées, ce n'est pas un agentic workflow, et en faire un coûte de l'argent et ajoute des modes de défaillance. Anthropic trace la même ligne, définissant les workflows comme des systèmes où modèles et outils sont orchestrés par des chemins de code prédéfinis, et les agents comme des systèmes où le modèle dirige dynamiquement son propre processus. LangGraph le formule presque à l'identique. Le Google Agent Development Kit qualifie ses workflow agents prédéfinis de déterministes et prévisibles précisément parce qu'ils fixent la séquence d'exécution sans consulter de modèle. La vraie question n'est donc jamais de savoir si les agents sont bons. Elle est de savoir si la décision que vous confiez à un modèle est bien une décision, ou juste une branche que vous ne vouliez pas écrire. L'agentic AI workflow automation ne mérite son supplément que lorsque l'étape suivante dépend de ce qu'une étape antérieure a trouvé.

• Étapes connues à l'avance, entrées structurées: prenez un script, une file d'attente ou un outil de workflow automation. Aucun modèle n'est nécessaire nulle part dedans.
• Étapes connues à l'avance, une étape demande du langage ou du jugement: prenez un workflow simple avec un seul appel au modèle dedans. Ce n'est toujours pas un agentic workflow.
• Les étapes dépendent de ce que les étapes précédentes découvrent, et le résultat est vérifiable: c'est là qu'un agentic workflow mérite son coût.
• Étapes imprévisibles et résultat non vérifiable: ne l'automatisez pas encore. Une boucle autonome invérifiable ne génère qu'une sortie assurée que personne ne peut contrôler.
• Vérification du coût d'abord: Anthropic indique les agents à environ 4x les tokens d'une interaction de chat et les systèmes multi-agent à environ 15x. Multipliez par votre volume avant de vous engager.

Les modes de défaillance et le guardrail de chacun

Les AI agentic workflows échouent de cinq façons reconnaissables, et chacune a un guardrail nommé, bon marché avant le lancement et cher à rétrofitter après un incident. Notez qu'aucune n'est un problème de qualité de modèle. Un meilleur modèle fait arriver chaque panne plus tard et coûter davantage quand elle arrive, et c'est pourquoi les équipes qui sortent d'un incident par une montée de version en récupèrent une version plus grosse un trimestre plus tard. Les guardrails sont aujourd'hui documentés plutôt qu'improvisés: l'OpenAI Agents SDK livre des guardrails d'entrée et de sortie dont le tripwire se déclenche immédiatement et arrête le run, et les guardrails d'entrée peuvent tourner en mode bloquant pour qu'une mauvaise requête soit rejetée avant qu'un seul token ne soit dépensé. Nous traitons cette liste comme le minimum dans la leçon human-in-the-loop à Agentic School.

• Les boucles qui ne se terminent jamais: bornez chaque boucle avec un nombre maximum de tours et exigez une amélioration mesurable pour en mériter un de plus. Un retry sans borne est la cause la plus fréquente d'une facture surprise.
• Les pannes d'outil silencieuses: un outil qui renvoie une chaîne d'erreur laisse le modèle lire l'échec comme une donnée et poursuivre. Renvoyez des échecs typés et arrêtez le run sur ceux dont il ne peut pas se remettre.
• Les explosions de coût au retry: plafonnez la dépense par run, pas seulement par mois, et faites fail closed au plafond. Une logique de retry multipliée par un profil de tokens multi-agent à 15x, c'est ainsi qu'un seul run de test dépasse un budget mensuel.
• Pas de checkpoint humain: interrompez avant les actions irréversibles, ce que LangGraph documente spécifiquement pour les appels API, les modifications de base de données et les transactions financières, et laissez le relecteur modifier les arguments.
• Aucun moyen de rejouer ce qui s'est passé: persistez le run. Les checkpointers LangGraph sauvegardent l'état du thread pour le time travel et la tolérance aux pannes, et l'OpenAI Agents SDK livre le tracing pour visualiser, déboguer et monitorer les workflows. Sans cela, chaque revue d'incident est de la devinette.

Les sept agentic design patterns comparés

Ces sept se composent, et la plupart des agentic AI workflows en production sont trois d'entre eux câblés ensemble. Chaque ligne ci-dessous porte les mêmes quatre choses dans le même ordre: qui contrôle le chemin, ce que cela coûte par rapport à un appel unique, ce à quoi c'est le meilleur, et ce qu'il faut surveiller. Rien ici n'est neuf; chaque fait figure dans la section au-dessus.

• Prompt chaining: chemin contrôlé par votre code, un appel par étape, meilleur pour les tâches que vous pouvez décomposer à l'avance, surveillez les erreurs qui s'accumulent le long de la chaîne.
• Routing: chemin contrôlé par un appel de classification, un appel bon marché plus un handler, meilleur pour les types d'entrée mélangés, surveillez la mauvaise classification silencieuse.
• Parallelization: chemin contrôlé par votre code, coût multiplié par le fan-out, meilleur pour les sous-tâches indépendantes ou les votes de consensus, surveillez le merge et la facture.
• Orchestrator-workers: chemin contrôlé par un modèle lead à l'exécution, environ 15x une interaction de chat selon Anthropic, meilleur pour un travail à forte valeur qui se parallélise, surveillez les tâches à contexte partagé.
• Evaluator-optimizer: chemin contrôlé par un seuil de qualité, un appel par tour, meilleur quand la qualité est mesurable et idéalement testable, surveillez les boucles de réécriture sans borne.
• L'autonomous tool loop: chemin contrôlé par le modèle, environ 4x une interaction de chat selon Anthropic, meilleur quand la route est imprévisible mais le résultat vérifiable, surveillez les pannes d'outil silencieuses.
• Human-in-the-loop checkpoint: chemin contrôlé par une personne en un point, presque zéro en tokens et bien réel en temps écoulé, meilleur avant les actions irréversibles, surveillez le tampon automatique.

Quel agentic workflow pattern choisir

Trois choses le décident, et aucune n'est de savoir quel pattern est le plus intéressant. Premièrement, qui doit contrôler le chemin: si vous pouvez nommer les étapes, votre code doit les posséder et le modèle ne remplir que les parties qui demandent du langage. Deuxièmement, si la sortie est vérifiable, parce qu'un pattern que vous ne pouvez pas contrôler est un pattern que vous ne pouvez pas automatiser sans risque. Troisièmement, ce que votre volume fait au multiplicateur de tokens, puisqu'un supplément de 4x ou 15x, trivial sur dix runs par semaine, devient une ligne de budget à dix mille.

Si vous êtes un fondateur seul qui automatise ses propres opérations, commencez par prompt chaining plus un checkpoint humain sur tout ce qui touche à l'argent ou à un client, et n'ajoutez routing que lorsque vous pouvez pointer les types d'entrée qui cassent sans arrêt un prompt unique. Si vous construisez un agentic coding workflow, utilisez l'autonomous tool loop avec votre suite de tests comme évaluateur plutôt qu'un second modèle qui note de la prose, et bornez les tours. Si orchestrator-workers vous tente, attendez que les sous-tâches soient vraiment inconnues à l'avance, vraiment parallèles et valent à peu près quinze fois les tokens, parce que tout ce qui est en deçà tourne mieux et moins cher en chaîne.

Les patterns ci-dessus, les guardrails et les builds dont ils viennent sont enseignés de bout en bout dans les cours gratuits d'Agentic School.

Questions fréquemment posées

Continuez à apprendre