Cómo Configurar un Buffer de Mensajes con Redis en N8N

En este artículo te voy a enseñar a cómo hacer un buffer de mensajes con Redis en N8N, paso a paso. No es solo teoría: te cuento los errores que cometí, las pruebas que hice y la solución que al final me funcionó para que tus agentes de IA puedan esperar y agrupar varios mensajes del usuario antes de responder. Este proyecto es parte de mi saga de creación de agentes de IA en N8N. Ya tengo tres versiones publicadas y esta sería la cuarta, la más profesional hasta ahora. Me costó un montón poder ejecutarlo y hacer un montón de pruebas (error, prueba error, prueba error) hasta que funcionara.

¿Por Qué Necesitas un Buffer de Mensajes Para Tu Agente de IA?

Imagina que le hablas a tu agente por Telegram. Le dices «Hola». Automáticamente te responde «Hola, ¿en qué puedo ayudarte?». Tú, pensando que es una conversación normal, le sueltas «¿Me puedes ayudar con un problema?». Y entonces pasa lo peor: el agente responde de nuevo, pero esta vez solo a tu segundo mensaje, como si fuera una interacción nueva. La conversación se rompe, se siente robótica y el usuario nota al instante que está hablando con una máquina.

¿Cuál es la diferencia clave? Pues que sin buffer, tu agente responde a cada mensaje individual. Con buffer, puede esperar unos segundos, agrupar lo que el usuario diga en ese tiempo y generar una respuesta única y coherente a todo el bloque. ¿Por qué te digo que esto es tan importante? Porque nadie habla en frases sueltas y perfectamente espaciadas. Nosotros soltamos ideas en ráfagas, y una IA que quiera parecer natural tiene que entender ese ritmo, ¿vale?

La experiencia del usuario final cambia por completo. Deja de ser una secuencia de preguntas y respuestas mecánicas y se convierte en un diálogo fluido. El usuario siente que le estás escuchando, que estás procesando su petición completa, no que estás disparando respuestas automáticas al primer estímulo. Y al final, eso es lo que buscamos: que la interacción sea útil, pero también agradable.

La Arquitectura Básica: Redis como Memoria Temporal y el Filtro de Tres Caminos

Para construir este buffer necesitas una memoria temporal rápida. Ahí es donde entra Redis. Redis es una base de datos en memoria de código abierto (BSD license), usada como caché, broker de mensajes y base de datos. En nuestro caso, la usamos como un almacén ultrarrápido donde dejar los mensajes que van llegando, solo el tiempo necesario para decidir si hay que esperar más o ya podemos continuar.

La arquitectura del ciclo es sencilla en teoría, pero hay que entender bien cada paso. Te lo explico como si fuera una cadena de montaje: 1. Guardar: Cuando llega un mensaje (por Telegram, WhatsApp, etc.), lo primero que hacemos es subirlo a Redis. 2. Obtener: Inmediatamente después, le pedimos a Redis que nos devuelva ese mismo mensaje (o la lista de mensajes) para trabajarlo. 3. Filtrar: Aquí está el núcleo. El mensaje obtenido pasa por un filtro (en realidad un nodo Switch en N8N) que tiene tres caminos posibles: Ignorar, Continuar o Esperar (Wait).

¿Por qué Redis y no guardarlo en otro sitio? Pues porque es volátil por diseño. No queremos que los mensajes se queden ahí eternamente, solo el tiempo que dure la sesión de chat. Según el mensaje se valida y pasa al agente, lo borramos del buffer. Así liberamos memoria y evitamos acumular basura. Piensa en Redis como una pizarra que se borra constantemente, no como un archivo.

El Paso Crítico Que Todos Se Saltan: Normalizar el Input Antes de Empezar

Aquí viene uno de los errores que más me hizo perder tiempo. Da igual si tu mensaje viene de Telegram, WhatsApp, Instagram o un chatbot web. Cada plataforma te manda los datos con nombres distintos: chat_id, message_id, from.number, etc. Si intentas construir tu workflow dependiendo de esos nombres específicos, te atas a una plataforma y el día que quieras añadir otra, tienes que rehacer todo.

