Tabla de contenidos
- ¿Por qué los agente de IA olvidan?
- Workflow vs. agente: la memoria es el diferencial
- Los 4 tipos de memoria para agentes de IA
- El enfoque file-based: el vault de tu agente
- Cómo darle memoria: frameworks y la Memory Tool de Claude
- Que la memoria mejore sola: context engineering y compactación
- Qué guardar según tu tipo de agente
- Conclusión
- Preguntas frecuentes
¿Por qué los agente de IA olvidan?
Los modelos LLM funcionan con lo que se llama una context window: la franja de tokens que el modelo puede «ver» mientras genera una respuesta. Claude tiene 200.000 tokens; GPT-4o, alrededor de 128.000. Suena a mucho, pero hay un problema estructural: cuando la sesión termina, esa ventana se cierra. No hay ningún mecanismo nativo que mueva automáticamente el contenido de una conversación a un almacén persistente. Si no programas esa capa, el agente empieza cada sesión en blanco.
El equipo de Anthropic Engineering ha documentado otro problema relacionado: el «context rot». A medida que el context window crece y se llena de información acumulada, la precisión del modelo disminuye. No es que el modelo sea perezoso; es que el volumen de tokens compite por atención y la calidad de las respuestas baja. Más contexto no siempre es mejor contexto.
Para una empresa, esto tiene un coste concreto. Un agente de soporte que no recuerda al cliente X entre conversaciones le pide el mismo DNI tres veces. Un agente de ventas que no recuerda las preferencias del lead A empieza el pitch desde el principio en cada llamada. Un agente de gestión de proyectos que no retiene las decisiones del lunes repite los mismos debates el jueves. Son horas perdidas, y la confianza del usuario en el sistema se erosiona rápido cuando percibe que el agente «no aprende».
La solución no es meter más tokens en el context window. La solución es diseñar una capa de memoria externa que exista fuera del modelo y se cargue selectivamente al inicio de cada sesión. Exactamente igual que tú abres el historial de un cliente antes de llamarle.
Workflow vs. agente: la memoria es el diferencial
Antes de entrar en la implementación, conviene dejar clara una distinción que mucha gente confunde. Hay dos tipos de sistema basados en IA que circulan bajo el mismo nombre «agente» y no son lo mismo.
Un workflow con IA es una secuencia de pasos predefinidos donde el LLM ejecuta tareas discretas. Recibe un input, genera un output, el trabajo termina. Es determinista: si le das el mismo input, hace lo mismo. No aprende, no se adapta, no recuerda. Es útil para automatizaciones simples y repetibles, como clasificar emails o resumir documentos.
Un agente de IA es distinto: tiene un loop de razonamiento-acción que le permite tomar decisiones, usar herramientas y adaptar su comportamiento según el contexto. Pero esa adaptación solo es real si hay un mecanismo que retenga lo aprendido entre sesiones. Sin memoria persistente, el agente tiene el loop pero no tiene historia. Ejecuta y olvida como un workflow, aunque sea más sofisticado.
La diferencia que hace que un sistema de IA pase de ser un workflow glorificado a ser un verdadero agentes de IA para empresas no es la complejidad del razonamiento, es la memoria. Un agente con memoria aprende de cada interacción, refina su modelo del mundo y se vuelve más preciso con el tiempo. Esa es la promesa real de la IA autónoma en entornos de negocio.
Los 4 tipos de memoria para agentes de ia
El framework CoALA, publicado por investigadores de Princeton en 2023 y adoptado por IBM, LangChain y Letta como referencia estándar, identifica cuatro tipos de memoria en los agentes LLM. Aquí no los desarrollaremos en profundidad, si te interesa para eso existe el post dedicado a los tipos de memoria en agentes LLM , pero sí conviene tener el mapa claro antes de entrar en la implementación.
| Tipo | Analogía humana | Dónde vive | Se pierde al cerrar sesión |
|---|---|---|---|
| In-context (working memory) | La RAM del ordenador | Context window activo | Sí, siempre |
| Episódica | Tu diario personal | Base de datos de acciones pasadas | No, si está externalizada |
| Semántica | Tu enciclopedia interna | Vector store o ficheros de conocimiento | No, si está externalizada |
| Procedimental | Tu memoria muscular | System prompt o fichero de instrucciones | No, está en el sistema |
El takeaway práctico: solo la memoria in-context es volátil por diseño. El resto ( episódica, semántica y procedimental )puede y debe persistir fuera del modelo si quieres un agente que mejore con el tiempo. La arquitectura que logra eso se llama memoria externalizada, y la forma más sencilla de implementarla es un vault de ficheros.
El enfoque file-based: el vault de tu agente
Un vault es simplemente un directorio de ficheros de texto (habitualmente markdown )donde el agente guarda y recupera información entre sesiones. No hay base de datos, no hay embeddings, no hay infraestructura especial. Un fichero de texto que el agente lee al empezar y actualiza al terminar.
La estructura que funciona bien en producción organiza el vault en carpetas por tipo de información y añade tres ficheros de identidad en la raíz:
- People/ — perfiles de contactos, clientes, interlocutores.
- Projects/ — estado actual de cada proyecto, decisiones tomadas, próximos pasos.
- Decisions/ — log de decisiones importantes con contexto y razonamiento.
- Companies/ — información sobre empresas clientes o proveedoras.
- Meetings/ — notas de reuniones, acuerdos, compromisos.
- Daily/ — log cronológico de actividad (útil para la compactación nocturna).
- Knowledge/ — conocimiento factual específico del dominio.
- USER.md — preferencias del usuario, estilo de comunicación, contexto personal.
- SOUL.md — valores y principios de comportamiento del agente.
- IDENTITY.md — rol del agente, qué sabe hacer y qué no, límites explícitos.
El ciclo de uso es el que importa: el agente lee los ficheros relevantes al inicio de cada sesión (carga selectiva, no todo el vault), actúa con ese contexto, y al terminar escribe en el vault lo que aprendió o cambió. El vault crece con cada sesión. Esto es lo que en la práctica convierte a Obsidian con IA en una opción popular para implementar este patrón: las notas de Obsidian son exactamente los ficheros markdown del vault, y los plugins de IA disponibles en el ecosistema hacen que la lectura y escritura sean accesibles sin escribir código.
+-------------------+
| Inicio de sesión |
| Lee vault |
+--------+----------+
|
v
+--------+----------+
| Razonamiento |
| y ejecución |
+--------+----------+
|
v
+--------+----------+
| Escribe vault |
| (lo que aprendió)|
+--------+----------+
|
v
+--------+----------+
| Cron nocturno |
| Compacta vault |
| Vault más denso |
+-------------------+
La ventaja del enfoque file-based frente a alternativas más complejas (vector stores, bases de datos SQL) es triple: portabilidad (los ficheros markdown son legibles por humanos y cualquier herramienta), auditabilidad (puedes abrir el vault y ver exactamente qué sabe el agente), y coste (no necesitas infraestructura adicional). Para la mayoría de PYMEs, empezar con file-based memory es la opción más pragmática antes de escalar a algo más sofisticado.
Cómo darle memoria: frameworks y la Memory Tool de Claude
Hay dos caminos para implementar memoria persistente en un agente. El primero es usar un framework especializado; el segundo es usar la capa nativa del modelo.
En cuanto a frameworks, el ecosistema ha madurado rápido. Mem0 es la opción open source con mayor adopción , con más de 40.000 estrellas en GitHub, y sus benchmarks son llamativos: según datos de Atlan, Mem0 reporta un 91% menos de latencia y un 90% de ahorro en coste de tokens frente a meter todo el historial en el context window. Para una comparativa detallada de Mem0 frente a LangMem, Letta y Zep, el post dedicado a frameworks de memoria para agentes cubre cada opción con criterios de selección por perfil técnico y presupuesto.
En cuanto a la capa nativa, Anthropic lanzó la Memory Tool oficial para Claude: tipo memory_20250818, disponible en todos los modelos Claude 4+ sin necesitar ningún beta header. La documentación oficial describe exactamente lo que hace: «The memory tool lets Claude store and retrieve information across conversations in a directory of memory files. Claude can create, read, update, and delete files that persist between sessions, building up knowledge over time without keeping everything in the context window.» Es, en esencia, un vault file-based gestionado por el propio modelo.
El patrón de uso correcto con la Memory Tool sigue el ciclo del diagrama: lectura del vault antes de actuar, escritura al terminar. Anthropic recomienda en su blog de ingeniería el patrón «structured note-taking»: los agentes mantienen un fichero NOTES.md con memoria persistente y los sub-agentes devuelven resúmenes de 1.000-2.000 tokens al agente coordinador, en lugar de pasar el historial completo. Este patrón es el que evita el context rot y mantiene la calidad de las respuestas estable en producción. Una arquitectura basada en Model Context Protocol encaja de forma natural con esta capa de memoria, ya que MCP es el protocolo que conecta al agente con las herramientas externas (incluyendo el propio vault).
Que la memoria mejore sola: context engineering y compactación
Guardar información en el vault no es suficiente. Sin un mecanismo de limpieza y síntesis, el vault acumula ruido: notas redundantes, datos desactualizados, contexto que ya no es relevante. Un vault que crece sin control acaba siendo tan inútil como no tener vault.
La solución es la compactación nocturna: un cron que se ejecuta fuera del horario de uso y que tiene como único trabajo revisar el vault, eliminar duplicados, consolidar notas relacionadas y elevar el nivel de abstracción de la información almacenada. El resultado es lo que algunos practitioners llaman «compound memory»: cada ciclo de compactación convierte datos brutos en conocimiento más denso y más útil. El vault de dentro de un mes es cualitativamente superior al de hoy, aunque haya ocupado menos espacio.
Esto conecta directamente con la disciplina del context engineering: la práctica de diseñar qué entra en el context window en cada momento, en qué formato y con qué nivel de detalle. La memoria de la IA persistente es la materia prima; el context engineering es la disciplina que decide qué parte de esa memoria es relevante ahora mismo. Juntas, hacen que el agente sea más preciso y más eficiente con cada sesión.
El impacto en métricas de negocio es real. Snowflake ha publicado datos que muestran una mejora del 20% en precisión de respuestas y una reducción del 39% en llamadas a herramientas cuando el agente tiene acceso a una capa de memoria estructurada, frente a trabajar solo con el context window activo. Menos llamadas a herramientas significa menos latencia y menos coste por sesión.
Qué guardar según tu tipo de agente
La arquitectura es la misma para todos, pero el contenido del vault cambia radicalmente según el trabajo que hace el agente. Estos son los tres casos más comunes en el contexto B2B de las automatizaciones con IA para empresas:
Agente de ventas: el vault debe incluir el historial de cada deal (estado, objeciones recurrentes, fechas de seguimiento), las preferencias de comunicación de cada lead (formal/informal, canal preferido, sensibilidad al precio), y el log de decisiones del pipeline. Lo que NO debe guardar: datos bancarios, información salarial, ni ningún dato personal que no sea necesario para el proceso de venta. El objetivo es que el agente pueda retomar una conversación con el mismo nivel de contexto que un comercial veterano que lleva el CRM al día.
Agente de soporte al cliente: perfiles de cliente (empresa, producto contratado, historial de incidencias, nivel de satisfacción estimado), soluciones que ya se intentaron y no funcionaron, y escalaciones previas. El agente de soporte que recuerda que el cliente X ya llamó tres veces por el mismo problema — y que las dos veces anteriores la solución no funcionó — puede ofrecer una respuesta cualitativamente distinta desde el primer mensaje.
Agente de onboarding: estado actual del proyecto para cada cliente (qué se ha entregado, qué está pendiente, qué está bloqueado), preferencias del equipo del cliente, decisiones de configuración ya tomadas. El onboarding es el proceso donde la memoria tiene mayor impacto porque la curva de aprendizaje del cliente es empinada y el agente necesita no repetir lo ya explicado.
En los tres casos, hay una regla de oro: guardar decisiones y contexto, no transcripciones completas. El vault no es un archivo de chat; es un repositorio de conocimiento estructurado. La diferencia entre los dos marca la diferencia entre un vault que mejora con el tiempo y uno que se vuelve inmanejable en semanas.
Un apunte sobre GDPR: si el vault contiene datos personales de clientes (nombres, emails, historial de incidencias), estás gestionando un fichero de datos personales que cae bajo el RGPD. El Artículo 17 (derecho al olvido) aplica: si un cliente solicita la eliminación de sus datos, debes ser capaz de localizar y borrar todo lo que el vault contiene sobre esa persona. El enfoque file-based tiene aquí una ventaja concreta: los ficheros son auditables y eliminables de forma quirúrgica. Con un vector store propietario, la eliminación de un registro puede ser más compleja. Diseñar el vault pensando en este requisito desde el principio ahorra problemas legales después.
Preguntas frecuentes sobre memoria de agentes de IA
¿Qué es la memoria de un agente de IA?
La memoria de un agente de IA es el conjunto de mecanismos que permiten al sistema retener y recuperar información entre sesiones. Sin memoria externa, cada conversación empieza desde cero porque el modelo solo tiene acceso a lo que hay en el context window activo. Con memoria externalizada — ya sea un vault de ficheros, una base de datos vectorial o un framework como Mem0 — el agente puede acumular conocimiento sobre el usuario, los proyectos y las decisiones tomadas, y usar ese conocimiento en futuras sesiones para dar respuestas más precisas y personalizadas.
¿Cuál es la diferencia entre un workflow y un agente de IA?
Un workflow con IA ejecuta una secuencia fija de pasos y olvida todo al terminar. Es útil para tareas repetitivas y predecibles. Un agente de IA tiene un loop de razonamiento-acción que le permite tomar decisiones, usar herramientas y adaptarse al contexto. La diferencia clave no está en el loop — está en si el agente tiene memoria persistente. Un agente sin memoria entre sesiones funciona en la práctica como un workflow más sofisticado: ejecuta y olvida. La memoria es lo que convierte el sistema en algo que aprende y mejora.
¿Cómo se le da memoria persistente a un agente como Claude?
Hay dos caminos principales. El primero es usar la Memory Tool oficial de Anthropic (tipo memory_20250818), disponible en todos los modelos Claude 4+ sin beta header. Esta herramienta permite al modelo leer y escribir ficheros en un directorio de memoria que persiste entre sesiones. El segundo camino es usar un framework externo como Mem0, que gestiona la memoria a nivel de aplicación y se integra con la API de Claude. En ambos casos, el patrón es el mismo: leer el vault relevante al inicio, actuar, escribir lo aprendido al terminar.
¿Qué es un vault de ficheros y por qué usar markdown?
Un vault es un directorio de ficheros de texto donde el agente almacena información persistente. Se organiza en carpetas por tipo de dato (People, Projects, Decisions, etc.) más ficheros de identidad en la raíz (USER.md, SOUL.md, IDENTITY.md). Se usa markdown porque es un formato legible por humanos y por máquinas, sin dependencias, versionable con git y compatible con herramientas como Obsidian. La auditabilidad es la ventaja clave: cualquier miembro del equipo puede abrir el vault y ver exactamente qué sabe el agente, sin necesitar acceso a una base de datos.
¿Es seguro guardar datos de clientes en la memoria del agente?
Sí, siempre que el vault esté correctamente securizado y el diseño cumpla con el RGPD. Los datos personales de clientes (nombres, emails, historial) son datos personales según la definición del Artículo 4 del RGPD. Debes tener base legal para el tratamiento, aplicar medidas técnicas de seguridad (acceso restringido, cifrado en reposo si el vault está en servidor compartido), y ser capaz de ejecutar el derecho al olvido del Artículo 17, lo que implica poder localizar y eliminar todos los registros de una persona concreta. El enfoque file-based tiene ventaja aquí: la eliminación es quirúrgica y auditable.
¿Qué tipos de memoria existen en los agentes de IA?
El framework CoALA (Princeton, arXiv:2309.02427), referencia estándar del campo, define cuatro tipos: memoria in-context o de trabajo (lo que el modelo ve en el context window activo, volátil), memoria episódica (registro de acciones y conversaciones pasadas, externalizable), memoria semántica (conocimiento factual persistente sobre entidades, dominios o el propio usuario, externalizable) y memoria procedimental (instrucciones y reglas de comportamiento del agente, habitualmente en el system prompt). Para una guía detallada de cada tipo con criterios de selección, consulta el post sobre tipos de memoria en agentes LLM.
Conclusión
La memoria no es una feature avanzada que se añade después de que el agente ya funciona. Es la diferencia entre un agente que ejecuta tareas y una IA con memoria que aprende de ellas. El vault de ficheros es el punto de entrada más pragmático para cualquier empresa que quiera construir esa capa sin depender de infraestructura compleja. La Memory Tool de Anthropic y frameworks como Mem0 hacen que la implementación técnica sea asequible incluso para equipos pequeños. Y el ciclo de compactación nocturna es lo que convierte ese vault en conocimiento compuesto en lugar de archivo muerto.
Si quieres diseñar la arquitectura de memoria de tu agente con criterio saber qué tipo de memoria necesita, qué guardar, qué framework usar, cómo integrar el cron de compactación podemos ayudarte desde la consultoría de IA de Baigency.
