Memora organiza la memoria de los agentes sin confundir recordar con cargarlo todo

Microsoft Research presentó Memora el 29 de junio de 2026 para resolver una tensión que aparece cuando un agente acumula meses de conversaciones: guardar cada detalle produce un archivo ruidoso, pero resumirlo todo puede borrar la excepción que decide una tarea. El anuncio original de los investigadores propone separar el contenido que se conserva de las señales usadas para encontrarlo. No es memoria dentro del modelo ni una ventana de contexto infinita; es un sistema externo de construcción, almacenamiento y recuperación.

La distinción cambia la pregunta práctica. Un agente no “recuerda” porque una frase exista en una base de datos. Recuerda solo si guardó la versión correcta, recuperó la evidencia pertinente y la utilizó sin deformarla. Memora aporta una arquitectura y resultados en dos bancos de pruebas, no una garantía universal. La capacidad que deja este trabajo es aprender a evaluar cualquier memoria de agente como una cadena de cuatro fallos posibles: escritura, actualización, recuperación y lectura.

El problema no es solo cuánto cabe

Enviar todo el historial al modelo parece el punto de comparación más sencillo. Funciona mientras el registro es pequeño, pero la entrada crece en coste y puede llenarse de información irrelevante. Recuperar fragmentos por similitud semántica reduce volumen, aunque una pregunta puede no usar las mismas palabras que la decisión que necesita. Resumir comprime aún más, pero una síntesis demasiado gruesa puede perder fechas, restricciones, negaciones o cambios.

El paper de Memora publicado en ICML 2026 formula esa disyuntiva como tensión entre especificidad y abstracción. Guardar conversaciones o hechos atómicos conserva detalle, pero fragmenta el relato; acumular resúmenes organiza el historial, pero sacrifica matices. La propuesta intenta usar la abstracción como índice y mantener aparte el contenido concreto.

Esto obliga a abandonar una metáfora engañosa. La memoria de un agente no se parece a la memoria humana ni a una verdad estable. Se parece más a un sistema de información que transforma entradas, mantiene versiones y responde consultas. Cada transformación puede introducir un error. Si una preferencia antigua ya no vale, recuperarla con gran precisión sigue siendo un fallo.

Tres piezas: valor, abstracción y pistas

Cada entrada de Memora contiene un valor de memoria con la información rica y una abstracción primaria que resume de qué trata. El valor conserva el detalle y no se usa directamente como texto indexado. La abstracción primaria funciona como identidad canónica: cuando llega información relacionada, el sistema puede consolidarla bajo el mismo asunto en vez de crear una colección de duplicados inconexos.

El ejemplo de Microsoft agrupa una cronología de proyecto bajo una frase estable. Si cambian prototipo, piloto y entrega, las actualizaciones pueden permanecer en una entrada coherente. Eso ayuda a reconstruir la evolución, pero introduce una decisión crítica: el proceso que crea la abstracción debe reconocer que dos mensajes pertenecen al mismo concepto. Si los separa por error, aparece fragmentación; si fusiona asuntos distintos, aparece contaminación.

La tercera pieza son los cue anchors, pistas breves extraídas del valor. Ofrecen varias rutas hacia la misma memoria: una persona, un hito, una fecha o una restricción pueden llevar a la cronología común. El repositorio oficial, publicado con licencia MIT, explica que solo las abstracciones y estas pistas se indexan, mientras el valor conserva el contenido. La idea no consiste en imponer una ontología fija de entidades y relaciones, sino en generar accesos contextuales.

Hay un beneficio y un riesgo simétricos. Más pistas pueden mejorar la cobertura cuando la pregunta no coincide literalmente con el recuerdo. También pueden crear rutas espurias si una pista está mal extraída. Por eso la evaluación debe medir no solo si apareció una respuesta correcta, sino qué entrada la sustentó, qué pista abrió el camino y qué recuerdos relevantes quedaron fuera.

Recuperar puede ser una secuencia de decisiones

Una búsqueda vectorial típica devuelve los elementos más próximos a una consulta. Memora añade una política que puede reformular la pregunta, expandir la búsqueda a través de pistas relacionadas y decidir cuándo detenerse. El objetivo es alcanzar dependencias de varios saltos que una única comparación semántica no encuentra.

El paper prueba una política guiada por prompts y otra entrenada con GRPO. El repositorio también incluye búsqueda semántica y una variante híbrida con coincidencia léxica. No son la misma intervención ni tienen el mismo coste: la política con un modelo puede realizar varias llamadas; la búsqueda semántica es más directa; la política entrenada necesita datos y cómputo. Comparar “Memora” sin fijar el recuperador oculta una variable principal.

