¿Cuánta memoria deberías darle a un agente de IA? Lo que descubrió un estudio de 8 modelos (2026)

"Memoria" aquí significa directrices destiladas, no transcripciones

Esto es lo primero que hay que aclarar, porque la palabra abarca varias cosas diferentes. Los autores son explícitos: "'Memoria' aquí no significa reproducir una transcripción pasada. Significa un conjunto de directrices (estrategias que funcionaron, errores a evitar y casos límite) destiladas de las propias trayectorias previas del agente".

El ciclo es: el agente intenta tareas y produce trayectorias; el sistema extrae directrices de comportamiento "tanto de sus ejecuciones exitosas como de las fallidas"; las consolida en un conjunto reutilizable; y en el momento de la inferencia, el agente recibe el conjunto completo o una selección de este. Fundamentalmente, "No se actualizan los pesos del modelo". Lo que cambia es "la guía disponible para el agente", no el modelo.

Por lo tanto, este no es un estudio sobre el historial de conversaciones, ni sobre ventanas de contexto grandes, una distinción que vale la pena mantener separada de por qué una ventana de contexto grande no es memoria.

El benchmark y las dos métricas

La evaluación se realizó en AppWorld: "585 tareas de múltiples pasos (168 test_normal + 417 test_challenge) a través de 9 aplicaciones simuladas (calendarios, mensajería, pagos, etc.)".

Dos puntuaciones, y la brecha entre ellas resulta ser la parte interesante:

TGC — Task Goal Completion (Finalización de Objetivos de Tareas). "La proporción de tareas individuales que el agente completa de manera total y correcta". La cifra principal de "funcionó o no".

SGC — Scenario Goal Completion (Finalización de Objetivos de Escenarios). "Una métrica más estricta, de todo o nada". Cada escenario agrupa varias variantes de la misma tarea, y "el SGC cuenta un escenario como aprobado solo si el agente tiene éxito en cada variante. Mide la confiabilidad".

Las tres configuraciones

Ambas configuraciones de memoria se basan en el mismo conjunto de directrices, "extraído una vez... solo de la partición de entrenamiento de AppWorld", y los autores señalan que "ningún dato de la partición de prueba se utiliza para construirlo". Lo que difiere es la entrega:

Baseline (Línea base) — "Sin memoria: el agente tal como se distribuye".

Full guideline set (Conjunto completo de directrices) — "Cada directriz extraída, inyectada en cada paso de ReAct".

Curated retrieval (Recuperación curada) — "Un núcleo fijo y de alta confianza de esas mismas directrices más algunas relevantes para la tarea recuperadas para cada tarea (una parte fija + una parte variable)".

Tres cosas destacan.

Los modelos fuertes lo absorbieron todo. Los modelos con margen de mejora obtuvieron mejores resultados con el conjunto completo de directrices, "incluidas las lecciones de casos límite poco comunes", porque "tienen la capacidad de absorber y aplicar todo ello".

Los modelos más débiles se vieron perjudicados por el volumen. "Los modelos más pequeños o débiles se ven abrumados por un conjunto grande de directrices". Para gpt-oss-120b, el conjunto completo "obtuvo menos ganancias y costó aproximadamente un 50% más de tokens" que la recuperación curada.

La métrica estricta se movió más que la principal. DeepSeek ganó +9.5 TGC pero +16.1 SGC, porque "las buenas directrices ayudan especialmente a un agente a resolver cada variante de un escenario, no solo el caso promedio". Incluso los modelos cerca de su límite siguieron ganando en confiabilidad: GPT-5.5 y Opus sumaron +7.2 y +7.1 pp de SGC. La formulación de los autores es la que hay que recordar: "La memoria sigue dando frutos mientras el modelo tenga un modo de fallo restante al que dirigirse".

Y un modelo no mostró nada. GLM-5 obtuvo una puntuación idéntica con y sin memoria en estas tareas. Lo que esto significa es el punto donde los autores son más cautelosos, y se analiza a continuación.

La objeción refleja a inyectar directrices en cada paso es el costo, y es una objeción justa. Sus mediciones:

Así que para el modelo más débil, la selección ganó en ambos ejes a la vez: "+16.1 pp de TGC con solo un +5% de tokens". Como dicen los autores, "Un mejor rendimiento aquí no requiere un mayor costo de inferencia".

Dos hallazgos de apoyo son importantes para cualquiera que presupueste esto. Primero, la sobrecarga es inflación de entrada en lugar de más trabajo: "DeepSeek ejecuta aproximadamente el mismo número de pasos de ReAct con memoria que sin ella (≈18–19 en promedio), por lo que el costo adicional es inflación de tokens de entrada, no trayectorias más largas". Segundo, hay una palanca estándar para ello: "La verdadera palanca de eficiencia en producción es el almacenamiento en caché de prompts (prompt caching): la parte estática del conjunto de directrices es idéntica en todos los pasos y se puede almacenar en caché, lo que reduce sustancialmente el costo real". Recomiendan diseñar pensando en esto: "mantener estable el prefijo compartido del conjunto de directrices para que siga siendo almacenable en caché".

