🧠 El mapa de la memoria de agentes en 2026: 8 soluciones, sus tradeoffs y cuándo conviene cada una

❝

Nota personal. Ayer la cabeza estaba en NVIDIA y los anuncios de Taipei. Hoy volvemos a memoria como prometí. Esta es la segunda parte de la serie — si no leíste el diagnóstico del lunes (5 patrones + checklist), conviene empezar por ahí: este post asume que ya manejas la diferencia entre memoria de trabajo y persistente, y la regla de "RAM vs. disco duro".

Hoy hacemos el mapa del territorio. Las soluciones que existen, qué resuelve cada una bien, dónde fallan, cuándo conviene apostar a cada una y cuándo no. Sin recomendaciones genéricas — con tradeoffs honestos.

La pregunta correcta antes de elegir framework

Antes de evaluar cualquier solución, define qué tipo de memoria necesita tu agente. La distinción que importa para builders:

  • Personalización: ¿el agente necesita recordar preferencias estables del usuario entre sesiones? (Ej. asistente personal, soporte recurrente.)

  • Razonamiento temporal: ¿necesita saber qué cambió, cuándo y por qué? (Ej. CRM con historia, agente de compliance que rastrea decisiones.)

  • Coherencia episódica: ¿necesita recordar "ayer probamos X y no funcionó" para no repetirlo? (Ej. agente autónomo de larga duración, copiloto de investigación.)

  • Recuperación documental: ¿necesita citar documentos específicos en la respuesta? (Ej. RAG enterprise, búsqueda interna.)

La trampa más común es asumir que cualquier framework hace bien las cuatro cosas. Ninguno lo hace. Cada uno está optimizado para una o dos.

Las 8 soluciones del mapa

Organizadas en tres categorías según dónde vive la memoria.

Categoría 1: Frameworks dedicados de memoria (open source + cloud-managed)

1. Mem0

Qué es: Capa de memoria con extracción automática de preferencias del usuario, recuperación semántica via vector store. 48.000+ stars en GitHub. Disponible como open source auto hospedado o como servicio managed.

Fortalezas:

  • Mejor para personalización: recordar preferencias estables del usuario.

  • Mejor opción si quieres servicio managed sin construir el storage.

  • Benchmark reciente: +26% de precisión vs. baselines en LongMemEval.

  • Recuperación rápida de "fuzzy" facts (cosas como "le gustan las luces a 2700K").

Debilidades:

  • Débil en razonamiento temporal (no es su modelo de datos).

  • La extracción automática a veces interpreta "hoy quiero X" como preferencia estable cuando no lo es.

  • Tier managed: lock-in vs. tu propia infra.

Cuándo apostar a Mem0: asistente personal, chatbot con usuarios recurrentes, agentes de soporte que necesitan conocer al cliente.

2. Letta (ex MemGPT)

Qué es: Runtime de agente stateful con memoria jerárquica integrada al estilo OS (paginación de contexto). Es heredero directo del paper MemGPT (Packer et al., 2023).

Fortalezas:

  • Mejor en coherencia episódica: el agente "recuerda" lo que probó y falló en sesiones anteriores.

  • Memoria de muy largo plazo con auto-gestión.

  • Recuperación más semánticamente apropiada que Mem0, aunque más lenta por consulta.

Debilidades:

  • Más lento por recuperación (latencia adicional vs. Mem0).

  • Curva de aprendizaje más empinada — la arquitectura de paginación es nueva para muchos equipos.

  • Menos opinión sobre extracción automática que Mem0.

Cuándo apostar a Letta: agentes autónomos de larga duración, copilotos de investigación, casos donde la "memoria de proyecto" importa.

3. Zep / Graphiti

Qué es: Núcleo de knowledge graph temporal (basado en Neo4j). Modela memoria como hechos con timestamps explícitos.

Fortalezas:

  • Mejor en razonamiento temporal: "¿quién cambió esto y cuándo?".

  • Excelente para Enterprise 360 (vista unificada de cliente/asset con historia).

  • Knowledge graph permite queries complejas que vector stores no pueden.

Debilidades:

  • Requiere Neo4j en tu stack (otro componente que mantener).

  • Curva de aprendizaje grande para equipos sin experiencia en graph databases.

  • Más caro de operar que Mem0.

Cuándo apostar a Zep: CRM con IA, compliance/audit trails, casos donde el "cuándo" y el "quién" importan tanto como el "qué".

Categoría 2: Memoria nativa del framework de orquestación

4. LangGraph + LangMem

Qué es: Memoria integrada al runtime de LangGraph. Separación limpia entre memoria de hilo (thread-scoped, resumible) y memoria de largo plazo (store-scoped, query-able cross-threads).

Fortalezas:

  • Si ya usas LangGraph para orquestar tu agente, esto es lo más natural.

  • Patrón checkpointer maneja resumibilidad automáticamente.

  • LangMem provee primitivas funcionales independientes del storage.