La configuración experimental utiliza GPT-4.1-mini para construir memoria, generar respuestas y dirigir la recuperación basada en prompt. Eso ayuda a reproducir el resultado, pero también significa que la cifra mide un sistema completo con un modelo concreto. Cambiar extractor, lector, embeddings, presupuesto de contexto o número de pasos puede cambiar calidad, latencia y coste.

Qué demostraron LoCoMo y LongMemEval

Los autores informan un 86,3 % en la métrica principal de LoCoMo para la recuperación por política y un 84,9 % para la variante semántica; el contexto completo obtiene 82,5 % en su configuración. En LongMemEval, Memora alcanza un 87,4 %. También declaran una reducción de hasta el 98 % de tokens frente a introducir el historial completo. “Hasta” señala el mejor caso comparado, no un ahorro asegurado para cada conversación.

Para interpretar esos números hay que abrir los bancos de pruebas. LoCoMo reúne conversaciones largas creadas con una combinación de generación automática y revisión humana, y pregunta por hechos, relaciones temporales y razonamiento. LongMemEval contiene 500 preguntas que cubren extracción, razonamiento entre sesiones, tiempo, actualizaciones y abstención, con historiales extensibles de conversaciones simuladas y editadas.

Son pruebas relevantes para memoria conversacional, pero no cubren por sí solas un agente que modifica archivos, opera herramientas o comparte conocimiento entre equipos. Tampoco convierten la puntuación en una tasa de acierto sobre cualquier empresa. El propio paper usa un juez basado en LLM como métrica principal y añade BLEU y F1 como complementos. Una puntuación de juez automática depende de la rúbrica y del modelo evaluador; conviene acompañarla de inspección humana y trazas de evidencia.

Hay más cautelas de comparación. Algunos resultados de sistemas rivales se toman de trabajos anteriores en vez de ejecutarse todos bajo un único arnés, según detalla la sección experimental. Y “contexto completo” es una base concreta con el mismo lector, no una prueba de que toda estrategia de contexto largo sea inferior. El resultado válido es estrecho: en esas configuraciones, organizar y recuperar el historial superó a los baselines reportados.

La prueba que importa en un producto

Una evaluación útil empieza con un registro de cambios, no solo con preguntas de recuerdo. Debe incluir hechos que siguen vigentes, hechos corregidos, preferencias revocadas, negaciones, datos casi duplicados y elementos que el sistema nunca vio. Así se miden cinco capacidades separadas: guardar, consolidar, actualizar, recuperar y abstenerse.

Después conviene puntuar evidencia además de respuesta. Para cada consulta, el evaluador puede comprobar si la entrada correcta apareció entre las primeras recuperadas, si la respuesta cita esa entrada, si mezcla una versión antigua y cuánto contexto consumió. Una respuesta casualmente correcta con evidencia equivocada es una deuda: fallará cuando la pregunta cambie.

Coste y latencia deben medirse de extremo a extremo. Memora puede reducir los tokens que recibe el lector, pero construir abstracciones, generar pistas y explorar varias rutas también consume recursos. La métrica honesta suma escritura, mantenimiento, recuperación y generación por tarea resuelta. También separa el tiempo en línea, que espera el usuario, del trabajo asíncrono.

En información sensible hace falta otra columna: permisos y borrado. Una memoria puede recuperar bien y aun así exponer una nota a la persona equivocada. El artículo y el paper apuntan a futuros trabajos sobre procedencia y límites de acceso, pero los resultados publicados se concentran en calidad y eficiencia de memoria. Un despliegue debe probar aislamiento por usuario, eliminación, auditoría y restauración después de una actualización incorrecta.

Cómo leer el siguiente récord de memoria

Antes de aceptar que un sistema “recuerda mejor”, hay que anotar seis datos: qué se guarda; qué transformación lo resume; qué se indexa; qué recuperador y lector intervienen; qué conjunto y métrica producen la cifra; y qué coste total incluye. En Memora, la respuesta es concreta: valores ricos, abstracciones primarias, pistas múltiples, varias políticas de recuperación, GPT-4.1-mini en los experimentos y dos benchmarks conversacionales.

Esa ficha permite reconocer el avance sin inflarlo. Memora muestra que cargar todo no es el único techo y que una estructura ligera puede conservar rutas hacia detalles. El código abierto permite inspeccionar y repetir la propuesta. Pero una memoria eficiente no se vuelve fiable por definición: sigue necesitando evidencia, gestión de versiones, abstención, permisos y pruebas con la distribución real.

La pregunta duradera no es “¿cuántos tokens ahorra?”. Es “¿en qué etapa perdería, mezclaría o recuperaría mal un hecho, y cómo lo detectaría?”. Un equipo capaz de responderla puede comparar Memora con el próximo sistema aunque cambien los nombres y los porcentajes.