5. Conversaciones multi-turno: mantener el hilo

Descripción

Al terminar esta lección vas a poder tomar el arreglo de mensajes que reconstruye el nodo de memoria y explicar, turno por turno, a qué entidad apunta cada referencia que escribe un usuario dentro de una conversación en curso — un pronombre como "ese", una descripción como "el pedido anterior", o directamente ninguna palabra que nombre la entidad. Y vas a poder distinguir el caso donde esa resolución es automática y confiable del caso donde es genuinamente ambigua, y escribir la línea de instrucción que hace que el agente pregunte en vez de adivinar.

Esto importa apenas un agente pasa de una demo de un mensaje a una conversación real. Un cliente de soporte con dos pedidos abiertos en la misma charla escribe, sin más contexto, "cancela mi pedido" — y si el agente adivina cuál de los dos, la mitad de las veces cancela el que no era. En una demo nadie nota esto, porque las demos casi siempre son de un mensaje. En producción, con volumen real, es de los fallos más caros que puede tener un agente: no porque falle de forma ruidosa, sino porque responde con total seguridad sobre la entidad equivocada.

Conexión con el módulo: en la lección anterior resolviste dónde vive el historial entre sesiones — un session ID que identifica al usuario y un almacén (Postgres o Redis) que sobrevive un reinicio del workflow. Esta lección da un paso al costado: asumiendo que ese historial ya está completo y disponible, ¿qué hace el agente con él dentro de una conversación en curso? Ese es el trabajo de hoy — cómo el modelo recorre varios turnos hacia atrás para resolver a qué apunta una referencia, y qué pasa cuando hay más de una candidata posible. Todavía no vas a ver qué ocurre cuando esa misma conversación se alarga tanto que el modelo empieza a perder precisión sobre historiales enormes — eso es context drift, y es exactamente el tema de la lección 6. Acá las conversaciones son cortas y manejables; el problema no es de tamaño, es de a cuál entidad apunta cada palabra.

Leer hacia atrás: cómo el modelo encuentra el antecedente

Piensa en un hilo largo de WhatsApp con un proveedor, de esos que se estiran toda la semana con fotos, precios y cambios de opinión. En algún punto el proveedor escribe: "Confirmado, va la primera opción, la despacho el viernes." Si alguien te reenvía justo esa captura de pantalla, sin nada más, "la primera opción" no te dice absolutamente nada. Pero si tienes el hilo completo y subes con el dedo unos mensajes, encuentras el punto exacto donde se habló de dos opciones — y una de ellas, unos mensajes antes, quedó marcada como "la primera". No adivinaste: leíste hacia atrás hasta encontrar el mensaje que le da sentido al de ahora.

Eso, en frío, es lo que hace un modelo de lenguaje cuando resuelve una referencia dentro de una conversación. En lingüística computacional el fenómeno tiene nombre: cuando dos expresiones de un texto apuntan a la misma entidad se llama correferencia, y el caso específico donde una expresión (un pronombre, por ejemplo) aparece después de aquello a lo que se refiere se llama anáfora (ver Recursos). "Ese pedido", "el anterior", "lo mismo" son anáforas: apuntan hacia algo que ya se dijo, en vez de nombrarlo de nuevo.

Ya sabes, desde la lección 2, que el nodo AI Agent arma un arreglo de mensajes antes de cada llamada, y que ese arreglo — turnos marcados user y assistant — es lo único que recibe el modelo; no hay ninguna sesión abierta del lado del proveedor del modelo esperándote, ni un "recuerdo" guardado aparte. La resolución de referencias no es un paso adicional que alguien programa por separado en n8n: es el mismo modelo, en la misma llamada donde genera la respuesta, leyendo hacia atrás dentro de ese arreglo para encontrar qué entidad hace que la oración de ahora tenga sentido. No hay un módulo de "resolución de referencias" en algún lugar del nodo AI Agent — hay un arreglo de texto completo, y un modelo entrenado para leer conversaciones enteras, no mensajes sueltos.

Ejemplo trabajado