La solución es tan simple que casi da vergüenza no haberla visto antes, ¿vale? Justo después del nodo de entrada (el trigger), pon un nodo «Set» (o Edit Fields). Su única misión es mapear y estandarizar. ¿Qué significa eso? Que vas a coger todas las variables que te lleguen, las vas a renombrar y dejar en un formato consistente.

Por ejemplo, el identificador único del chat, que puede ser un número de teléfono o un ID numérico, lo vas a guardar siempre bajo la misma clave, por ejemplo chat_id. El texto del mensaje, siempre como texto. La fecha, siempre como fecha. Y aquí un detalle crucial que me dio problemas: Redis necesita que las claves sean strings (texto). Si tu chat_id llega como un número, N8N lo tratará como número y puede dar errores. En el nodo Set, lo conviertes a texto. Yo incluso le añadía un prefijo como "chat:" para asegurarme.

¿El resultado? A partir de ese nodo, todo tu workflow trabaja sobre variables genéricas como chat_id y texto. Las plantillas que uses después funcionarán da igual de dónde venga el mensaje. N8N es una herramienta de automatización de workflows low-code basada en Node.js, y este paso de normalización es el que aprovecha realmente su potencia para crear flujos reutilizables.

Explicando el Bucle de Espera: Cómo el Filtro Decide Si Continúa, Espera o Ignora

Esta es la lógica que hace magia el buffer. Vamos a desglosarla paso a paso, porque entender esto es lo que evita que tu flujo se vuelva loco.

1. La lógica del filtro (Switch): Cuando el mensaje obtenido de Redis llega al nodo Switch, se evalúa en tres ramas definidas por ti.
2. Rama 1: Ignorar. Esta rama comprueba si el session_id o identificador del mensaje NO coincide con el del chat actual. ¿Por qué te digo esto? Imagina que tu bot es público y dos personas te escriben a la vez. No quieres que la respuesta para el usuario A se le mande al usuario B porque sus mensajes se mezclaron en el buffer. Si los IDs no coinciden, esta rama activa y el flujo se detiene ahí para ese mensaje. Es un mecanismo de seguridad.
3. Rama 2: Continuar. Esta es la rama de éxito. Se activa cuando han pasado los segundos de espera configurados (por ejemplo, 7) y el mensaje que hay ahora en Redis es el mismo que el que evaluamos antes. Significa que el usuario no ha enviado nada nuevo en ese tiempo. Cuando se activa esta rama, el flujo continúa: se borra ese mensaje (o grupo de mensajes) de Redis y se pasa al nodo de tu agente de IA para que genere la respuesta.
4. Rama 3: Esperar (Wait). Esta es la que crea el bucle. Se activa cuando el mensaje SÍ coincide con el ID del chat actual (para no ignorarlo), pero aún no ha pasado el tiempo de espera o hay mensajes nuevos. Lo que hace esta rama es, simplemente, pausar el flujo durante esos 7 segundos (o los que tú pongas).
5. La ‘rueda’: Después de la pausa, el flujo no va hacia adelante. En su lugar, vuelve atrás al nodo de «Obtener mensaje de Redis». ¿Por qué? Porque durante esa espera, el usuario pudo haber enviado un segundo mensaje («¿me puedes ayudar?»). Al volver a obtener, ahora Redis tendrá una lista con dos mensajes: [«Hola», «¿me puedes ayudar?»]. Este bloque nuevo pasa otra vez por el Switch. Como es un bloque distinto al anterior (ahora tiene dos textos), la rama «Continuar» no se activará (porque el mensaje no es el mismo), y la rama «Esperar» se activará de nuevo, pausando otros 7 segundos. Esto se repite hasta que el usuario deja de escribir. Cuando pasa el tiempo de espera sin nuevos mensajes, el bloque final pasa por la rama «Continuar» y el agente responde a todo.

