Memoria de agentes 2.0: Titans, MemOS, y el gap de continuidad cross-sesión que nadie cerró todavía

Cuatro semanas desde nuestro post de Graphiti / Mem0 y la capa de memoria del stack agéntico se movió más que cualquier otra en la misma ventana. Titans, la arquitectura de memoria neural de Google, escaló más allá de 7B parámetros con resultados que silenciosamente desplazaron a los Transformers de contexto largo en los benchmarks de horizonte más largo. MemOS — el "sistema operativo para memoria LLM" — publicó benchmarks peer-reviewed que le ganan a cada baseline previo por 60-160% en LongMemEval. Letta (antes MemGPT) cruzó los 50.000 deployments en producción. Y el gap arquitectónico que marcamos en la síntesis del stack — continuidad de memoria cross-sesión a nivel protocolo — sigue abierto. Este post es el update para operadores actualmente en Graphiti, Mem0, Letta o un stack custom, intentando decidir si rotar.

Dónde estábamos hace un mes — recap rápido

El post original de memoria argumentó que dos enfoques grado-producción dominaban el espacio open-source a principios de 2026. Graphiti, el knowledge graph bi-temporal de Zep que registra hechos más el tiempo en que se volvieron verdaderos y el tiempo en que fueron aprendidos, soportando tanto consultas point-in-time ("qué sabía el agente el 14 de marzo") como tracking de consistencia. Mem0, el enfoque más simple que extrae memorias de conversaciones crudas hacia un vector store con edges opcionales de relación, rankeando memorias por frescura y relevancia al momento del retrieval.

Ambos enfoques resolvían el mismo problema de superficie — meter contexto previo útil en la memoria de trabajo del agente en el momento correcto — y ambos lo hacían lo suficientemente bien como para que el gap entre "sin capa de memoria" y "Graphiti o Mem0" fuera el salto de calidad más grande individual que un operador podía hacer. La pregunta que dejamos abierta: ¿cómo se ve la próxima capa arquitectónica, y está lo suficientemente cerca de producción como para que un operador apueste por ella?

Cuatro semanas después la respuesta es más concreta de lo que esperábamos.

Titans — memoria neural que aprende en test time

Titans fue publicado por primera vez por Google Research a fines de 2024 y ha estado escalando silenciosamente a lo largo de 2025 y principios de 2026. La arquitectura resuelve un problema distinto al de Graphiti o Mem0: en lugar de almacenar memorias externamente y recuperarlas con búsqueda vectorial, Titans le da al modelo un módulo de memoria neural que aprende a memorizar durante la inferencia. El módulo de memoria es en sí mismo una pequeña red neuronal cuyos parámetros se actualizan en test time basándose en qué tan sorprendente es cada nuevo token, y cuyos outputs están condicionados por un estado de memoria de larga duración.

La arquitectura define tres variantes de integración:

Patrones de integración de memoria en Titans:

  Memoria como Contexto (MAC)
    El módulo de memoria produce una secuencia de tokens "memory hint"
    que se prepende al contexto de atención. La atención ve tanto la
    ventana de contexto corto como el resumen de memoria.

  Memoria como Gate (MAG)
    El output del módulo de memoria controla por gate el output
    estándar de atención — memoria y atención contribuyen
    conjuntamente vía un gate aprendido.

  Memoria como Capa (MAL)
    El módulo de memoria es una capa en el stack — composición
    secuencial en lugar de paralela con la atención.

Los números de benchmark que importan para los operadores están del lado del horizonte largo. BABILong, el benchmark para razonamiento estilo aguja-en-pajar a través de distancias de millones de tokens, es donde la variante MAC de Titans claramente le ganó tanto a Transformers de contexto largo (clase Gemini 1.5 Flash) como a los modelos state-space líderes (variantes de Mamba-2). El gap se amplía en las distancias más largas — pasada la marca de 4M tokens, Titans MAC mantiene 80%+ de exactitud donde los baselines de Transformer caen a la moneda al aire.

Qué significa esto para los operadores en la práctica. Titans no es (todavía) algo que dropeas en tu stack de agentes. Es un cambio a nivel arquitectura del modelo que tiene que lanzarse dentro de un modelo fundacional. La expectativa es que la familia Gemini 3.5 sea el primer modelo comercial en lanzar memoria estilo Titans como capacidad core, con un anuncio probable en Q3-Q4 2026. Los operadores no adoptan Titans; adoptan el modelo que tiene Titans.

