Orchestrer plusieurs agents IA dans n8n : le pattern superviseur/spécialistes

Le cluster d'articles sur l'AI Agent vous a peut-être menés jusqu'ici : votre agent tourne, il a ses outils, sa mémoire — et son prompt système commence à ressembler à un règlement intérieur de vingt paragraphes. « Si la question porte sur la doc, fais ceci ; si c'est un client existant, fais cela ; réponds toujours sur ce ton, sauf quand… » C'est le signal typique qu'un agent unique arrive à saturation. La réponse n'est pas d'allonger encore le prompt : c'est de découper en plusieurs agents spécialisés, orchestrés par un superviseur. Cet article détaille comment construire ce pattern dans n8n — et surtout quand ne pas le faire.

D'abord, l'avertissement honnête : un seul agent suffit souvent

Commençons par ce que les démos multi-agents oublient de dire : dans la majorité des cas de production, un seul AI Agent bien configuré fait le travail. Un system message clair, 5 à 7 outils bien décrits, une mémoire adaptée — et vous avez un système simple à déboguer, rapide et économique.

Chaque agent supplémentaire dans votre architecture ajoute trois taxes bien réelles :

• Le coût : chaque délégation déclenche des appels LLM en plus — le raisonnement du spécialiste, puis la relecture du superviseur. Une conversation qui coûtait un appel peut en coûter cinq ou six.
• La latence : les appels s'empilent en série. Un superviseur qui consulte deux spécialistes avant de répondre triple facilement le temps de réponse.
• Le débogage : quand la réponse finale est mauvaise, la cause peut être dans le routage du superviseur, dans le prompt d'un spécialiste, dans un de ses outils, ou dans la synthèse finale. Quatre étages de suspects au lieu d'un.

Le multi-agents ne se justifie que sur des symptômes précis : un prompt système devenu fourre-tout de consignes contradictoires, plus de 7 ou 8 outils qui commencent à se confondre, ou des tâches aux exigences incompatibles (« sois exhaustif et technique » pour la recherche, « sois bref et chaleureux » pour la réponse client). Tant que vous n'avez pas ces symptômes, restez sur un agent.

Ce que dit la recherche

L'idée de faire coopérer des agents spécialisés n'est pas un caprice d'architecte. Les travaux de Wu et ses coauteurs sur AutoGen (2023), framework de référence du domaine, montrent que des agents LLM spécialisés qui conversent entre eux résolvent certaines classes de tâches complexes mieux qu'un agent monolithique — précisément parce que chaque agent garde un rôle et un contexte resserrés.

Mais la même littérature invite à la prudence : le survey de Guo et ses coauteurs, « Large Language Model based Multi-Agents » (2024), dresse le panorama des architectures multi-agents et pointe leurs limites persistantes : coordination fragile entre agents, coût qui explose avec le nombre d'échanges, et difficulté à évaluer le système global. Autrement dit : la spécialisation paie, l'orchestration se paie.

Le pattern superviseur/spécialistes dans n8n

Le principe : un agent superviseur reçoit la demande de l'utilisateur et ne fait qu'une chose — comprendre l'intention et déléguer au bon spécialiste, exposé comme un outil parmi ses outils. Le superviseur n'a pas d'outil « métier » ; ses outils sont les autres agents.

n8n offre deux mécanismes pour brancher un agent comme outil d'un autre :

1. Un agent branché directement comme outil. Sous la connexion ai_tool du superviseur, vous branchez un second agent, avec son propre modèle, son propre prompt système court et ses propres outils. Tout vit dans le même workflow — pratique pour prototyper, moins pour maintenir.
2. Le sub-workflow appelé comme outil (Call n8n Workflow Tool). Le spécialiste vit dans son propre workflow, avec son AI Agent, son prompt et ses outils, et le superviseur l'appelle via un toolWorkflow. C'est l'approche que nous recommandons dès que le système dépasse le prototype : chaque spécialiste se teste, se versionne et se réutilise indépendamment, exactement comme n'importe quel sub-workflow n8n.

Dans les deux cas, la règle d'or reste la même que pour un outil classique : le superviseur ne voit du spécialiste que son nom et sa description. « Spécialiste documentation : appelle cet outil quand la question porte sur nos produits, la doc ou les procédures internes ; passe-lui la question reformulée » — c'est cette phrase, pas le contenu du sub-workflow, qui décide du routage.

Fil rouge : un assistant support client à trois spécialistes

Prenons un cas concret : un assistant support qui reçoit des messages clients variés. Le découpage naturel :

