Hola,
Tengo un flujo de trabajo que utiliza una conversación de Teams como punto de entrada. Ya tengo varios criterios establecidos para filtrar solicitudes. Actualmente, el flujo es: una solicitud = una respuesta en Teams, seguida del final de la conversación.
He añadido un agente de IA de n8n para aprovechar los datos de una base de datos. El flujo simple de „una solicitud = una respuesta
El bucle no es la solución, y vale la pena entender por qué: cada mensaje de Teams llega como una ejecución separada, y las ejecuciones de n8n no tienen estado. Nada persiste entre ellas a menos que lo almacenes en algún lugar. Un bucle dentro de una ejecución solo ayuda si toda la conversación ocurre dentro de esa única ejecución, lo cual no es el caso aquí, porque el siguiente mensaje del usuario llega minutos después a través de un disparador nuevo.
Lo que necesitas es memoria persistente vinculada a la conversación, no un bucle:
Adjunta un nodo de Memory al AI Agent (Postgres Chat Memory o Redis Chat Memory en lugar de Simple Memory en memoria, que muere con la ejecución y tampoco sobrevivirá a reinicios de Docker).
Establece la clave de sesión en el ID de la conversación de Teams, no en un valor estático. Cada mensaje del mismo hilo de Teams carga entonces el mismo historial, por lo que “el tercero” se resuelve contra lo que el agente dijo la última vez. Si usas la misma clave para todos, los usuarios verán el contexto los unos de los otros, así que este campo es el que debes acertar.
Mantén una ventana sobre él (últimos N mensajes) para que el contexto no crezca indefinidamente y tus costos de tokens se mantengan predecibles.
Una cosa que vale la pena añadir mientras estés ahí: si la respuesta del usuario es ambigua (“el tercero” cuando el agente no listó nada), el agente debe decir que no lo sabe en lugar de adivinar un registro de cliente. Las direcciones incorrectas que regresan de una búsqueda en la base de datos son el tipo de fallo que la gente nota.
@flipflip La clave principal: UUID, utiliza el “UUID de Teams”
Si generas un UUID completamente nuevo cada vez que se ejecuta el flujo de trabajo, la IA seguirá tratándolo como un chat nuevo. El enfoque más sencillo es obtener el ID único que Microsoft Teams ya envía en su carga útil y usarlo como tu Session ID.
Paso a paso
Añade un nodo Memory a tu AI Agent
Necesitas conectar un nodo Memory al lado izquierdo de tu nodo AI Agent.
Configura el Session ID en el nodo Memory
Haz clic para abrir el nodo Memory. Verás un campo llamado Session ID (Si no lo ves, haz clic en Add Field / Parameter y selecciona Session ID).
Mapea el ID del Teams Trigger
En el campo Session ID, mapea la variable que viene de tu Teams Trigger. Tienes 2 opciones según tus necesidades:
Recuerda por “Sala de chat/Thread” (Recomendado):
Extrae el Conversation ID de Teams, por ejemplo:
{{ $json.conversation.id }} o {{ $json.message.conversation.id }}
(Ventajas: Si chateas en un grupo/canal, la IA recuerda el contexto de ese hilo específico)
Recuerda por “Usuario individual”:
Extrae el User ID de la persona que está escribiendo, por ejemplo:
{{ $json.from.id }}
(Ventajas: Sin importar desde qué sala de chat escriba este usuario, la IA recordará el historial de conversación con esta persona específica)
¿Cómo funciona el sistema después de esta configuración?
Solicitud 1: El usuario escribe “Dame la dirección del cliente foobar”
Teams envía el mensaje con Conversation ID = “abc-123”
El AI Agent recibe el mensaje y vincula su memoria al Session ID “abc-123”
La IA responde “Tengo varios clientes… ¿Cuál deseas?” (y guarda este historial)
Solicitud 2: El usuario responde “El tercero”
¡El flujo de trabajo se reinicia desde el principio!
Pero esta vez, Teams envía el mensaje con el mismo Conversation ID = “abc-123” (el ID exacto para este bucle de conversación).
Cuando el nodo Memory ve el Session ID “abc-123”, inmediatamente extrae el historial de chat de la Solicitud 1 y se lo proporciona a la IA.
¡La IA sabe instantáneamente que “El tercero” se refiere a la lista de clientes del mensaje anterior!
¡Bienvenido @flipflip!
La clave es adjuntar un sub-nodo de memoria a tu Agente de IA — específicamente el nodo “Window Buffer Memory”. En su campo “Session ID”, usa el ID de conversación de Teams: {{ $json.channelId }} o cualquier campo que contenga el ID de conversación único de Teams en tus datos de activación. De esta manera, cada conversación de Teams obtiene su propia ventana de memoria y el agente recuerda los intercambios previos dentro de esa misma conversación.
Tu flujo se convierte en: activación de Teams → Agente de IA (con sub-nodo Window Buffer Memory, session ID = ID de conversación de Teams) → respuesta a Teams. Cada nuevo mensaje del usuario llega al mismo agente, el nodo de memoria carga los turnos anteriores de esa sesión, y el agente retoma el contexto. El enfoque de bucle que intentaste no funcionará aquí porque n8n no está diseñado para pausarse a mitad de la ejecución esperando entrada del usuario — memoria + clave de sesión es el patrón correcto.
Hola a todos,
Gracias por sus respuestas. Tenían razón—usar un bucle definitivamente no era el enfoque correcto.
Añadí memoria basada en PostgreSQL, pero no usé el ID de conversación de Teams porque cambia con cada mensaje enviado o recibido. En su lugar, usé el ID del perfil del usuario que envía el mensaje.
Ahora puedo utilizar la memoria del agente de IA mientras distingo entre diferentes usuarios.
El consejo de memoria de ID de conversación es la capa base correcta, pero añadiría una prueba de recuperación antes de confiar en esto en producción.
En tu ejemplo, «el tercero» no es solo un problema de memoria. También es un problema de actualidad y autoridad: el agente solo debe resolver «el tercero» si la lista de candidatos anterior sigue vinculada a la misma conversación de Teams, la lista no ha expirado y el usuario sigue respondiendo el mismo paso de desambiguación.
Almacenaría un pequeño registro de recuperación junto con la memoria del chat:
Prueba rápida: inicia en frío el flujo de trabajo con solo las entradas de memoria/recuperación persistidas y pregunta al agente qué sabe, qué está obsoleto, qué no debe inferir y cuál es su siguiente acción segura. Si no puede decirlo claramente, el flujo de trabajo tiene memoria pero no una recuperación confiable.