La implicación: el impuesto de contexto largo que ha sido la realidad operacional de la memoria de agentes durante dos años — el pico de costo de contextos por encima de 200K tokens, la degradación de DELEGATE-52 — tiene una respuesta arquitectónica real llegando en los próximos dos trimestres. El camino interino sigue siendo memoria externa (Graphiti, Mem0, MemOS) encima de modelos frontera estándar.

MemOS — el sistema operativo de memoria

Si Titans es la respuesta a nivel modelo fundacional, MemOS es la respuesta a nivel aplicación. Publicado en abril de 2026 por un consorcio de investigación que abarca varias universidades chinas y estadounidenses, MemOS replantea la memoria del agente como un problema de sistema operativo: tres tipos distintos de memoria con diferentes costos de durabilidad y acceso, agendados y migrados a través de los tipos por un gestor de memoria que decide qué promover, demover, expulsar o re-materializar.

Arquitectura de memoria de tres tiers de MemOS:

  Memoria plaintext
    Hechos en lenguaje natural, historial de conversación, docs
    estructurados. Barata de almacenar, cara de usar (debe ser
    recuperada + leída en el contexto para cada invocación
    relevante).

  Memoria de activación (KV cache)
    Estados key-value cacheados de invocaciones previas del modelo.
    Costo medio de almacenamiento, muy barata de usar (sin
    re-encoding). Con pérdida: la activación solo representa lo
    que el modelo "pensó" en el momento de la escritura.

  Memoria de parámetros
    Conocimiento codificado como deltas de parámetros del modelo
    (adapters estilo LoRA). Cara de escribir (requiere update
    con forma de fine-tune), muy barata de usar (sin retrieval,
    sin inflado de contexto). Permanente en el sentido de que el
    modelo "sabe" el hecho.

La contribución de MemOS es el scheduler. Los operadores no eligen un tier de memoria por hecho; el scheduler lo hace. Un hecho nuevo llega como plaintext, es promovido a activación si se usa frecuentemente dentro de una sesión, es promovido a memoria de parámetros si es reforzado a través de muchas sesiones o etiquetado como conocimiento core por el operador. Las expulsiones y demociones funcionan al revés. El resultado es un sistema de memoria donde el conocimiento más usado vive en el tier más barato de acceder sin intervención del operador.

Los números de benchmark son sorprendentes. En LongMemEval — el benchmark estándar de memoria de horizonte largo — MemOS reportó mejoras del 60-160% sobre el baseline previo más fuerte (que era la memoria built-in de OpenAI al momento de la publicación). La ganancia vino casi enteramente del tier de memoria de parámetros: una vez que el conocimiento había sido promovido al espacio de parámetros del modelo, el recall era efectivamente gratis y persistía a través de ventanas de contexto que rompían los baselines de solo-plaintext.

Qué significa esto para los operadores en la práctica. MemOS está más cerca de ser deployable que Titans. La implementación de referencia es open source, y varias startups (la más activa es un proyecto afiliado a Letta llamado Persistent) la están envolviendo en SDKs operator-friendly. La ecuación de costo no es trivial: las actualizaciones de memoria de parámetros cuestan dinero real (estás corriendo updates con forma de fine-tune por agente) pero el costo de inferencia por consulta cae sustancialmente porque tanto el retrieval como el inflado de contexto bajan. Para un agente sirviendo al mismo cliente por muchas sesiones, la amortización de la memoria de parámetros es favorable; para un agente high-churn de un solo disparo, solo-plaintext sigue siendo la elección correcta.

El gap de continuidad cross-sesión que nadie cerró

Marcamos este gap en el post de síntesis del stack y el campo no lo cerró en el mes desde entonces. La forma del problema: un agente que hace gran trabajo para una contraparte en la sesión N no tiene forma estandarizada y a nivel protocolo de traer ese aprendizaje hacia adelante a la sesión N+1. El estado de memoria del agente es opaco a otros agentes, a otras plataformas, a los propios sistemas de la contraparte.

Los workarounds a nivel operador son reales pero parciales. Mem0 y Graphiti ambos lanzan formatos de export; un operador puede dumpear el estado de memoria de un cliente y re-importarlo en otro lado, pero ningún otro sistema efectivamente consume el formato de forma nativa. Los deltas de memoria de parámetros de MemOS son adapters LoRA, que son teóricamente portables pero prácticamente atados al modelo base específico sobre el que fueron entrenados. La memoria estructurada de Letta tiene forma JSON y se lee limpiamente pero no interopera con agentes no-Letta.