• Superviseur : prompt système de dix lignes maximum. Son seul rôle : classifier la demande, appeler le ou les bons spécialistes, assembler la réponse finale. Aucun accès direct aux données.
• Spécialiste « recherche documentaire » : un agent avec un Vector Store en outil, qui interroge la base de connaissances (le pattern RAG classique). Son prompt : chercher, citer ses sources, dire « je n'ai pas trouvé » plutôt qu'inventer.
• Spécialiste « données client » : un agent en lecture seule sur le CRM ou Supabase — commandes, abonnement, historique de tickets. Son prompt : renvoyer des faits structurés, jamais de prose.
• Spécialiste « rédaction » : un agent sans aucun outil, qui reçoit les éléments bruts des deux autres et produit la réponse finale dans le ton de la marque.

L'intérêt saute aux yeux : le prompt de chaque spécialiste tient en quelques lignes non contradictoires, chaque agent a 1 à 3 outils au lieu de 10, et vous pouvez améliorer le rédacteur sans risquer de casser le routage. Le spécialiste documentaire, lui, est exactement la brique livrée dans notre Pack Assistant RAG — il se branche tel quel comme sub-workflow du superviseur.

L'alternative sous-estimée : le pipeline séquentiel

Avant de câbler un superviseur, posez-vous une question simple : connaissez-vous l'ordre des étapes à l'avance ? Si oui, vous n'avez pas besoin de routage dynamique — un pipeline suffit : plusieurs nodes AI Agent enchaînés dans le workflow, chacun avec son rôle (extraction des faits → enrichissement avec les données client → rédaction), la sortie de l'un nourrissant l'entrée du suivant.

Le pipeline est presque toujours préférable au superviseur quand il s'applique : pas d'appels LLM « de coordination », une latence prévisible, et un débogage trivial — vous voyez dans l'exécution exactement ce que chaque étage a produit. Réservez le superviseur aux cas où la route dépend réellement de la demande entrante ; pour tout ce qui est déterministe, enchaînez.

Les garde-fous indispensables

Un système multi-agents amplifie tous les risques d'un agent unique. Quatre garde-fous à poser dès le premier jour :

• Max Iterations partout. Sur le superviseur et sur chaque spécialiste. Sans plafond, un superviseur qui rappelle en boucle un spécialiste qui échoue peut brûler des dizaines d'appels avant d'abandonner. Abaissez la valeur par défaut sur les spécialistes qui n'ont besoin que d'un ou deux cycles.
• Suivi de coût par conversation. Chaque délégation multiplie les appels LLM ; le coût pertinent n'est plus « par appel » mais « par demande traitée de bout en bout ». Notre guide pour suivre le coût des appels IA dans n8n s'applique à chaque étage — loggez les tokens de chaque sous-exécution avec un identifiant de conversation commun.
• Traçabilité des sous-exécutions. Quand un spécialiste tourne dans un sub-workflow, son exécution apparaît séparément dans n8n. Sans identifiant partagé dans les logs, reconstituer « qui a dit quoi à qui » pour une conversation donnée devient un cauchemar. Propagez un ID de bout en bout.
• Prompt injection démultipliée. Si le spécialiste documentaire lit des contenus externes (pages web, tickets, emails), une instruction malveillante glissée dans ces contenus peut remonter jusqu'au superviseur et influencer le routage ou la réponse finale. Les défenses décrites dans notre article sur la prompt injection et les guardrails doivent s'appliquer à chaque frontière entre agents, pas seulement à l'entrée du système.

Un dernier point d'architecture : dans le pattern superviseur, c'est en général le superviseur seul qui porte la mémoire de conversation ; les spécialistes restent sans état et reçoivent tout le contexte nécessaire dans la requête. Donner une mémoire à chaque spécialiste crée des versions divergentes de la conversation — à éviter.

Évaluez le système, pas les agents isolés

Dernier piège : tester chaque spécialiste séparément, constater que chacun fonctionne, et en conclure que le système fonctionne. Faux — les échecs multi-agents naissent aux frontières : un superviseur qui route vers le mauvais spécialiste, un contexte tronqué au passage, une synthèse qui contredit ce qu'un spécialiste a trouvé. Construisez un jeu de demandes réalistes de bout en bout et mesurez la réponse finale, comme décrit dans notre guide des évaluations de workflows IA dans n8n. Les métriques par agent aident à localiser un problème, jamais à prouver que l'ensemble marche.

Par où commencer

Le chemin raisonnable : partez d'un agent unique, poussez-le jusqu'à ses limites réelles, et ne découpez que quand les symptômes de saturation apparaissent — en commençant par un pipeline si l'ordre des étapes est connu, par un superviseur à deux spécialistes sinon. Pour ne pas partir de zéro, notre Pack Assistant RAG fournit le spécialiste documentaire prêt à brancher comme sub-workflow, et nos workflows FlowKit livrent des agents outillés et documentés qui font d'excellents spécialistes de départ. Un superviseur de dix lignes devant deux briques éprouvées : c'est comme ça que les bons systèmes multi-agents commencent.