Node AI Agent de n8n : agents, chaînes et mémoire expliqués

Ouvrir pour la première fois la section IA de n8n est déroutant : des nodes qui se branchent par en dessous, des noms comme « Basic LLM Chain » ou « Question and Answer Chain », des connexions en pointillés qui ne ressemblent pas au reste de l'éditeur. Cette impression de complexité cache en réalité une architecture très logique — et une fois qu'on l'a comprise, tout l'écosystème IA de n8n devient lisible. Ce guide pose les fondations, puis construit un premier workflow pas à pas.

Le concept clé : les cluster nodes

Dans n8n, un workflow classique enchaîne des nodes de gauche à droite : chaque node reçoit des données, les transforme, les passe au suivant.

Les nodes IA (issus du package LangChain de n8n) fonctionnent différemment. Ils forment des cluster nodes : un node racine (root node) qui s'insère normalement dans le flux du workflow, et des sub-nodes qui se branchent sous lui pour lui fournir des capacités. Le node racine dit « quoi faire » ; les sub-nodes disent « avec quel modèle, quelle mémoire, quels outils ».

Concrètement, un node AI Agent seul ne sait rien faire. Il lui faut au minimum un modèle de langage branché dessous. Ajoutez une mémoire, il devient conversationnel. Ajoutez des outils, il devient capable d'agir.

Les types de connexion : le vocabulaire à connaître

Chaque prise sous un node racine a un type précis — c'est ce que vous verrez dans les exports JSON des workflows :

ai_languageModel : le cerveau. On y branche un modèle de chat — OpenAI Chat Model (lmChatOpenAi), Anthropic Chat Model (lmChatAnthropic), Google Gemini, Ollama pour du local… Le modèle est interchangeable sans toucher au reste (voir notre guide pour connecter Claude ou GPT à n8n).
ai_memory : le souvenir. Une mémoire stocke l'historique de conversation et le réinjecte à chaque tour. Sans elle, chaque message repart de zéro.
ai_tool : les mains. Un outil est une capacité que l'agent peut décider d'utiliser : requête HTTP, code personnalisé, appel d'un autre workflow, recherche dans un vector store, calculatrice…
ai_outputParser : le format. Un parseur (comme le Structured Output Parser) contraint la réponse à respecter un schéma JSON.
ai_embedding, ai_document, ai_textSplitter : la famille RAG, utilisée par les vector stores pour vectoriser et découper des documents.

Retenez l'image : racine = tâche, sub-nodes = capacités.

Les trois nodes racines à connaître

Basic LLM Chain (`chainLlm`)

La brique la plus simple : un prompt entre, une réponse sort. Pas de mémoire, pas d'outils, pas d'autonomie. C'est le node de travail de l'automatisation IA : classification, résumé, extraction, reformulation. Associé à un Structured Output Parser, il produit du JSON fiable que les nodes suivants consomment directement.

Quand l'utiliser : chaque fois que le traitement est déterministe et se décrit en une phrase. C'est le cas de la grande majorité des automatisations — le tri d'emails par IA en est l'exemple canonique.

AI Agent (`agent`)

L'agent reçoit un objectif et décide lui-même comment l'atteindre : il raisonne, choisit d'appeler tel ou tel outil, examine le résultat, recommence si besoin, puis répond. Il accepte les connexions ai_memory et ai_tool, ce que la chaîne simple ne fait pas.

Quand l'utiliser : chatbots, assistants qui doivent interroger des sources externes, tâches dont le déroulé dépend du contexte. Contrepartie : plusieurs appels au modèle par exécution (donc plus cher), et un comportement moins prévisible. Le paramètre Max Iterations évite les boucles infinies.

Question and Answer Chain (`chainRetrievalQa`)

La chaîne spécialisée RAG : à chaque question, elle interroge systématiquement un vector store (connexion dédiée au retriever), injecte les passages trouvés dans le prompt et répond. Ni mémoire native, ni outils multiples — mais un comportement parfaitement déterministe et un coût maîtrisé.

Quand l'utiliser : une FAQ documentaire pure, où chaque question mérite une recherche. Dès que l'assistant doit aussi converser longuement ou faire autre chose que chercher, passez à l'AI Agent avec le vector store branché en outil — c'est l'architecture que nous détaillons dans notre guide RAG avec n8n et Supabase pgvector.

Le node AI Agent sous le capot

Ouvrez l'export JSON de n'importe quel workflow à agent : le node AI Agent y est déclaré par son type complet, @n8n/n8n-nodes-langchain.agent :

{
  "type": "@n8n/n8n-nodes-langchain.agent",
  "typeVersion": 1.9,
  "parameters": {
    "promptType": "auto",
    "hasOutputParser": true,
    "options": {
      "systemMessage": "Tu es l'assistant d'audit. Pose une question à la fois…"
    }
  }
}

Les paramètres à connaître avant d'en modifier un à la main :