Lo que falta a nivel protocolo: una primitiva de memoria portable que un agente pueda entregar, que otro agente (u otra plataforma) pueda consumir, que la contraparte pueda auditar, y que la disciplina criptográfica del resto del stack (Mandates firmados, validation receipts, identidad atestiguada) pueda aplicarse. Ninguna de las cinco capas del protocolo cubre esto; los working groups de MCP, A2A y AP2 no la están scopeando activamente; la dirección de investigación más cercana es la exploración de "knowledge credentials" de la comunidad W3C Verifiable Credentials, que todavía es pre-producción.

Nuestra predicción: el gap va a ser cerrado por una extensión A2A v1.x o v2 definiendo una primitiva estructurada de handoff de memoria, en algún punto a mediados o fines de 2027. Hasta entonces, los operadores lanzan los patrones workaround y aceptan el costo de lock-in del sistema de memoria que elijan.

El patrón de binding con ERC-8004

Mientras espera la solución a nivel protocolo completo, un patrón práctico emergió que ata la memoria del agente a la capa de identidad on-chain. El patrón: cada update significativo al estado de memoria de un agente genera un hash de contenido; el hash se postea como parte de la entrada del agente en la Validation Registry de ERC-8004; la reputación del agente incluye un "score de consistencia de memoria" derivado de qué tan seguido sus hashes de memoria divergen de las trayectorias declaradas.

Patrón de binding de estado de memoria:

  1. El agente procesa un hecho nuevo / recibe feedback / cierra una task
  2. La capa de memoria computa un hash estilo Merkle sobre los
     updates relevantes
  3. Hash + metadata mínima posteado a la Validation Registry de
     ERC-8004 bajo el token de identidad del agente
  4. La contraparte verifica que el estado de memoria declarado del
     agente coincida con el estado atestiguado on-chain
  5. El score de reputación incorpora la señal de consistencia a
     través de muchas de estas attestations

El binding no transporta la memoria misma a través de sistemas — el contenido se queda en el store privado del agente. Transporta la prueba de que el comportamiento del agente es consistente con el estado de memoria que reclama tener. Una contraparte contratando al agente por primera vez puede leer el score de consistencia on-chain sin nunca ver la memoria cruda; un agente que silenciosamente resetea su memoria entre sesiones tiene un rastro de hashes que expone el reset.

Corremos este patrón en Agent Builder desde mediados de mayo de 2026 para cada agente con binding ERC-8004 habilitado. El costo por attestation es ~$0.10 en una L2 clase Base; la tasa es por sesión (no por hecho), así que el overhead está acotado. El beneficio es que "la memoria de este agente fue consistente a través de 200 sesiones" se vuelve una señal consultable que las contrapartes pueden usar sin confiar en el operador o en la plataforma.

Qué debería hacer el operador hoy

Guía práctica para los cuatro puntos de partida más comunes.

Si estás en Graphiti. Quédate. El modelo bi-temporal de Graphiti sigue siendo el fit más fuerte para cargas donde "qué sabía el agente en el tiempo T" importa — workflows legales, de auditoría, compliance, investigación. El trabajo de MemOS no lo reemplaza; lo complementa para el tier de memoria de parámetros. Espera una integración Graphiti + MemOS de Zep en Q3 2026.

Si estás en Mem0. Quédate hasta Q3 2026. El enfoque de Mem0 (extracción + vector store + relaciones) es operacionalmente el más liviano y el equipo ha estado agregando silenciosamente hooks de memoria de parámetros. El scheduler estilo MemOS es más difícil de retrofittear a la arquitectura de Mem0 que a la de Letta, así que esperamos que Mem0 evolucione más incrementalmente. El gap entre Mem0 y MemOS se va a ampliar para cargas memory-heavy a lo largo del fin de año; si tienes diez o más sesiones por cliente, evalúa la migración.

Si estás en Letta (antes MemGPT). Estás bien posicionado. La arquitectura de memoria estructurada de Letta mapea limpiamente a los tres tiers de MemOS, y el equipo de Letta ha sido el más público sobre adoptar el scheduling estilo MemOS. La migración de Letta v0.x a Letta v1.0 (esperado Q3 2026) es el momento para revisar; se supone que v1.0 lanza con soporte MemOS nativo.