Debilidades:

  • Lock-in fuerte con el ecosistema LangChain.

  • Las clases clásicas de LangChain memory están deprecated en 2026: BufferMemory, ConversationBufferMemory, ConversationSummaryBufferMemory y VectorStoreRetrieverMemory ya no son soportadas. Si tu codebase legacy las usa, tienes que migrar. (Esto es importante — si lo viste en un tutorial viejo, está desactualizado.)

  • No tan optimizado para personalización profunda como Mem0.

Cuándo apostar a LangGraph + LangMem: ya usas LangGraph y quieres que la memoria sea parte del grafo de ejecución, no un sistema separado.

Categoría 3: Memoria nativa del LLM provider (la categoría que cambió todo en 2026)

5. Anthropic Memory Tool + Dreaming

Qué es: Memoria expuesta como filesystem montado en /mnt/memory/ dentro del container del agente. Acompañado por el Dreaming primitive (lanzado el 6 de mayo de 2026), que corre asíncronamente entre sesiones — revisa transcripts, extrae patrones, fusiona duplicados y surface nuevos insights. Modelado explícitamente sobre consolidación hipocampal de memoria humana.

Fortalezas:

  • Si tu stack es Claude-native, esto es plug-and-play.

  • Dreaming resuelve el patrón #4 del lunes (Session-Close Extraction) automáticamente.

  • Filesystem como interfaz es familiar para developers.

Debilidades:

  • Lock-in con Anthropic (no portable a OpenAI o Google).

  • Sin features de razonamiento temporal nativo (Zep gana ahí).

  • Dreaming asíncrono es magia útil, pero también caja negra — no controlas exactamente qué se extrae ni cuándo.

Cuándo apostar: stack 100% Anthropic, equipo pequeño que valora simplicidad por encima de portabilidad.

6. OpenAI file_search (Responses API)

Qué es: Tool de recuperación basado en vector store, expuesto en la Responses API. No es "memoria" estrictamente — es retrieval sobre archivos que tu agente puede subir y consultar.

Fortalezas:

  • Si tu stack es OpenAI-native, integración inmediata.

  • Buena para recuperación documental.

  • Costos predictibles.

Debilidades:

  • No es memoria en el sentido cognitivo — es retrieval. Sin extracción de preferencias, sin razonamiento temporal.

  • Lock-in con OpenAI.

  • Para los otros tres tipos de memoria (personalización, episódica, temporal), necesitas complementar con otro sistema.

Cuándo apostar: ya tienes Responses API integrada y tu caso de uso es retrieval documental, no memoria cognitiva.

7. Google Memory Bank (Gemini Enterprise Agent Platform)

Qué es: Primitiva de base de datos identity-scoped en la plataforma Gemini Enterprise. La identidad del usuario (Google Workspace) es la clave primaria de memoria.

Fortalezas:

  • Si tu org corre sobre Google Workspace, integración nativa con identity.

  • Cumple por defecto con políticas de data residency de Google Cloud.

  • Útil para compliance enterprise.

Debilidades:

  • Lock-in con Google Cloud + Workspace.

  • Menos flexible que Mem0 o Letta para arquitecturas custom.

  • Identity-scoped significa que multi-agent / multi-tenant es más complicado.

Cuándo apostar: enterprise sobre Google Workspace, casos donde la identity Google es el contexto principal.

Categoría 4: Custom (Redis + pgvector)

8. Stack propio

Qué es: Tú construyes la arquitectura. Típicamente: Redis para memoria de trabajo de sesión, pgvector (Postgres + pgvector extension) para memoria persistente con búsqueda semántica.

Fortalezas:

  • Control total: sin lock-in, sin dependencias externas.

  • Compliance regulatorio fuerte (autohospedaje, residencia de datos garantizada).

  • Costo más bajo a escala si tu equipo sabe operar Redis y Postgres bien.

Debilidades:

  • Tienes que diseñar los 5 patrones del lunes desde cero.

  • Mantenimiento operacional 100% tuyo.

  • No hay extracción automática, observabilidad, ni dreaming — todo eso lo construyes.

Cuándo apostar: casos regulados con autohospedaje no negociable, equipos con expertise operacional fuerte, presupuesto bajo y volumen alto.

📊 La matriz comparativa

Solución

Tipo de memoria fuerte

Hosting

Lock-in

Curva

Cuándo

Mem0

Personalización

Self-hosted u OSS + managed

Bajo (OSS) / Alto (cloud)

Baja

Asistentes personales, soporte recurrente

Letta

Coherencia episódica

Self-hosted u OSS

Bajo

Media

Agentes autónomos de larga duración

Zep

Razonamiento temporal

Self-hosted u OSS + managed

Medio (requiere Neo4j)

Alta

CRM, compliance, audit trails

LangGraph + LangMem