promptType — auto consomme le champ chatInput entrant (ce que produit le Chat Trigger) ; define vous laisse écrire le prompt utilisateur vous-même, avec des expressions. Un agent alimenté par un webhook ou un trigger IMAP passe presque toujours en define.
hasOutputParser — un drapeau, pas une connexion. À true, il indique au node Agent d'attendre un parseur sur sa prise ai_outputParser et d'ajouter les instructions de format au prompt. L'erreur classique à l'import — « Output parser missing » — signifie que hasOutputParser vaut true dans le JSON mais qu'aucun Structured Output Parser n'est réellement branché dessous. L'inverse est silencieux : un parseur branché avec hasOutputParser: false est simplement ignoré, et vous récupérez du texte libre là où vous attendiez du JSON.
options.systemMessage — le protocole de l'agent. Au-delà d'une démo, écrivez-le long : rôle, règles d'usage des outils, langue de sortie, conditions d'arrêt.
maxIterations — le budget de boucle (comptez un appel d'outil + raisonnement par itération). La valeur par défaut de 10 est généreuse ; abaissez-la quand les outils coûtent cher.

Depuis la typeVersion 1.7+, l'Agent est par défaut un Tools Agent : il s'appuie sur le function calling natif du modèle pour choisir ses outils — c'est pourquoi la description de chaque outil pèse plus que tout autre réglage. Exemple concret combinant hasOutputParser et un outil : un agent qui interroge un utilisateur, appelle un outil record_answer après chaque réponse confirmée, et rend un JSON final {status, missing_fields[]} via le Structured Output Parser — mot pour mot l'architecture de notre bot de questionnaire guidé.

La mémoire, sans mystère

Le sub-node de mémoire le plus courant est Simple Memory (memoryBufferWindow) : il conserve les N derniers échanges (la « fenêtre », 5 par défaut) et les renvoie au modèle à chaque tour.

Deux notions essentielles :

La clé de session (session key) : c'est elle qui sépare les conversations. Avec un Chat Trigger, elle est fournie automatiquement. Avec un autre déclencheur (Telegram, webhook), utilisez un identifiant stable de l'utilisateur — sinon tous vos utilisateurs partageront la même conversation, avec des fuites de contexte embarrassantes.
Le coût : la mémoire est réinjectée dans chaque appel. Une fenêtre de 20 échanges verbeux, c'est autant de tokens facturés à chaque message. Restez sur une fenêtre courte sauf besoin réel.

La Simple Memory vit dans la mémoire de l'instance n8n : elle ne survit ni à un redémarrage ni à plusieurs workers. Pour de la persistance réelle, n8n propose des mémoires adossées à Postgres ou Redis — mêmes branchements, durabilité en plus.

Premier workflow pas à pas : un assistant avec mémoire et outil

Objectif : un chat qui répond, se souvient de la conversation et sait aller chercher une information sur le web via une API. Comptez quinze minutes.

Créez un workflow vide, ajoutez un node Chat Trigger. Il ouvre une interface de chat de test directement dans l'éditeur.
Ajoutez un node AI Agent à la suite du trigger. À ce stade, n8n signale qu'il manque un modèle.
Branchez un modèle : cliquez sur la prise « Chat Model » sous l'agent et choisissez OpenAI Chat Model ou Anthropic Chat Model. Sélectionnez un modèle économique (GPT-4.1 mini ou Claude Haiku) et votre credential.
Branchez une Simple Memory sur la prise « Memory ». Laissez la fenêtre par défaut.
Rédigez le message système dans les options de l'agent :

Tu es l'assistant interne d'une PME française.
Réponds en français, de façon concise.
Si une question nécessite une information externe, utilise l'outil disponible.
Si tu ne sais pas, dis-le.

Branchez un outil : sur la prise « Tool », ajoutez un HTTP Request Tool pointant par exemple vers une API météo ou votre propre endpoint. Le champ description de l'outil est crucial : c'est en le lisant que l'agent décide de l'utiliser (« Donne la météo actuelle pour une ville donnée »).
Testez : ouvrez le chat, posez « Bonjour, je m'appelle Camille », puis « Quel temps fait-il à Lyon ? », puis « Comment je m'appelle ? ». Vous vérifiez d'un coup l'outil (2e question) et la mémoire (3e).
Inspectez les logs : dans le panneau d'exécution, n8n affiche chaque étape du raisonnement de l'agent — appels au modèle, invocations d'outils, tokens consommés. C'est le meilleur outil pédagogique qui soit : lisez-les.

Pour aller plus loin

Une fois ces bases posées, tout l'écosystème s'ouvre avec les mêmes briques : remplacez le Chat Trigger par un trigger Gmail et l'agent par une chaîne de classification, et vous avez un tri d'emails ; branchez un vector store en outil, et vous avez un assistant documentaire. Si vous préférez étudier des workflows complets et éprouvés plutôt que de partir d'une page blanche, nos packs — comme le Pack Assistant RAG — sont aussi d'excellents supports d'apprentissage : chaque node y est déjà câblé selon les patterns décrits ici, et rien ne vaut la dissection d'un workflow qui fonctionne.

L'architecture en cluster nodes qui vous semblait étrange ce matin est en réalité le grand atout de n8n : des briques standardisées, interchangeables, qui se combinent à l'infini. Racine pour la tâche, sub-nodes pour les capacités — vous avez la grille de lecture ; le reste n'est que de la pratique.