Vas a montar un agente de soporte para Andes Market, una tienda en línea. El System Message trae, hardcodeados, los datos de dos pedidos existentes — así puedes seguir el ejemplo sin depender todavía de una tool que consulte una base de datos en vivo (eso es terreno del Módulo 4; acá el foco es solo la memoria).

# System Message del agente
"Eres el asistente de soporte de Andes Market. Ayudas a los clientes
con dudas sobre sus pedidos. Datos de los pedidos en el sistema:
- Pedido #7734: estado 'en tránsito', total $134, entrega estimada
  el jueves.
- Pedido #7601: estado 'en preparación', total $76, todavía no se
  despacha."

Turno 1. El cliente escribe: "¿En qué va mi pedido #7734?" El agente responde: "Tu pedido #7734 está en tránsito, la entrega estimada es el jueves."

Turno 2. El cliente escribe: "¿Y cuánto pagué por ese pedido?" Así se ve el arreglo de mensajes que recibe el modelo en este turno:

messages = [
  { role: "system",    content: "Eres el asistente de soporte de Andes
                                 Market... [datos de los pedidos]" },
  { role: "user",      content: "¿En qué va mi pedido #7734?" },
  { role: "assistant", content: "Tu pedido #7734 está en tránsito, la
                                 entrega estimada es el jueves." },
  { role: "user",      content: "¿Y cuánto pagué por ese pedido?" }
]

Qué esperar. "Ese pedido" es una anáfora: apunta hacia atrás. El modelo recorre el arreglo y encuentra un solo candidato posible — el #7734, mencionado en el turno 1 y otra vez en su propia respuesta. No hay ambigüedad porque no hay ningún otro pedido en juego todavía. Respuesta esperable: "Pagaste $134 por el pedido #7734."

Turno 3. El cliente escribe: "Ok. Cambia la dirección de entrega a Avenida Providencia 1234." Fíjate en algo distinto a los turnos anteriores: esta oración no tiene ningún pronombre ni descripción que apunte a un pedido — ni "ese", ni "el anterior", nada. Y aun así, la respuesta esperable es: "Listo, actualicé la dirección de entrega del pedido #7734 a Avenida Providencia 1234."

Interpretación: esto no es resolución de un pronombre — es continuidad de tema. El modelo lee el arreglo completo y encuentra que solo hay un pedido activo en toda la conversación, y que "cambiar la dirección de entrega" es una acción coherente con ese pedido (que además todavía está en tránsito, no entregado). Cuando hay un único candidato y el tema encaja, el modelo resuelve la referencia aunque el cliente ni siquiera la haya nombrado explícitamente. Esta es la parte fácil: una sola entidad activa, cero ambigüedad real. La parte difícil empieza cuando entra una segunda entidad en juego.

Cuando la referencia es ambigua: dos candidatas en juego

Sigamos la misma conversación con dos turnos más.

Turno 4. El cliente escribe: "Y también quiero preguntar por mi pedido #7601, ¿en qué va?" El agente responde: "El pedido #7601 está en preparación, todavía no se despacha."

En este punto, el arreglo de mensajes tiene dos pedidos mencionados: el #7734 (turnos 1-3) y el #7601 (turno 4). Ambos siguen siendo cancelables — ninguno fue entregado todavía.

Turno 5. El cliente escribe: "Cancela mi pedido, por favor."

Ninguna palabra de esa oración distingue entre los dos pedidos. No hay "ese", no hay ordinal, no hay ningún rasgo que apunte a uno más que al otro. Esto ya no es una anáfora fácil de resolver por continuidad de tema — es una referencia genuinamente ambigua, con dos antecedentes igual de válidos.

Lo que responda el agente depende de cómo esté escrito el System Message:

# CONFIGURACIÓN A — System Message sin instrucción sobre ambigüedad

Qué esperar — Configuración A. El modelo tiene que elegir algo, y algunos modelos eligen sin avisar que dudaron — por ejemplo, el mencionado más recientemente (el #7601). La respuesta puede sonar tan segura como cualquier otra: "Listo, cancelé el pedido #7601." El problema es que el cliente pudo haber querido decir el #7734. No hay forma de saberlo desde afuera, porque el agente nunca preguntó — y el cliente, si no revisa el número exacto en la respuesta, puede ni darse cuenta de que se canceló el pedido equivocado.

# CONFIGURACIÓN B — se agrega una línea explícita al System Message
"...Si el cliente pide una acción sobre 'su pedido' sin especificar
el número, y hay más de un pedido mencionado en esta conversación,
pregunta primero a cuál se refiere. No asumas cuál es por el orden
en que se mencionaron."

Qué esperar — Configuración B. Con esa línea, la respuesta esperable cambia de raíz: "Tienes dos pedidos activos en esta conversación: el #7734 (en tránsito) y el #7601 (en preparación). ¿Cuál de los dos quieres cancelar?" El modelo sigue leyendo exactamente el mismo arreglo de mensajes que en la Configuración A — lo único que cambió es que el System Message ahora le dice explícitamente qué hacer cuando detecta más de un candidato: no resolver en silencio, resolver preguntando.

Una herramienta que puede ayudarte a reforzar esto en casos delicados es el nodo Chat Memory Manager de n8n: te permite insertar un mensaje adicional en el historial —por ejemplo, uno de tipo sistema que diga algo como "Entidad activa confirmada: pedido #7734"— justo después de que el cliente confirma a cuál pedido se refiere, para que quede como ancla clara si más adelante aparece otra referencia ambigua en la misma conversación. Es una herramienta puntual para anclar una entidad, no para resumir ni recortar historial — eso lo vas a ver en la lección 7.

Errores comunes

Asumir que "hay memoria conectada" equivale a "cero ambigüedad", sin importar cuántas entidades entren en juego (conceptual). Qué pasa: como el arreglo de mensajes trae el historial completo, se da por sentado que cualquier referencia se resuelve sola, sin revisar qué pasa cuando aparece una segunda entidad del mismo tipo en la conversación. El agente funciona perfecto en las pruebas (donde casi siempre se prueba con un solo pedido, un solo ticket, un solo cliente mencionado) y falla en producción, donde los clientes reales mezclan varios temas en la misma charla. Por qué pasa: memoria completa resuelve dónde está la información, no cuál de dos piezas de información aplica cuando ambas son candidatas válidas — son dos problemas distintos, y el primero no garantiza el segundo. Cómo detectarlo: si el agente nunca fue probado con dos entidades del mismo tipo mencionadas en la misma conversación (dos pedidos, dos tickets, dos direcciones), no sabes si resuelve bien la ambigüedad — solo sabes que resuelve bien el caso fácil de una sola entidad. Cómo corregirlo: agrega al menos un caso de prueba con dos entidades activas y una referencia deliberadamente ambigua ("cancela mi pedido", sin número), y revisa si el agente pregunta o adivina.

Confundir el orden conversacional con el orden cronológico real al usar palabras como "el anterior" (conceptual). Qué pasa: un cliente escribe "y del pedido anterior, ¿cuál era la dirección?" esperando que "anterior" signifique "el que hice antes en el tiempo" (por fecha de compra real), pero el modelo puede resolverlo como "el que mencionamos hace un momento en el chat" — que no necesariamente es el mismo pedido si la conversación no siguió el orden cronológico de las compras. Por qué pasa: "anterior" es ambiguo en español entre dos ejes distintos — orden del discurso (lo último que se dijo) y orden del calendario (lo que ocurrió primero) — y el modelo no tiene forma de saber cuál de los dos quiso decir el cliente si el System Message no lo aclara. Cómo detectarlo: si en tus pruebas mencionas pedidos en un orden distinto al que fueron comprados (por ejemplo, primero el más reciente y después el más viejo) y luego usas "el anterior", revisa cuál de los dos eligió el modelo — puede sorprenderte. Cómo corregirlo: cuando el orden cronológico real importe para el negocio (facturación, garantías, plazos), pide al cliente el número exacto en vez de depender de "anterior", o instruye al agente a preguntar explícitamente qué eje de "anterior" aplica.

No verbalizar el identificador de la entidad en las respuestas del propio agente (práctico). Qué pasa: el System Message se escribe para que el agente responda con frases genéricas como "tu pedido está en camino" en vez de "tu pedido #7734 está en camino". Funciona bien mientras solo hay una entidad en juego, pero en cuanto entra una segunda, el historial ya no tiene ningún turno donde el número quede escrito explícitamente — ni en lo que dijo el cliente (que tampoco siempre lo repite) ni en lo que respondió el agente. Por qué pasa: repetir el número en cada respuesta se siente redundante para quien escribe el prompt, porque dentro de esa respuesta puntual es obvio a qué pedido se refiere — pero esa obviedad no viaja: el modelo, en un turno posterior, solo tiene el texto reinyectado, y si el texto nunca dijo el número, no está ahí para encontrarlo. Cómo detectarlo: revisa el historial de una conversación con más de una entidad y busca si el identificador aparece explícito en al menos un turno cercano a cada mención — si solo aparece implícito ("tu pedido"), la cadena de referencias es más frágil de lo que parece. Cómo corregirlo: instruye al agente a incluir el identificador exacto (número de pedido, de ticket, de lo que sea) cada vez que lo menciona, incluso si "suena redundante" para un humano leyendo un solo turno — esa redundancia es justo lo que mantiene resoluble la referencia más adelante.

Ejercicios

Ejercicio 1 — Referencia sin nombrar la entidad. Retoma la conversación de Andes Market hasta el turno 1 únicamente (el cliente preguntó por el pedido #7734 y el agente respondió que está en tránsito). El cliente escribe en el turno 2: "¿A qué hora más o menos llega?" — sin mencionar ningún pedido. ¿A qué se resuelve esa referencia, y por qué no es ambigua a pesar de no nombrar nada explícitamente?

Ver solución

Se resuelve al pedido #7734, el único mencionado hasta ese punto en el arreglo de mensajes. No es ambigua porque no hay ningún otro candidato compitiendo: el modelo lee el historial completo (system + turno 1 + turno 2), encuentra una sola entidad de tipo "pedido" activa, y la pregunta sobre "a qué hora llega" es temáticamente coherente con esa entidad (que además está "en tránsito", con entrega estimada el jueves). Esto es continuidad de tema, no resolución de un pronombre — el mismo mecanismo del turno 3 del ejemplo trabajado.

Por qué funciona: cuando hay una sola entidad activa, el modelo no necesita ninguna pista lingüística explícita para saber de qué se está hablando — la unicidad del candidato hace el trabajo. La ambigüedad solo aparece cuando hay dos o más candidatos válidos al mismo tiempo, como en la Configuración A/B de la lección.

Ejercicio 2 — Escribir la instrucción que evita adivinar. Un colega te muestra el System Message de un agente de soporte de una aerolínea que maneja cambios de vuelo. El agente puede tener, en una misma conversación, más de una reserva mencionada (el cliente viaja seguido y pregunta por varios vuelos). El System Message actual no dice nada sobre qué hacer si el cliente pide "cambia mi vuelo" sin especificar cuál. Escribe la línea que agregarías al System Message para evitar que el agente adivine.

Ver solución

Algo en la línea de: "Si el cliente pide una acción sobre 'su vuelo' o 'su reserva' sin dar el número de reserva o la fecha, y hay más de una reserva mencionada en esta conversación, pregunta primero a cuál se refiere antes de hacer cualquier cambio. No asumas que es la última mencionada."

Por qué funciona: la instrucción hace dos cosas a la vez — detecta la condición de riesgo (más de una entidad candidata) y da la acción correcta ante esa condición (preguntar, no adivinar). Sin esa línea, el modelo puede elegir en silencio la reserva más reciente por defecto, que es un sesgo razonable pero no garantizado, y en una aerolínea un cambio de vuelo equivocado es un error caro de corregir.

Ejercicio 3 — Diagnóstico con el historial completo a la vista. Un agente de soporte de Andes Market, en el turno 6 de una conversación, aplica un descuento del 10% al pedido #7601 cuando el cliente había pedido claramente, en el turno 5, aplicarlo "al pedido que mencioné primero" — que era el #7734, mencionado en el turno 1, tres turnos antes del #7601. El arreglo de mensajes que llegó al modelo tenía los seis turnos completos, en orden, sin nada faltante. ¿Es un problema de memoria? ¿Es el mismo tipo de error que viste en esta lección?

Ver solución

No es un problema de memoria — el historial estaba completo, los dos pedidos y el orden en que se mencionaron están ahí. El fallo es de resolución de referencia, pero de un tipo específico: "el que mencioné primero" es una referencia ordinal sobre el orden conversacional, no ambigua en el sentido de "dos candidatos igual de válidos" (acá el cliente sí especificó un criterio claro), sino un caso donde el modelo razonó mal sobre cuál de los dos cumplía ese criterio — aplicó el descuento al último mencionado en vez de al primero, invirtiendo el orden.

Por qué funciona: distinguir tipos de fallo dentro de "resolución de referencias" — ambigüedad genuina (dos candidatos sin ningún criterio que los distinga, como en la Configuración A de esta lección) versus error de razonamiento sobre un criterio que sí estaba claro (este ejercicio) — te dice si la corrección es "agregar una instrucción para pedir aclaración" o "revisar por qué el modelo se equivocó con una instrucción que sí tenía toda la información para seguir bien". Son problemas distintos con arreglos igual de completos.

Resumen y siguiente paso

Ya viste que resolver una referencia dentro de una conversación no es un paso aparte que n8n ejecuta por su cuenta: es el mismo modelo, leyendo hacia atrás en el arreglo de mensajes que la memoria reconstruyó, encontrando qué entidad le da sentido a "ese", a "el anterior" o a una oración que ni siquiera nombra la entidad. Mientras solo hay un candidato activo, esa lectura es confiable casi siempre. En cuanto entra un segundo candidato del mismo tipo, la referencia puede volverse genuinamente ambigua — y ahí la diferencia entre un agente que adivina en silencio y uno que pregunta primero está en una línea explícita del System Message, no en qué tan grande o "inteligente" sea el modelo conectado.

Antes de avanzar deberías poder: leer un arreglo de mensajes con varias entidades mencionadas y predecir a cuál resuelve una referencia dada, distinguir un caso de referencia ambigua (dos candidatos sin ningún criterio que los diferencie) de un caso de error de razonamiento sobre un criterio que sí era claro, y escribir la línea de instrucción que hace que un agente pida aclaración en vez de asumir.

Todo esto asumió conversaciones cortas, de cinco o seis turnos, donde el arreglo completo cabe sin problema en cualquier ventana de contexto. La siguiente lección rompe esa suposición: qué le pasa a un agente cuando la conversación no dura seis turnos sino sesenta, y el historial empieza a ser tan largo que el modelo pierde precisión sobre partes de él — el fenómeno que se conoce como context drift.

Recursos

• How memory works — n8n Docs — confirma qué guarda cada nodo de memoria: el historial de turnos que se reinyecta en cada llamada, la base sobre la que ocurre toda resolución de referencias de esta lección.
• Chat Memory Manager — n8n Docs — el nodo que permite insertar, revisar o borrar mensajes del historial directamente; útil para anclar una entidad activa cuando la ambigüedad es un riesgo real.
• AI Agent node — n8n Docs — referencia del nodo y de la conexión ai_memory, ya citada en el Módulo 1 y en la lección 2 de este módulo.
• Prompting best practices — Claude Docs — técnicas de instrucciones explícitas y sin ambigüedad, la base de la línea de System Message que le pide al agente preguntar antes de adivinar.
• Coreference — Wikipedia — la definición formal del fenómeno lingüístico detrás de "ese pedido" y "el anterior": cuándo dos expresiones se refieren a la misma entidad.