Por qué olvida tu agente de n8n
Simple Memory es una ventana, y la ventana es pequeña
La configuración Context Window Length del nodo Simple Memory es el número de interacciones anteriores a incluir, y por defecto es 5. Una interacción es un intercambio (un mensaje del usuario más la respuesta del agente), por lo que el valor predeterminado conserva aproximadamente los últimos diez mensajes. Todo lo que sea más antiguo desaparece silenciosamente de la ventana. No se produce ningún error. El agente simplemente deja de hacer referencia a lo que sucedió antes en la misma conversación, razón por la cual los chats largos se degradan en lugar de romperse.
Vive en los datos del flujo de trabajo, por lo que no sobrevive
Simple Memory almacena el historial de chat en los propios datos del flujo de trabajo bajo una clave de sesión. Eso es conveniente en el editor y frágil en cualquier otro lugar: el historial está vinculado al estado de funcionamiento de la instancia y desaparece tras un reinicio o un nuevo despliegue. Este es el clásico reporte de "funciona en desarrollo, lo olvida todo después del despliegue", y el consejo estándar —migrar a la memoria de chat de Postgres o Redis antes de pasar a producción— existe precisamente por eso.
El modo cola lo rompe por completo
La documentación de n8n expone la limitación claramente: si tu instancia utiliza el modo cola (queue mode), este nodo no funciona en un flujo de trabajo de producción activo, porque no hay garantía de que las llamadas de memoria se enruten al mismo worker. Si escalaste n8n horizontalmente y luego te preguntaste por qué la memoria se volvió errática —recordando a veces, olvidando otras—, ese es el mecanismo. Las solicitudes llegan a diferentes workers, y cada worker tiene una idea distinta de lo que se dijo.
La clave de sesión decide quién recuerda qué
La memoria se agrupa por clave de sesión. Con el Chat Trigger, n8n la completa a partir del sessionId entrante, que suele ser lo que se desea. Dos configuraciones erróneas comunes causan síntomas opuestos entre sí:
- Una clave estática codificada (hardcoded) significa que cada usuario comparte una misma memoria: el agente confunde las conversaciones y filtra el contexto entre personas.
- Una clave que cambia en cada ejecución significa que cada mensaje inicia una nueva conversación: el agente parece amnésico aunque técnicamente la memoria esté funcionando.
La memoria tiene un alcance por nodo de agente, por flujo de trabajo
El nodo de memoria se conecta a un único nodo de AI Agent. No es un almacén compartido en toda tu automatización. El agente de soporte en el flujo de trabajo A no sabe nada de lo que el agente de incorporación (onboarding) en el flujo de trabajo B concluyó ayer, incluso para el mismo cliente, y ninguno de los dos sabe lo que tu equipo escribió en el SOP que rige a ambos. Si ejecutas varios agentes, esa fragmentación se agrava; el problema general se aborda en multi-agent memory.
Lo que los equipos intentan primero
Aumentar el Context Window Length
La palanca obvia, y ayuda brevemente. Pero pagas por cada mensaje retenido en cada llamada, la ventana sigue estando limitada y sigue siendo volátil. Has hecho que el olvido ocurra más tarde, no lo has detenido.
Cambiar a la memoria de chat de Postgres o Redis
Este es el paso correcto para producción y deberías darlo: el historial sobrevive a los reinicios y funciona bajo el modo cola. Sin embargo, ten claro lo que te ofrece. Es un almacén de transcripciones duradero indexado por sesión: guarda lo que se escribió, no lo que tu organización sabe. No contiene los documentos de tu producto, tus reglas de precios, las decisiones del trimestre pasado o la resolución del ticket que este cliente abrió en marzo. Pregúntale cualquier cosa fuera de los mensajes de esa sesión y no tendrá nada.
Introducir el contexto en el system prompt
Los equipos pegan la política, la guía de tono y las preguntas frecuentes en el mensaje del sistema (system prompt) del agente. Cada ejecución paga por esos tokens, el texto se desactualiza y actualizarlo significa editar los flujos de trabajo uno por uno. Es el equivalente en automatización a re-explaining context to your AI para siempre.
Construir la recuperación tú mismo
El siguiente paso suele ser un almacén de vectores más un pipeline de embeddings más un subflujo de trabajo de recuperación. Eso puede funcionar, y es un proyecto real: fragmentación (chunking), actualización de embeddings, clasificación (ranking), delimitación de alcance (scoping) y expiración. Tampoco resuelve la memoria por sí solo, por razones que vale la pena leer en why RAG isn't memory: la recuperación encuentra documentos, la memoria guarda conclusiones.
La solución: Dale a tus agentes de n8n una capa de memoria persistente
La memoria de chat y la memoria son dos trabajos diferentes. Mantén un nodo de memoria de Postgres o Redis para la continuidad de la conversación dentro de una sesión, y coloca el conocimiento duradero en una capa que no esté vinculada a un flujo de trabajo, un worker o una clave de sesión. Ese es el papel que desempeña MemoryLake: una memoria única de la que tus agentes leen y en la que escriben, accesible a través de MCP o la API desde cualquier flujo de trabajo que construyas.
Paso 1: Crea una clave de API
Genera una clave y realiza tu primera solicitud en unos 30 segundos.
Paso 2: Sube tus primeras memorias
Arrastra los documentos, imágenes y archivos que tus agentes necesitan constantemente: documentos de producto, SOPs, reglas de precios y políticas, rutas de escalado, resoluciones anteriores. Este es el conocimiento que nunca debió estar en un búfer de chat.
Paso 3: Conecta tu IA y tus agentes
Dale a Claude, Codex, OpenClaw y a tus agentes de n8n acceso a esa memoria a través de MCP o la API: una conexión MCP donde tus herramientas lo admitan, o una solicitud HTTP simple desde el propio flujo de trabajo. Cada ejecución, en cualquier worker, accede a la misma memoria. Si también expones tus propias herramientas a los agentes, adding memory to a custom MCP server y memory for stateless MCP servers cubren ese aspecto.
Qué cambia esto en la práctica
Calcula lo que tus flujos de trabajo repiten actualmente. Si cada ejecución lleva 1,500 tokens de contexto de producto y políticas pegados, y el flujo de trabajo se ejecuta 500 veces al día, eso equivale a 750,000 tokens diarios —alrededor de 22 millones al mes— gastados en volver a enviar texto que nunca cambia. Recuperar solo la parte relevante de una capa de memoria suele costar una fracción de eso.
La mayor victoria es de comportamiento. Un agente de soporte que puede ver el ticket anterior del cliente deja de pedir el ID de la cuenta de nuevo. Un agente de incorporación que lee la misma memoria que el agente de soporte deja de contradecirlo. Y cuando reconstruyas el flujo de trabajo el próximo trimestre, el conocimiento permanecerá en su lugar en vez de quedar atrapado en la versión que eliminaste.
Buenas prácticas para la memoria de agentes en n8n
Mantén las transcripciones y el conocimiento en lugares separados
Usa un nodo de memoria de chat para los últimos turnos de la conversación actual. Usa una capa de memoria para cualquier cosa que deba seguir siendo cierta mañana. Mezclarlos produce almacenes que son simultáneamente demasiado grandes para leer y demasiado superficiales para ayudar.
Vincula la memoria a la entidad, no a la ejecución
Las claves de sesión son para las conversaciones. La memoria duradera debe estar vinculada al cliente, proyecto o cuenta: algo que signifique lo mismo a través de los flujos de trabajo y los meses. Eso es lo que permite que un segundo flujo de trabajo continúe donde se detuvo el primero.
Escribe las conclusiones de vuelta al final de una ejecución
Añade un paso final que almacene lo que decidió la ejecución: la resolución, la excepción concedida, la preferencia que indicó el usuario. Los agentes que solo leen memoria nunca se vuelven más inteligentes; los agentes que escriben en ella acumulan conocimiento. Mantén esas escrituras cortas y objetivas, y prefiere reemplazar un dato desactualizado en lugar de apilar uno nuevo encima.
Conclusión
Tu agente de n8n no está roto. Simple Memory está haciendo exactamente lo que documenta: mantener un puñado de intercambios recientes en los datos del flujo de trabajo, razón por la cual se evapora al reiniciar y no funciona bajo el modo cola en producción. Migrar a Postgres o Redis soluciona la durabilidad de la transcripción, pero deja intacto el vacío más grande, porque una transcripción de una sesión nunca fue lo mismo que conocer tu negocio.
Divide los dos trabajos. La continuidad de la conversación pertenece a un nodo de memoria de chat; el conocimiento institucional pertenece a una capa de memoria que tus flujos de trabajo leen a través de MCP o la API. Así, el próximo agente que construyas comenzará con todo lo que aprendió el anterior, en lugar de una ventana en blanco de cinco intercambios de profundidad.