Si tienes un stack custom. La evaluación honesta: probablemente estás sub-invertido en esta capa. Los sistemas de memoria custom que funcionaban en 2025 están empezando a quedarse atrás del estado del arte open-source de una forma que compone semana a semana. El camino de migración: elige uno entre Graphiti, Mem0, o Letta basándote en la forma de la carga (audit / extracción liviana / memoria estructurada), migra a lo largo de un trimestre, planifica una segunda migración a un stack MemOS-aware en 2027. Tener la capa de memoria end-to-end es un impuesto que casi ningún operador debería pagar más.

Qué vigilar a lo largo del Q4 2026

Tres cosas concretas en el horizonte que van a afectar cómo los operadores piensan sobre memoria.

Gemini 3.5 con memoria clase Titans. Anuncio esperado Q3-Q4 2026. Si lanza como anunciado, el costo de las cargas de contexto largo baja materialmente y los operadores actualmente usando memoria externa primariamente como workaround de contexto largo pueden simplificar. Los operadores usando memoria externa como almacenamiento de conocimiento estructurado (el caso de uso de Graphiti / Mem0) no van a ver cambio significativo.

Wrappers comerciales de MemOS. Persistent, el proyecto afiliado a Letta, más dos startups en stealth mode, están corriendo a ser el primer MemOS-as-a-service grado producción. El primero que lance con tooling creíble para operadores (integración con suite de eval, detección de drift sobre memoria de parámetros, audit trails) gana share desproporcionado de mercado. Vigila el anuncio en Q3.

Primitiva de handoff de memoria en A2A v1.x o v2. El working group de la Linux Foundation que corre A2A no comprometió este scope todavía pero reconoció el gap. Nuestra lectura: hay aproximadamente una probabilidad de 50/50 de un draft de propuesta para fin de 2026. Si aterriza, la capa de memoria se vuelve legítimamente portable por primera vez y el costo de lock-in del operador baja a casi cero.

La forma arquitectónica que producirán los próximos dieciocho meses

Si estamos en lo correcto sobre la memoria clase Titans lanzando en los modelos fundacionales, el scheduling clase MemOS lanzando en las plataformas de memoria grado operador, y la portabilidad clase A2A lanzando a nivel protocolo, la capa de memoria de agentes a fines de 2027 luce materialmente distinta a la de hoy. La memoria de trabajo vive en el módulo de memoria neural del modelo (gratis, rápida, sin retrieval). La memoria episódica vive en tiers gestionados por MemOS (auto-agendada a través de plaintext / activación / parámetros). La continuidad cross-sesión es una primitiva de protocolo de primera clase (portable, verificable, anclada). El trabajo del operador en ese punto es configuración y supervisión; la arquitectura subyacente es problema de otra persona.

Para los próximos dieciocho meses, el trabajo del operador es más difícil. Elige la capa de memoria que se ajuste a tu carga, acepta el costo de migración que vas a pagar una vez que el polvo se asiente, y atá el estado de memoria a attestations de ERC-8004 ahora para que cualquier cosa que pase a nivel protocolo, el track record de tu agente sea durable. La inversión en infraestructura de attestation compone aunque el sistema de memoria subyacente cambie debajo.

Cierre

La memoria era la capa de menor movimiento del stack a principios de 2025 y es la de mayor movimiento a principios de junio de 2026. La forma de los próximos dieciocho meses es lo suficientemente legible como para planear alrededor de ella: memoria clase Titans en los modelos, scheduling clase MemOS en el tooling, handoff portable de memoria a nivel protocolo. La forma de las próximas cuatro semanas no — esperamos que al menos un paper más que cambie arquitectura aterrice antes de nuestro próximo post de memoria, y el campo a esta velocidad probablemente nos va a sorprender.

Para el operador decidiendo hoy, la respuesta práctica es quedarse en el stack grado producción que tienes (Graphiti, Mem0, Letta) y empezar a atar el estado de memoria a attestations de ERC-8004. El beneficio del binding compone sin importar qué arquitectura gane; el costo del binding es trivialmente chico. La apuesta contra el campo es ser dueño de un stack de memoria custom desde cero; la apuesta con el campo es consumir el estado del arte open-source y correr las preocupaciones a nivel plataforma (eval, observabilidad, attestation) encima de él.

El próximo post de esta serie se mueve de memoria a la vista forward más amplia: el forecast de doce meses para el stack agéntico — qué protocolos van a lanzar v1.0, qué startups se van a consolidar, qué vectores de ataque van a emerger, y qué categorías de operadores van a componer más rápido. Nos vemos allá.