Este último punto tiene una implicación de diseño directa. Una capa de memoria que reorganiza su salida en cada llamada anula el almacenamiento en caché. Una con un núcleo estable y una pequeña cola variable es más barata de ejecutar, y también es la configuración que ganó en precisión para el modelo más débil.

Los autores son inusualmente disciplinados con sus propios límites, y citarlos adecuadamente es la forma honesta de interpretar el resultado.

"Saturado" describe una observación, no una causa. Sobre el resultado plano de GLM-5: "Llamamos a esto el patrón saturado; la etiqueta describe lo que observamos, no una causa probada. Es posible que el modelo ya estuviera cerca de su límite en estas tareas, que las directrices no abordaran sus fallos restantes o que no haya aplicado la guía de manera efectiva". Eso no es un hallazgo sobre la calidad del modelo. Es un benchmark, un conjunto de directrices, una configuración.

El nivel de capacidad no es el recuento de parámetros. "Lo que coloca a un modelo en un patrón en lugar de otro no es simplemente el recuento de parámetros. El margen de mejora en el benchmark, el tamaño de la ventana de contexto, la arquitectura, la calidad de las directrices y la distribución de las tareas parecen influir en dónde aterriza un modelo, y separar esos factores es un trabajo en curso". Ten en cuenta que GLM-5 con 745B y DeepSeek con 671B terminaron en patrones diferentes.

La explicación de la ventana de contexto es una hipótesis. Piensan que las ventanas más grandes pueden absorber mejor los conjuntos completos, y dicen directamente: "Aún no hemos realizado experimentos controlados que aíslen este factor".

Es un solo benchmark. "Estos resultados están validados en AppWorld: un benchmark riguroso de múltiples pasos, pero solo uno". Se indica que benchmarks más amplios y despliegues reales están en progreso.

La recuperación en sí es, por admisión propia, imperfecta. "Nuestra recuperación actual clasifica las directrices por similitud de coseno, lo que hemos demostrado que no predice perfectamente qué directrices ayudan a una tarea determinada". Se menciona un selector aprendido como el siguiente paso, lo que significa que las cifras de recuperación curada se lograron a pesar de un método de selección rudimentario.

Los modelos muy débiles están fuera del alcance. "Por debajo de una línea base de capacidad mínima, la autodestilación carece de señal".

Leído en conjunto: la dirección del hallazgo está bien respaldada, y los números específicos pertenecen a este benchmark y a este método. No cites los porcentajes como lo que hará tu sistema.

Tratar el almacenamiento como todo el problema. La mayoría de las configuraciones de memoria se optimizan para capturar más. Este estudio dice que la captura es la mitad fácil; lo que se inyecta, por tarea, es donde residen tanto la precisión como el costo.

Inyectar todo porque el contexto ahora es barato. Barato no es gratis, aquí fue de +51% a +78%, y para el modelo más débil, más contexto empeoró los resultados.

Asumir que un modelo más grande necesita menos ayuda. Los modelos cerca de su límite aún ganaron significativamente en la métrica de confiabilidad. La precisión principal lo ocultó; la métrica estricta no.

Juzgar la memoria por el éxito en el caso promedio. El TGC subestimó el beneficio en todo momento. Si tu agente "suele tener razón", lo que la memoria corrige puede ser la variante en la que falla, que es exactamente lo que mide el SGC.

Concluir que la memoria no funciona cuando un modelo no muestra ganancias. Los autores rechazan explícitamente extraer esa conclusión de sus propios datos.

La traducción práctica de este estudio no es "almacenar menos". Es que una capa de memoria tiene que ser capaz de seleccionar, mantener un núcleo estable y ser depurable, porque la dosis es una decisión que tomas por modelo y por tarea, no una sola vez en la configuración.

Divide tu memoria en un núcleo y una cola. Un conjunto pequeño y de alta confianza que siempre se inyecta, más entradas relevantes para la tarea recuperadas por tarea. Esa es la configuración que ganó tanto en precisión como en costo para el modelo más débil, y es la que sigue siendo almacenable en caché.

Mantén el núcleo estable para que funcione el almacenamiento en caché de prompts. Si la parte siempre activa es idéntica byte por byte en todos los pasos, obtienes el descuento. Reordenarla silenciosamente descarta esa ventaja.

Prueba ambas dosis en tu propio modelo. Conjunto completo frente a núcleo más recuperación, medido en tus tareas. La propia conclusión del estudio es que la respuesta difiere según el modelo.

Mide la métrica estricta. No solo cuentes las tareas completadas; cuenta con qué frecuencia se aprueba cada variante de la misma tarea. Ahí es donde aparecieron estas ganancias.

Depura, ya que la calidad de las directrices se menciona como un factor. Las entradas incorrectas o desactualizadas no son neutras: se inyectan junto con las buenas.

Hacer eso requiere una memoria que viva en un lugar que puedas inspeccionar y editar, en lugar de acumularse dentro de un solo asistente. Eso es lo que es MemoryLake: una capa de memoria de la que tus agentes leen a través de MCP o una API, donde las entradas son individuales y editables en lugar de un bloque opaco en constante crecimiento, lo que hace que calibrar la dosis sea posible. La configuración consta de tres pasos.

