La memoria es lo que separa un agente útil de un chatbot olvidadizo
Le explicas tu negocio a ChatGPT, mañana es la primera vez otra vez. Esto se llama amnesia y es lo que distingue un loro inteligente de un agente que crece contigo. En este post desarmamos las tres capas de memoria de un agente, comparamos las herramientas serias de 2026 (Mem0, Letta, Zep, MCP) y compartimos el patrón vault-as-memory que usamos en producción, con un repo open source que puedes leer.
Este es el segundo post de una serie de cuatro sobre agentes de IA. Si llegas directo, conviene leer primero el post de fundamentos y después el resto: comparativa y tutorial.
Hoy: la memoria. El componente que casi todo demo ignora y que en producción decide si tu agente es un compañero o un servicio caro de "vuelvo a explicártelo cada lunes".
El problema: los LLM no recuerdan nada
Un modelo de lenguaje, en el fondo, es una función pura. Le pasas un texto, te devuelve un texto. No tiene estado. No hay un disco interno donde "guarde" cosas. Lo único que sabe en cada llamada es lo que le mandaste en esa misma llamada — su famoso contexto.
Cuando hablas con ChatGPT y "se acuerda" de lo que dijiste hace 5 mensajes, no es porque tenga memoria: es porque la app le está reenviando todos los mensajes anteriores en cada turno. Cuando cierres la conversación y abras una nueva, todo eso desaparece. La amnesia es por diseño.
Para un chatbot de Q&A, eso está bien. Para un agente que pretende operar tu negocio, es un problema fundamental. No puedes tener un compañero que cada mañana te pregunta cómo se llama tu empresa.
Las tres capas de memoria que toda arquitectura seria distingue
Cuando hablamos de "memoria de un agente", en realidad estamos hablando de tres cosas distintas que conviene separar.
1. Working memory (memoria de trabajo)
Lo que cabe en el contexto del modelo en este momento. Para Claude Sonnet 4.6 son hasta 200.000 tokens; para Opus 4.7 con extensión, hasta 1 millón. Suena mucho, pero se llena rápido cuando un agente lleva 30 turnos, leyó 5 archivos, y mantiene el log de cada herramienta que llamó.
La working memory es rápida (no hay viaje a un sistema externo) pero costosa (cada token entra al precio del modelo) y volátil (se pierde al terminar la sesión).
Cuanto mejor sepas administrar la working memory — qué meter, qué resumir, qué descartar — más capaz se vuelve tu agente. Esto es lo que en Anthropic llaman context engineering, una disciplina nueva que reemplaza al prompt engineering clásico.
2. Session memory (memoria de sesión)
La conversación actual completa, incluso lo que ya no cabe en el contexto. Suele estar en una base de datos clásica (Postgres, SQLite) o en un store key-value (Redis). El agente la mira para recuperar qué pasó al inicio de la sesión cuando ya pasaron 50 turnos y el comienzo se está saliendo de la ventana.
3. Long-term memory (memoria de largo plazo)
La que sobrevive entre sesiones. Lo que el agente "aprende" de ti, de tu empresa, de tus preferencias. Esta es la que vale oro y la que más mal se hace. Hay tres familias de implementaciones:
- Vector search. Cada hecho se convierte en un embedding (un vector numérico) y se guarda en una base vectorial. Cuando hace falta recordar algo, se busca por similitud semántica. Rápido, escalable, opaco — el agente recupera "lo más parecido", no necesariamente "lo más correcto".
- Knowledge graph. Los hechos se guardan como relaciones (Germani — fundó — ServerStack). Permite razonar sobre conexiones y manejar tiempo (este hecho era cierto hasta marzo, ya no lo es). Más complejo de mantener pero mucho más potente.
- Self-editing memory. El agente decide qué guardar y qué borrar de su propia memoria, escribiendo a archivos o bloques estructurados. Es el patrón que usan Letta, Hermes Agent y los archivos
MEMORY.mdque cada vez más herramientas (incluyendo Claude Code) adoptaron.
Las cuatro herramientas serias de memoria en 2026
Acá hay un mercado real. Te resumimos lo que importa de cada una.
Mem0
Filosofía: memoria como servicio plug-and-play. Le das tus mensajes, decide qué vale guardar, los almacena en un híbrido (vectores + grafo + key-value) y te los devuelve cuando los necesitas. Tiene tres scopes: usuario, sesión, agente — útil para multi-tenant.
A favor: es lo más fácil de adoptar. La integración con LangChain, OpenAI Assistants y los frameworks populares es directa. Comunidad grande, documentación buena.
En contra: es un SaaS gestionado (también hay versión open source pero menos pulida); cedes control sobre qué se guarda y cómo. Para PyME con datos sensibles, conviene la versión self-hosted.
Letta (antes MemGPT)
Filosofía: el agente edita su propia memoria explícitamente. La memoria está dividida en bloques (core memory, archival memory) y el agente tiene herramientas dedicadas para escribir, editar y archivar. Inspirado en cómo funciona la memoria de un sistema operativo.
A favor: es el patrón con más control. Vos puedes ver y editar la memoria que el agente armó. Excelente para agentes de larga vida (que corren días o semanas).
En contra: requiere que el modelo entienda de "decisiones de memoria", lo cual no todos los modelos hacen bien. La curva de aprendizaje es más alta que Mem0.
Zep (con Graphiti)
Filosofía: memoria como grafo temporal. No solo guarda hechos sino cuándo eran ciertos. Si en marzo "el director de Ventas era Juan" y en mayo "es María", Zep no sobrescribe — sabe que un hecho dejó de ser válido en cierto momento.
A favor: es lo mejor que existe para razonamiento temporal. En el benchmark LongMemEval supera a Mem0 por 15 puntos justamente porque captura validez temporal de los hechos.
En contra: más caro de operar (un grafo + vectores + cómputo de validez temporal). Para casos donde no necesitas temporalidad, es overkill.
MCP (Model Context Protocol)
No es una solución de memoria en sí — es el protocolo que Anthropic abrió en 2024 para que cualquier servidor exponga herramientas a un modelo. Pero rápidamente se volvió la forma estándar de conectar memoria externa a un agente.
Hay decenas de servidores MCP de memoria. Algunos exponen Mem0 vía MCP, otros usan vault de markdown, otros bases vectoriales como Qdrant. La ventaja: el agente no se acopla a una herramienta de memoria específica. Cambiás el servidor MCP y ya está.
Para nuestro stack interno, terminamos armando uno propio: mcp-memory, que combina Qdrant + Ollama (embeddings locales) + un servidor FastMCP y se conecta a Claude Code como cualquier otra herramienta. Es open source y vive en github.com/GermaniU/mcp-memory por si quieres leerlo o forkearlo.
El patrón vault-as-memory: lo que usamos en producción
Llevamos varios meses operando un sistema que llamamos vault-as-memory. La idea es simple y la usan también Hermes Agent (con sus archivos MEMORY.md/USER.md) y Claude Code (con su sistema de auto-memory): toda la memoria del agente vive como archivos markdown legibles.
La estructura concreta nuestra:
vault/
01 - Empresas/
ServerStack/
04 - Arquitectura/Infraestructura.md
05 - Decisiones/2026-04-22 — Migración a Cloudflare Tunnel.md
OrdenaAhora/
...
02 - Personal CEO/
Objetivos 2026.md
Finanzas/...
03 - Recursos/
Aprendizajes/
2026-05-07 — Ollama Cloud no expone embeddings.md
...
Encima del filesystem corren dos cosas:
- Un servidor FastAPI que sirve el vault como grafo (cada nota es un nodo, cada wikilink es una arista). El agente puede pedir "dame las notas conectadas a la decisión X" y recibirlas en formato JSON.
- Un servidor MCP (
mcp-memory) que indexa el vault en Qdrant con embeddings BGE-M3 locales y permite búsqueda semántica. El agente pide "dame las 5 notas más relevantes para 'incidente de RabbitMQ'" y le llegan los chunks correctos.
El agente puede leer y escribir markdown directamente. Cuando se cierra una sesión productiva, el agente actualiza un archivo MEMORY.md con un resumen y crea notas nuevas en 03 - Recursos/Aprendizajes/ si descubrió algo transferible.
¿Por qué este patrón frente a un SaaS de memoria?
| Criterio | Vault-as-memory | SaaS de memoria |
|---|---|---|
| Auditabilidad | Cada hecho es un .md que abres y lees | Caja negra, hay que pedir export |
| Costo | ~0 (filesystem + Qdrant local) | Costo por mes / por usuario |
| Privacidad | Todo en tu máquina o servidor | Depende del proveedor |
| Portabilidad | Markdown puro, sirve para cualquier agente | Lock-in al SDK del proveedor |
| Madurez del SDK | Tienes que armar un poco | Plug-and-play |
Para una PyME donde la memoria es valor central del negocio (decisiones, clientes, proyectos), nos parece imbatible.
El gotcha que descubrimos en el camino: Ollama Cloud no expone embeddings
Una nota práctica que nos costó descubrir y la dejamos acá para ahorrarte las horas:
Si usas Ollama Cloud (la versión gestionada de ollama.com), tienes acceso solo a modelos de chat (kimi-k2, deepseek, gpt-oss). El endpoint de embeddings devuelve 401 Unauthorized aunque tu API key sea válida para chat.
Si tu agente necesita generar embeddings para guardar memoria (que es lo más común), necesitas un Ollama local o autohosteado y un ollama pull bge-m3 (o nomic-embed-text) ahí. Verifícalo con curl antes de armar el stack:
curl -X POST http://localhost:11434/api/embeddings \
-H 'Content-Type: application/json' \
-d '{"model":"bge-m3","prompt":"hola"}'
Si te devuelve un vector de números, vas bien. Si te devuelve 404 o 401, es porque tu Ollama no tiene el modelo o le estás pegando al cloud sin embeddings.
Un detalle más: el dimensionado del modelo de embeddings tiene que coincidir EXACTO con la colección de Qdrant. BGE-M3 son 1024 dimensiones, Nomic son 768. Si tu colección está creada con 768 y le metes vectores de 1024, Qdrant rechaza el insert con error oscuro.
Estos detalles los documentamos también en el repo de mcp-memory por si te ahorran tiempo.
Cómo elegir entre estas opciones
Heurística rápida:
- Quieres algo plug-and-play y tienes presupuesto: Mem0.
- Necesitas razonamiento temporal pesado (compliance, legal, contratos que cambian): Zep.
- Quieres control fino y agentes de muy larga vida: Letta.
- Quieres markdown auditable y barato: vault-as-memory + servidor MCP.
- Tu stack es pura API de Claude o de OpenAI sin agentes complejos: prompt caching + un store externo simple alcanza.
Y si tu agente es una PyME enmascarada de software (operación, tickets, decisiones), nuestra recomendación es ir directo a vault-as-memory. La diferencia entre tener un sistema que tú puedes auditar y uno que es opaco no se nota el primer mes — se nota en el sexto.
Cierre y lo que sigue
La memoria no es un detalle de implementación: es la diferencia entre un agente que es una herramienta y uno que es un compañero. Si lo quieres probar en serio, dale un sistema de memoria desde el día uno. Si no, vas a tener un becario brillante con amnesia anterógrada.
En el siguiente post de la serie comparamos las tres herramientas más serias del mercado de agentes "personales": OpenClaw, Hermes Agent y Claude Code, con experiencia real corriendo OpenClaw en producción. → Ir al post 3.
Si quieres discutir cómo armar memoria persistente para un agente que ya tienes (o uno que quieres tener), escribinos. El stack base es público; el ajuste a tu operación lo hacemos juntos.
Relacionado: Tu vault de Obsidian convertido en memoria viva · RAG en producción: tres bugs reales · Bases de datos vectoriales explicadas.
Preguntas frecuentes
¿Por qué un LLM no puede simplemente "recordar" sin usar herramientas externas?
Porque un LLM en su núcleo es una función pura sin estado: cada llamada es independiente. Lo que se "recuerda" en una conversación es porque la aplicación reenvía la historia previa en cada turno, no porque el modelo guarde nada. Existen experimentos académicos de modelos con "weights aprendiendo en línea", pero a 2026 ningún modelo de producción funciona así. La memoria es siempre un sistema externo.
¿Mem0, Letta y Zep son compatibles entre sí?
No directamente — cada uno tiene su propio SDK y su propio formato de datos. Algunos exponen una capa MCP (Model Context Protocol) que permite mezclarlos, pero migrar de uno a otro requiere exportar la memoria, transformarla y reimportarla. Por eso conviene pensar bien la elección desde el principio o quedarse con el patrón vault-as-memory que es portable a cualquier herramienta.
¿Cuánto cuesta operar memoria persistente para un agente?
Depende del volumen y la opción. Mem0 cloud arranca en planes gratuitos y escala con uso; Zep es similar. Self-hosted con Qdrant + Ollama embeddings locales puede correr en una VPS de 20 USD/mes para volúmenes pequeños y medianos. El costo dominante para volúmenes grandes no es el storage — son las llamadas al modelo de embeddings cada vez que indexas texto nuevo. Por eso usar embeddings locales (BGE-M3, Nomic) abarata radicalmente la operación.
¿La memoria del agente puede tener información sensible? ¿Cómo se protege?
Sí, casi siempre la tiene — preferencias, decisiones internas, información de clientes, claves operativas. Las protecciones son las mismas que para cualquier dato sensible: cifrado en reposo, control de acceso, auditoría de queries, y NO mandarla a un modelo externo si tu compliance no lo permite. Por eso el patrón vault-as-memory con Ollama local para embeddings es popular: ningún dato sensible sale de tu infraestructura. Si usas un modelo cloud para razonar, sólo le mandas los pedazos que el agente decidió que necesita esa llamada.
¿Tiene sentido empezar simple sin memoria persistente y agregarla después?
Sí, y de hecho lo recomendamos. Un agente sin memoria persistente pero con session memory bien armada (todo el contexto de la sesión actual) ya cubre el 70% del valor. Sumar long-term memory tiene sentido cuando el agente atiende a la misma persona o equipo varias veces y empieza a sentirse caro tener que reexplicarle el contexto. La regla: agregá memoria persistente cuando empieces a notar que repites información en sesiones distintas. Antes de eso, es complejidad sin retorno.