Es como una rueda que sigue girando: entra mensaje -> espera -> verifica si es el mismo (o hay más) -> repite o continúa. La clave es que siempre está verificando la sesión para ignorar mensajes de otros chats y solo acumula para el chat activo.

Configuración Paso a Paso en N8N: Desde el Input Hasta la Respuesta del Agente

Vamos a lo práctico. Te explico cómo montar el flujo en N8N basándome en lo que a mí finalmente me funcionó, después de muchos intentos.

Paso 1: El nodo inicial de mapeo (Set). Conecta este nodo justo después de tu trigger (Telegram, WhatsApp, etc.). Dentro, añade campos para mapear las variables clave. Como mínimo, necesitarás: * chat_id: Arrastra aquí el ID único del chat desde el nodo anterior. Luego, en la opción de tipo, cámbialo de «Number» a «String». Para asegurarte, en el campo de expresión (el icono de llave inglesa), puedes poner algo como "chat:" + $json["chat_id"]. Así lo conviertes en texto con un prefijo. * texto: Arrastra aquí el contenido del mensaje. * session_id: Arrastra aquí también el chat_id o un ID de sesión, para usarlo luego en el filtro. * fecha: Arrastra la marca de tiempo. Puede que necesites transformar el formato a milisegundos. Si no sabes cómo, se lo pides a ChatGPT: «crea una expresión para N8N que convierta esta fecha a milisegundos».

Paso 2: Guardar el mensaje en Redis. Añade un nodo de Redis. Selecciona la operación «Push to list». En el campo «List Name», arrastra tu variable chat_id desde el nodo Set. Esto creará una lista única en Redis para cada usuario. En «Data», no pongas solo el texto. Crea un JSON que incluya toda la información que necesites más adelante, por ejemplo:

{
  "mensaje": "{{$json[\"texto\"]}}",
  "session_id": "{{$json[\"session_id\"]}}",
  "fecha": "{{$json[\"fecha\"]}}"
}

Marca la opción «Tail». Esto asegura que los mensajes se añadan en orden al final de la lista.

Paso 3: Obtener el mensaje de Redis. Añade otro nodo de Redis justo después. Esta vez, la operación es «Get from list». En «Key», arrastra de nuevo el chat_id desde el nodo Set (¡no desde el nodo Redis anterior!). Esto es importante para evitar errores en el bucle. En «Property Name» pon algo como mensaje_buffer. Aquí obtendrás el último bloque de mensajes acumulado.

Paso 4: El nodo filtro con sus tres ramas. Añade un nodo «Switch». Configura tres reglas: 1. Ignorar: La condición será que el session_id del mensaje obtenido no sea igual al session_id del chat actual (que tienes guardado en el nodo Set). Usa una expresión como $json["mensaje_buffer"].session_id != $node["Set"].json["session_id"]. 2. Continuar: La condición será que el session_id del mensaje obtenido sí sea igual al del nodo Set, y que hayan pasado los segundos de espera. Esta lógica a veces se maneja mejor con un nodo «IF» separado tras el Switch, comprobando si el mensaje actual es igual al anterior. 3. Esperar: No lleva una condición compleja. En el Switch, configura una rama por defecto (o una condición que capture cuando no se cumplan las anteriores). En esta rama, conecta un nodo «Wait» configurado a, por ejemplo, 7 segundos. Tras el nodo Wait, conecta una flecha de vuelta al Paso 3 (el nodo «Obtener de Redis»). Esto crea el bucle.

Paso 5: Borrar de Redis y pasar al agente. Cuando el flujo sale por la rama «Continuar», significa que ya tenemos el bloque final de mensajes. Lo primero que hay que hacer es limpiar. Añade un nodo Redis con la operación «Delete» y en «Key» pon el chat_id. Luego, el mensaje (o la lista de mensajes) que obtuviste en el Paso 3 es lo que debes pasarle a tu agente de IA para que genere la respuesta. Conecta ese output al nodo de tu modelo (Claude, GPT, etc.).