Paso 1: Crea una clave de API

Inicia sesión en MemoryLake y crea una clave de API. Una sola credencial para todas las herramientas que conectes.

Paso 2: Sube tus primeras memorias

Escribe las entradas de la misma forma en que se estructuran los conjuntos de directrices del estudio: una afirmación cada una, de comportamiento siempre que sea posible (qué funcionó, qué evitar y el caso límite que arruinó un intento anterior). Las categorías que se ganan su lugar:

Correcciones que has hecho más de una vez. Estas son tus entradas principales de mayor confianza, por definición.

Modos de fallo y cómo evitarlos. Las ganancias del estudio provinieron en gran medida de resolver la variante que solía fallar.

Restricciones que parecen arbitrarias. Límites de velocidad, requisitos de orden, la API que se comporta de manera diferente a la documentada.

Lo que ya se ha descartado. La categoría que ningún artefacto contiene y la que cada nuevo agente vuelve a proponer.

Paso 3: Conecta tu IA y tus agentes

Conecta las herramientas que utilizas. MemoryLake es accesible a través de MCP y de una API, por lo que los agentes nativos de MCP (entre ellos Claude Code, Codex y OpenClaw) se conectan apuntando al servidor MCP, mientras que otros asistentes leen la misma memoria a través de la API.

Tres límites honestos. MemoryLake no formó parte de este estudio, y ninguno de los porcentajes anteriores son afirmaciones sobre él; los resultados pertenecen al propio método de los autores en su propio benchmark. Almacena lo que tú o tus agentes escriben en él, por lo que la calidad depende de tu entrada. Y no cambia la capacidad de un modelo; si los fallos restantes de tu agente no son del tipo que la guía corrige, una mejor memoria tampoco los solucionará.

"Más contexto" deja de ser la solución predeterminada. Para un modelo más débil, más contexto lo empeoró. La selección es la palanca.

La confiabilidad se convierte en la métrica a vigilar. La medida estricta de todas las variantes se movió más que la precisión principal en todos los niveles, incluidos los modelos cerca de su límite.

El costo deja de ser el argumento en contra de la memoria. +5% de tokens para +16.1 pp en un modelo, y almacenamiento en caché de prompts en un núcleo estable para el resto.

Los cambios de modelo se convierten en recalibraciones. Cambia de modelo y la dosis correcta puede cambiar con él, ya que el nivel de capacidad no se puede predecir a partir del tamaño.

La depuración se convierte en una actividad de rendimiento. La calidad de las directrices se enumera entre los factores que deciden en qué patrón aterriza un modelo, lo que hace que eliminar entradas desactualizadas sea un trabajo real, no solo de limpieza. El aspecto de los tokens se aborda en reducción del uso de tokens con una capa de memoria.

Comienza con un núcleo pequeño y de alta confianza. Amplíalo solo cuando puedas demostrar que la adición ayuda.

Recupera por tarea para todo lo demás. Unas pocas entradas relevantes superan al conjunto completo para modelos sin margen de mejora.

Mantén el prefijo siempre activo estable a nivel de bytes. La capacidad de almacenamiento en caché es la diferencia entre lo asequible y lo que no lo es.

Ejecuta la prueba A/B en tus propias tareas. Completo frente a curado, en tu carga de trabajo. El hallazgo principal del estudio es precisamente que la respuesta no es universal.

Evalúa con todo o nada, no con el promedio. La confiabilidad es donde la guía da resultados.

Pon fecha y elimina. Las entradas desactualizadas también se inyectan.

No interpretes un resultado plano como prueba de que la memoria es inútil. Los autores mencionaron tres posibles explicaciones para su único caso sin ganancias y no se comprometieron con ninguna.

Mantén la memoria fuera del modelo. No se actualizaron pesos en este estudio; por eso el enfoque fue "barato de adoptar y portátil a través de los ocho modelos que probamos". La portabilidad es una propiedad de mantenerla externa, el caso general en lo que significa la memoria persistente.

El hallazgo que vale la pena recordar es el que los autores colocaron en el encabezado de una sección: "La memoria debe calibrarse, no simplemente acumularse". Los modelos fuertes con margen de mejora utilizaron el conjunto completo de directrices autodestiladas. Los modelos más débiles obtuvieron mejores resultados con un núcleo compacto más recuperación por tarea, y lo hicieron con un +5% de tokens en lugar de un +51%. Un modelo no mostró cambios medibles, y los autores se negaron deliberadamente a explicar por qué a partir de un solo benchmark.

Para tus propios agentes, eso se traduce en tres hábitos: separar un núcleo estable siempre activo de una cola recuperada, medir la confiabilidad en lugar del éxito promedio y tratar la depuración como parte del rendimiento. Y mantén la memoria en un lugar inspeccionable y editable, porque "cuánto" es un dial que girarás cada vez que cambies de modelo, no un interruptor que activas una sola vez.