Integración a workflow

Self-hosted u OSS

Alto (LangChain)

Media

Ya usas LangGraph

Anthropic Memory + Dreaming

Provider-native + async consolidation

Anthropic-managed

Total

Baja

Stack 100% Claude

OpenAI file_search

Retrieval documental

OpenAI-managed

Total

Baja

Stack 100% OpenAI, caso de retrieval

Google Memory Bank

Identity-scoped enterprise

Google Cloud

Total

Media

Enterprise sobre Workspace

Custom (Redis + pgvector)

Lo que diseñes

Self-hosted

Cero

Alta

Casos regulados, expertise operacional

🌳 Árbol de decisión rápido

Si necesitas decidir esta semana, aquí están las preguntas en orden:

  1. ¿Tu compliance exige autohospedaje? Sí → Custom (Redis + pgvector) o Mem0/Letta self-hosted. No → sigue.

  2. ¿Ya usas LangGraph? Sí → LangGraph + LangMem (default natural). No → sigue.

  3. ¿Tu stack es 100% Claude / 100% OpenAI / 100% Gemini? Sí → primitive nativa del provider (Anthropic Memory, file_search, Memory Bank). No → sigue.

  4. ¿Cuál es la dimensión dominante?

    • Personalización → Mem0

    • Razonamiento temporal → Zep

    • Coherencia episódica → Letta

    • Las tres juntas → custom + Mem0 + Zep en capas (advertencia: caro)

⚠️ Alerta importante para equipos LATAM con código legacy

Si tu codebase usa LangChain memory classes clásicas (BufferMemory, ConversationBufferMemory, ConversationSummaryBufferMemory, VectorStoreRetrieverMemory), están deprecated en 2026. El patrón soportado es ahora LangGraph checkpointer (short_term + long_term).

Si te aparece esto en un tutorial reciente sin marcar la migración, está desactualizado.

Migración mínima: mover la lógica de memoria a LangGraph con InMemoryStore (dev) o PostgresStore (producción). Es ~1 día de trabajo para una codebase pequeña. Si llevas mucho tiempo sin tocar esto, es buen momento para reconsiderar si LangChain sigue siendo la decisión correcta o si vale moverte a Mem0/Letta directo.

🌎 Tradeoffs específicos para builders LATAM

Tres consideraciones que pesan más para nosotros que para equipos US/EU:

1. Costo a escala

Mem0 y Letta autohospedados son baratos a volumen bajo y crecen con tu uso. Las primitivas del provider (Anthropic, OpenAI, Google) cobran por uso de memoria — predictible al inicio, costoso a escala. Para early-stage LATAM, autohospedaje gana.

2. Residencia de datos y soberanía

LGPD (Brasil), la nueva ley mexicana de IA, las leyes argentinas de protección de datos personales y la regulación de Colombia. Las primitivas managed de US (Anthropic, OpenAI, Google) corren memoria en US por default. Si tu cliente exige residencia local, necesitas autohospedaje — Mem0/Letta self-hosted, o custom.

3. Multi-tenancy

La mayoría del SaaS LATAM exitoso es B2B multi-tenant. Aislamiento de memoria por tenant es requisito de compliance, no opcional. Mem0 y Letta soportan aislamiento out-of-the-box. Las primitivas managed (Anthropic, Google Memory Bank) soportan por user/identity pero no por tenant arbitrario — si tu modelo es "una empresa cliente compra mi SaaS y dentro tiene 100 usuarios", necesitas pensarlo.

💡 Tip del día

Pregunta accionable para tu equipo HOY:

Mira tu stack actual. Pregúntate qué framework de memoria estás usando (si es ninguno, esa es la respuesta) y compáralo con el árbol de decisión de arriba.

Tres escenarios típicos:

  • "Estamos sobre LangChain con BufferMemory." → Migración obligada. Empieza por LangGraph checkpointer y evalúa si vale moverte a Mem0/Letta.

  • "No tenemos memoria, todo va en el system prompt." → Caso 1 del lunes (te lo advertí). Esta semana es buen momento para empezar con Mem0 (la curva más baja) y validar si necesitas más.

  • "Usamos OpenAI file_search." → Confirma que tu caso es retrieval documental, no memoria cognitiva. Si necesitas que el agente recuerde preferencias del usuario entre sesiones, file_search no lo resuelve y vas a necesitar complementar.

Mañana profundizamos en el ángulo más sensible: memoria para casos regulados (LGPD, ley mexicana de IA, audit trails). Cómo lo está pensando Enter, qué hace WideLabs, y por qué custom Redis+pgvector sigue siendo defendible en este contexto.

📚 Lecturas obligatorias para profundizar

Hablamos mañana con el deep dive sobre memoria en casos regulados.

Keep Reading

© 2026 BitNeuronal.
Report abusePrivacy policyTerms of use
beehiivPowered by beehiiv