Bonjour,
J’ai un workflow qui utilise une conversation Teams comme point d’entrée. J’ai déjà mis en place plusieurs critères pour filtrer les demandes. Actuellement, le flux est : une demande = une réponse dans Teams, suivie de la fin de la conversation.
J’ai ajouté un agent IA n8n pour exploiter les données d’une base de données. Le simple flux « une demande = une réponse » fonctionne bien. Maintenant, je veux que l’utilisateur puisse avoir une conversation bidirectionnelle avec l’agent. Par exemple :
- Utilisateur : Donne-moi l’adresse du client « foobar ».
- Agent : J’ai plusieurs clients avec ce nom :
liste des clients. Lequel voulez-vous ?
- Utilisateur : Le troisième.
Mon problème est que chaque message envoyé par l’utilisateur est traité comme un nouveau message ; par conséquent, le workflow redémarre et l’agent « oublie » l’interaction précédente.
J’ai essayé de mettre l’agent à l’intérieur d’une boucle, mais cela ne semble pas être la bonne approche 
Avez-vous des suggestions ?
Merci d’avance.
Informations sur votre configuration n8n
- Version n8n : 2.29.9
- Base de données (par défaut : SQLite) :
- Paramètre EXECUTIONS_PROCESS de n8n (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) : Docker
- Système d’exploitation : Linux
1 « J'aime »
La boucle n’est pas la solution, et il vaut la peine de comprendre pourquoi : chaque message Teams arrive comme une exécution distincte, et les exécutions n8n sont sans état. Rien ne persiste entre elles à moins que vous le stockiez quelque part. Faire une boucle dans une exécution n’aide que si toute la conversation se déroule dans cette seule exécution, ce qui n’est pas le cas ici, car le message suivant de l’utilisateur arrive quelques minutes plus tard via un déclencheur nouveau.
Ce que vous voulez, c’est une mémoire persistante associée à la conversation, pas une boucle :
Associez un nœud Memory à l’AI Agent (Postgres Chat Memory ou Redis Chat Memory plutôt que le Simple Memory en mémoire, qui disparaît avec l’exécution et ne survivra pas non plus aux redémarrages Docker).
Définissez la clé de session sur l’ID de conversation Teams, et non sur une valeur statique. Chaque message du même thread Teams charge ensuite le même historique, de sorte que « le troisième » se résout en fonction de ce que l’agent a dit la dernière fois. Si vous utilisez la même clé pour tout le monde, les utilisateurs verront le contexte les uns des autres, donc ce champ est celui à bien configurer.
Mainttenez une fenêtre dessus (les N derniers messages) afin que le contexte ne croisse pas indéfiniment et que vos coûts en tokens restent prévisibles.
Une chose utile à ajouter pendant que vous y êtes : si la réponse de l’utilisateur est ambiguë (« le troisième » quand l’agent n’a rien énuméré), l’agent devrait dire qu’il ne sait pas plutôt que de deviner un enregistrement client. Les mauvaises adresses qui reviennent d’une recherche en base de données sont l’échec que les gens remarquent.
2 « J'aime »
@flipflip La clé essentielle : UUID, utilisez l’« UUID Teams »
Si vous générez un nouvel UUID à chaque exécution du workflow, l’IA traitera toujours cela comme une nouvelle conversation. L’approche la plus simple consiste à récupérer l’ID unique que Microsoft Teams envoie déjà dans sa charge utile et à l’utiliser comme ID de session.
Étape par étape
-
Ajoutez un nœud Memory à votre agent IA
Vous devez connecter un nœud Memory au côté gauche de votre nœud AI Agent.
-
Configurez l’ID de session dans le nœud Memory
Cliquez pour ouvrir le nœud Memory. Vous verrez un champ nommé Session ID (Si vous ne le voyez pas, cliquez sur Add Field / Parameter et sélectionnez Session ID).
-
Mappez l’ID du déclencheur Teams
Dans le champ Session ID, mappez la variable provenant de votre déclencheur Microsoft Teams. Vous avez 2 options selon vos besoins :
Mémoriser par « Salle de conversation/Thread » (Recommandé) :
Extrayez l’ID de conversation de Teams, par exemple :
{{ $json.conversation.id }} ou {{ $json.message.conversation.id }}
(Avantages : Si vous discutez dans un groupe/canal, l’IA se souvient du contexte de ce thread spécifique)
Mémoriser par « Utilisateur individuel » :
Extrayez l’ID utilisateur de la personne qui tape, par exemple :
{{ $json.from.id }}
(Avantages : Peu importe la salle de conversation dans laquelle cet utilisateur tape, l’IA se souviendra de l’historique de conversation avec cette personne spécifique)
Comment fonctionne le système après cette configuration ?
Requête 1 : L’utilisateur tape « Donnez-moi l’adresse du client foobar »
Teams envoie le message avec Conversation ID = « abc-123 »
L’agent IA reçoit le message et lie sa mémoire à l’ID de session « abc-123 »
L’IA répond « J’ai plusieurs clients… Lequel voulez-vous ? » (et sauvegarde cet historique)
Requête 2 : L’utilisateur répond « Le troisième »
Le workflow redémarre depuis le début !
Mais cette fois, Teams envoie le message avec le même ID de conversation = « abc-123 » (le même ID pour cette boucle de conversation).
Quand le nœud Memory voit l’ID de session « abc-123 », il récupère immédiatement l’historique de conversation de la requête 1 et l’envoie à l’IA.
L’IA sait instantanément que « Le troisième » fait référence à la liste de clients du message précédent !
1 « J'aime »
Bienvenue @flipflip!
La clé est d’attacher un sous-nœud de mémoire à votre Agent IA — spécifiquement le nœud « Window Buffer Memory ». Dans son champ « Session ID », utilisez l’ID de conversation Teams : {{ $json.channelId }} ou n’importe quel champ qui transporte l’ID de conversation unique de Teams dans vos données de déclenchement. De cette façon, chaque conversation Teams obtient sa propre fenêtre de mémoire et l’agent se souvient des échanges précédents au sein de cette même conversation.
Votre flux devient : déclencheur Teams → Agent IA (avec sous-nœud Window Buffer Memory, session ID = ID de conversation Teams) → répondre à Teams. Chaque nouveau message de l’utilisateur atteint le même agent, le nœud de mémoire charge les tours précédents de cette session, et l’agent comprend le contexte. L’approche de boucle que vous avez essayée ne fonctionnera pas ici car n8n n’est pas conçu pour mettre en pause l’exécution en attente d’une entrée utilisateur — la mémoire + clé de session est le bon modèle.
Bonjour à tous,
Merci pour vos réponses. Vous aviez raison — utiliser une boucle n’était définitivement pas la bonne approche.
J’ai ajouté une mémoire basée sur PostgreSQL, mais je n’ai pas utilisé l’ID de conversation Teams car il change à chaque message envoyé ou reçu. À la place, j’ai utilisé l’ID du profil utilisateur envoyant le message.
Maintenant, je peux utiliser la mémoire de l’agent IA tout en distinguant les différents utilisateurs.
1 « J'aime »
Le conseil sur la mémoire de l’ID de conversation est la bonne couche de base, mais j’ajouterais un test de récupération avant de faire confiance à cela en production.
Dans votre exemple, « le troisième » n’est pas seulement un problème de mémoire. C’est aussi un problème de fraîcheur et d’autorité : l’agent ne devrait résoudre « le troisième » que si la liste de candidats précédente est toujours liée à la même conversation Teams, la liste n’a pas expiré, et l’utilisateur répond toujours à la même étape de désambiguïsation.
Je stockerais un petit enregistrement de récupération aux côtés de la mémoire de conversation :
- ID de conversation Teams / clé de session ;
- objectif courant, p. ex. désambiguïser le client « foobar » ;
- dernière liste de candidats plus horodatage/requête source ;
- actions utilisateur suivantes autorisées ;
- champs qui sont obsolètes ou inconnus ;
- non-inférences explicites, p. ex. ne pas mapper « le troisième » sur un client si la liste de candidats est manquante, expirée ou provient d’une autre conversation ;
- action sécuritaire suivante en cas d’échec de la récupération, p. ex. demander à l’utilisateur de reformuler le client.
Test rapide : démarrer à froid le workflow avec uniquement les entrées de mémoire/récupération persistantes et demander à l’agent ce qu’il sait, ce qui est obsolète, ce qu’il ne doit pas inférer, et quelle est sa prochaine action sécuritaire. S’il ne peut pas l’exprimer clairement, le workflow a une mémoire mais pas une récupération fiable.
