Cómo dar memoria a tus agentes de IA en n8n: guía completa

Los modelos de lenguaje (LLMs) son increíbles, pero tienen un problema de base: son estadoféricos. Cada vez que hablas con ellos empiezan desde cero, sin recordar nada de la conversación anterior. No es un fallo, es cómo funcionan por diseño. Y cuando intentas construir un agente de IA que mantenga el contexto a lo largo del tiempo, te das cuenta de que ampliar la ventana de contexto no es suficiente.

Por suerte, n8n lo ha resuelto de forma elegante. La última versión de la plataforma incluye nodos específicos para gestionar la memoria de tus agentes, y en esta guía te explico cómo usarlos.

El problema: el contexto no es memoria

Los modelos actuales soportan ventanas de contexto enormes (hasta 1 millón de tokens), pero eso no significa que recuerden bien todo lo que hay dentro. La precisión de recuperación cae para información en medio de la ventana, no hay priorización de datos importantes, y los tokens cuestan dinero. Pasarle todo el historial a cada llamada es como fotocopiar toda tu libreta cada vez que necesitas recordar una página: funciona, pero es caro e ineficiente.

Además, sin almacenamiento persistente, cada sesión empieza de cero. Los productos de consumo como ChatGPT o Claude ya extraen hechos para memoria entre sesiones, pero los agentes personalizados requieren implementación explícita.

Los cuatro tipos de memoria para agentes IA

n8n sigue el framework CoALA (Cognitive Architecture for Language Agents) para clasificar la memoria. Cada tipo se elige por lo que representa, no por dónde se almacena:

  • Memoria de trabajo (Working Memory): El prompt actual, las últimas interacciones, el estado inmediato de la tarea. Vive en la ventana de contexto y se evapora al cerrar la sesión.
  • Memoria semántica (Semantic Memory): Conocimiento general: políticas de empresa, documentación de productos, FAQs. Se almacena en bases de datos vectoriales (Pinecone, Weaviate, Qdrant) con búsqueda por similitud.
  • Memoria episódica (Episodic Memory): Historial de interacciones: qué se dijo, qué se hizo, cuándo. Requiere indexación temporal además de la búsqueda vectorial.
  • Memoria procedural (Procedural Memory): Comportamientos codificados: secuencias de llamadas a herramientas, reglas de escalado. Normalmente va en el prompt del sistema.

En producción, la mayoría de los agentes combinan al menos dos tipos. Por ejemplo, un agente de soporte al cliente usa un buffer para la conversación actual, una base de datos para el historial de sesiones y un almacén vectorial para buscar entre miles de tickets pasados.

Cómo implementar memoria en n8n paso a paso

n8n trata la memoria como un primitivo de workflow configurable. Los nodos de memoria se sientan en el canvas junto al resto de la lógica, sin necesidad de código externo.

1. Memoria a corto plazo (Simple Memory)

El nodo Simple Memory funciona por sesión con un ID de sesión. Cada sesión mantiene sus memorias aisladas. Funciona de serie para despliegues de instancia única. Si usas modo cola (varios workers), necesitas Postgres Chat Memory o Redis Chat Memory para aislamiento fiable entre workers.

2. Control avanzado: Chat Memory Manager

El nodo Chat Memory Manager te permite insertar, recuperar o borrar memorias específicas mediante programación. Puedes comprobar el tamaño de la memoria, eliminar entradas antiguas o inyectar contexto. Combínalo con nodos de código JavaScript o Python para reglas de retención personalizadas.

3. Memoria a largo plazo con almacenamiento persistente

Para memoria que sobreviva a reinicios y sesiones, n8n ofrece múltiples opciones:

  • Postgres Chat Memory: Historial cronológico de conversaciones en base de datos relacional.
  • Redis Chat Memory: Historial cronológico rápido, ideal para datos efímeros.
  • Vector Stores (Pinecone, Weaviate, Qdrant, MongoDB Atlas): Búsqueda semántica y episódica por similitud.
  • Entity Memory (Zep Memory node): Extracción automática de hechos sobre usuarios, sesiones y entidades, combinando extracción, resumen y recuperación.

Lo mejor: cambiar de Pinecone a MongoDB Atlas no requiere reescribir el agente. El backend de almacenamiento se intercambia sin tocar la lógica del workflow.

Stack típico de producción en n8n

Un agente n8n en producción suele combinar:

  • Nodo AI Agent como orquestador principal
  • Simple Memory o Postgres Chat Memory para el historial de conversación
  • Vector Store como herramienta del agente para búsqueda semántica (documentación, FAQs, historial de tickets)
  • Chat Memory Manager para control fino: inyectar contexto antes de responder, limpiar memoria periódicamente, etc.

Ejemplo práctico: agente de soporte con memoria

Imagina que tienes una tienda online y recibes 20 consultas al día por email. Un agente n8n con memoria puede gestionar la mayoría sin que tú tengas que intervenir. Así sería el flujo:

  1. Trigger: Email recibido — El workflow se dispara cuando llega un email nuevo del cliente.
  2. Extraer datos del cliente — Un nodo de código Javascript extrae el email del remitente y busca en tu CRM si es un cliente nuevo o recurrente usando el nodo n8n «Customer Lookup».
  3. Consultar memoria episódica — El agente busca en Postgres Chat Memory si hay interacciones previas con ese cliente. Si es recurrente, el agente sabe qué le preocupó la última vez y retoma el hilo sin que el cliente tenga que repetirse.
  4. Consultar memoria semántica — El agente busca en una base de datos vectorial (Pinecone, Qdrant) la documentación o FAQs relevantes para responder a la consulta actual. No necesita tener la respuesta memorizada: la busca por similitud semántica.
  5. Generar respuesta — El nodo AI Agent combina el historial de la conversación + la documentación recuperada + el contexto actual y genera una respuesta personalizada.
  6. Guardar en memoria — El nodo Chat Memory Manager guarda la interacción en Postgres Chat Memory con un ID de sesión, para que la próxima vez que el cliente escriba, el agente sepa exactamente en qué punto se quedó la conversación.
  7. Responder al cliente — El workflow envía el email de respuesta y marca el ticket como gestionado.

Lo mejor: si quieres cambiar de Pinecone a Qdrant o a Postgres como backend vectorial, solo cambias el nodo. El resto del flujo no se toca. Esa es la potencia de n8n: la memoria es un componente intercambiable, no un bloque monolítico.

Para qué sirve todo esto en la práctica

Un agente con memoria puede recordar preferencias de un cliente, retomar conversaciones exactamente donde se quedaron, buscar en su propia experiencia pasada para resolver problemas recurrentes, y mantener coherencia a lo largo de semanas de interacción. Sin memoria, cada conversación empieza desde cero. Con memoria, tu agente se vuelve útil de verdad.

Y lo mejor de todo: en n8n no necesitas ser ingeniero de machine learning para implementarlo. Es cuestión de arrastrar nodos y conectarlos aunque, no te voy a mentir, sí que necesitas nociones básicas para saber qué estás haciendo.

N8N ha conseguido algo que hace años era impensable: facilitar de forma gráfica lo que hace no tanto se podía hacer sólo con conocimientos muy técnicos. Y así es como debería funcionar la tecnología.

Fuente: n8n Blog — AI Agent Memory: Types, Storage, and Retrieval Guide

Deja un comentario