Mi Experiencia y Errores Comunes (Para Que No Los Cometas Tú)

Te voy a contar los problemas con los que me topé, para que te ahorres el mismo sufrimiento.

• Los días de prueba y error hasta que funcionó. No fue cosa de una tarde. Estuve literalmente días cambiando configuraciones, viendo por qué el bucle se rompía o por qué no se acumulaban los mensajes. La clave fue aislar y probar cada nodo por separado, especialmente la lógica del Switch.
• El error de no aislar el ID del chat correctamente. Al principio, en el nodo «Obtener de Redis» (Paso 3), yo ponía como Key el chat_id tomado del nodo Redis anterior (el del Paso 2). Esto funciona la primera vez, pero cuando el bucle se activa y vuelve atrás, el nodo anterior ya no es el de Redis, sino el de Wait. La referencia se rompe y da error. La solución fue siempre, siempre, tomar el chat_id del nodo Set inicial, que es estable y no cambia.
• Cuidado con copiar nombres de variables literalmente. En mi flujo, al nodo Set le puse de nombre «Edit Field». Si tú ves mi vídeo y copias la expresión $node["Edit Field"]... pero tú has nombrado a tu nodo «Mapeo Inicial», no te funcionará. Tienes que ajustar las referencias al nombre que tú hayas usado.
• Por qué el audio es más complejo de manejar en este buffer. En mi flujo final, tengo un filtro antes del buffer que pregunta: ¿el input es audio o texto? Si es audio, lo mando por otro camino directo al agente (transcribiéndolo antes). ¿Por qué te digo esto? Porque las transcripciones de audio nunca son idénticas. Si el usuario manda un audio, se transcribe, se guarda en Redis, se espera 7 segundos, y luego se vuelve a obtener y transcribir para comparar… casi seguro que habrá mínimas diferencias (una coma, una palabra). El filtro nunca vería dos transcripciones «iguales» y el bucle sería infinito. Para audio, es mejor manejarlo como una interacción única sin buffer.

Más Allá del Tutorial: Cómo Integrar Esto en Tu Flujo Real

Ya tienes el buffer funcionando, pero esto es solo un módulo. La potencia real está en cómo lo integras en tu agente completo.

Si usas Instagram, WhatsApp Business o Telegram, la adaptación es inmediata. Recuerda: todo el truco está en el Paso 1, el nodo de mapeo. Sea cual sea la plataforma, ahí conviertes sus variables raras en tu estándar chat_id, texto y fecha. El resto del workflow (los pasos 2 al 5) queda exactamente igual. Eso es la belleza de haber normalizado al principio.

Este buffer hace que tus plantillas de prompt sean más robustas. Al recibir un bloque de mensajes en lugar de uno suelto, tu agente tiene más contexto de una vez. Puedes crear prompts del estilo: «El usuario ha dicho lo siguiente en varios mensajes: [Bloque de mensajes]. Resume su intención principal y responde de manera apropiada.» La calidad de las respuestas mejora porque la IA tiene más información para trabajar desde el primer momento.

El siguiente paso, y con lo que estoy yo ahora, es evolucionar tu agente a esta versión 4.0. No es solo añadir el buffer; es rediseñar todo el flujo alrededor de esta capacidad de conversación natural. Implica revisar cómo gestionas la memoria a largo plazo del chat, cómo formateas las respuestas y cómo controlas los timeouts para no dejar conversaciones abiertas eternamente.

Si quieres ver cómo queda todo esto integrado en un agente real, desde el trigger hasta la respuesta, tengo un vídeo en mi canal donde lo muestro en vivo. Y si te ha servido este artículo y quieres seguir aprendiendo sobre cómo automatizar con IA, suscríbete al canal. Ahí es donde subo las soluciones reales que voy encontrando, con los errores incluidos, para que aprendas desde la práctica, no desde la teoría perfecta.