¿Qué es la memoria y qué no lo es?
El malentendido más habitual es creer que una ventana de contexto larga es memoria. No lo es. La ventana de contexto es lo que cabe delante del modelo en una ejecución; la memoria es lo que queda entre ejecuciones. Esa diferencia la explica en detalle el post token y context window , con ejemplos.
La división habitual por alcance da dos:
- Memoria a corto plazo: ligada a una única sesión. El hilo de la conversación, conservado con puntos de guardado para poder retomarlo en cualquier momento.
- Memoria a largo plazo: atraviesa sesiones y conversaciones, se organiza en espacios de nombres y es accesible en cualquier momento desde cualquier hilo.
Por tipo, en cambio, son tres:
| Tipo | Qué guarda | Dónde vive normalmente |
|---|---|---|
| Semántica | hechos y conceptos concretos: quién es el usuario, cuál es la empresa, cuál es el proyecto | un único perfil actualizado de continuo o una colección de documentos |
| Episódica | acontecimientos y acciones anteriores: cómo se resolvió una tarea parecida | una colección de ejemplos, un almacén de memoria o un conjunto de datos |
| Procedimental | las reglas según las cuales hay que hacer la tarea | en el system prompt, afinado con reflexión |
Este trío es útil porque cada uno tiene una caducidad correcta distinta. El hecho semántico se queda obsoleto (cambia el puesto, el nombre de la empresa, la preferencia). El recuerdo episódico no se queda obsoleto, sino que deja de ser relevante. Y la regla procedimental vale mientras no cambie el flujo de trabajo ; cuando cambia, hay que sustituirla de golpe, no dejar que se desgaste.
¿Cuándo debe escribir el agent?
Hay dos opciones, y es una decisión de diseño, no un detalle menor:
- Durante la ejecución (en la «vía caliente»): lo que el agent ha aprendido está disponible al instante. A cambio, sube la latencia y el sistema se complica.
- En segundo plano, de forma asíncrona: no hay latencia, pero hay que decidir cuándo y con qué frecuencia corre el paso de resumen.
El compromiso práctico suele ser que la escritura de hechos va por la vía caliente (corta, barata) y el resumen y el ordenado van en segundo plano.
La medición: la memoria es la capacidad más floja de los agents
Aquí hay disponible una fuente independiente insólitamente buena. El ranking de llamada a funciones de un grupo universitario mide la memoria en una categoría aparte y mide tres estrategias de memoria sobre el mismo modelo:
- almacenamiento clave-valor: el agent escribe en casillas etiquetadas y lee de ellas,
- recuperación vectorial: los fragmentos guardados se buscan por significado (de eso trata el post embedding y vector search , a fondo),
- resumen recursivo: el agent reescribe cada cierto tiempo el suyo, más comprimido.
El resultado (situación de abril de 2026, 109 modelos):
| Modelo | Clave-valor | Vectorial | Resumen recursivo | Conjunto |
|---|---|---|---|---|
| El mejor del grupo | 70,97 % | 72,90 % | 77,42 % | 73,76 % |
| El modelo menor de la misma familia | 54,19 % | 57,42 % | 83,23 % | 64,95 % |
| Otra familia puntera, en modo prompt | 59,35 % | 62,58 % | 63,23 % | 61,72 % |
| El mismo modelo, en modo function calling | 50,32 % | 63,23 % | 50,97 % | 54,84 % |
| Un modelo de razonamiento potente | 33,55 % | 50,32 % | 71,61 % | 51,83 % |
| Un modelo grande de pesos abiertos | 21,94 % | 20,00 % | 45,16 % | 29,03 % |
| La media de todo el grupo | 13,9 % | 18,6 % | 28,2 % | — |
(Cálculo propio a partir de la tabla de datos pública del ranking. El ranking se actualiza con regularidad.)
De aquí se leen tres cosas, y las tres salen de la medición:
1. La memoria es un orden de magnitud más floja que las demás capacidades de los agents. Esos mismos modelos que alcanzan el 86–91 % con una sola llamada a función acaban las tareas de memoria entre el 29 % y el 74 %. La media de todo el grupo no llega al 30 % con ninguna de las estrategias.
2. De media gana el resumen recursivo: 28,2 % frente al 18,6 % del vectorial y el 13,9 % del clave-valor. A primera vista sorprende: el resumen pierde información y aun así va mejor. La explicación es que el almacenamiento en bruto no solo conserva la información, sino también el ruido, y el agent tiene que averiguar por su cuenta qué pedir.
3. Pero no hay una arquitectura buena para todos. Mira la cuarta fila de la tabla: el mismo modelo, en dos modos de funcionamiento distintos. En modo function calling gana en él la estrategia vectorial (63,23 %), y por doce puntos por delante del resumen, mientras que en la mayoría del grupo pasa justo lo contrario. La arquitectura de memoria y el modelo no son elecciones independientes. Si cambias de modelo, tu estrategia de memoria hay que volver a medirla.
Esto lo respalda una segunda medición académica: en un benchmark de 500 preguntas diseñado expresamente para memoria a largo plazo, los asistentes comerciales y los modelos de contexto largo mostraron una caída de precisión del 30 % cuando tenían que recordar algo a lo largo de varias sesiones.
Los números de los fabricantes, y lo que valen
Circulan dos series de cifras sobre esto; conviene conocer las dos y poner las dos en su sitio.
Según un proveedor de modelos, la herramienta de memoria y la edición de contexto juntas dieron una mejora del 39 % respecto al caso base, y la edición de contexto por sí sola un 29 %. Y en una tarea de búsqueda de 100 turnos hizo completables flujos de trabajo que si no fracasarían por quedarse sin contexto, con un 84 % menos de tokens. (Evaluación interna, no publicada, sin tamaño de muestra ni metodología.)
Según el estudio de un equipo que desarrolla un producto de memoria, su solución da un 26 % de mejora relativa en una métrica puntuada por un modelo juez, con una latencia un 91 % menor y un ahorro de tokens superior al 90 % frente a pasar el contexto entero. (Los autores trabajan en la empresa que desarrolla el producto medido. La mejora la puntúa un modelo juez, no la corrección objetiva.)
Detrás del 84 % y del 90 % está la misma verdad, y conviene llevársela aunque no te creas las cifras exactas: la memoria es ante todo una herramienta de coste. El agent no se vuelve más listo por recordar, sino más barato y capaz de correr más tiempo, porque no hay que ponérselo todo delante otra vez en cada vuelta.
La memoria como superficie de ataque
Este es el capítulo que se salta la mayoría de las introducciones, y es donde está el mayor riesgo. La memoria, por definición, traslada la confianza de una ejecución a la siguiente: es decir, un único ataque con éxito consigue un efecto duradero.
La medición más importante del tema lo es justamente porque el atacante no tiene acceso a la memoria. Solo puede preguntar y mirar la respuesta. Un estudio de marzo de 2025 examinó exactamente eso: enlaza la pregunta posterior de la víctima con una cadena de razonamiento dañina mediante pasos puente y después va borrando las instrucciones explícitas hasta que solo queda el recuerdo de aspecto inofensivo.
| Agent | Entorno | Éxito de la grabación | Éxito del ataque |
|---|---|---|---|
| Analista de datos sanitarios | base de datos clínica A | 95,6 % | 57,0 % |
| El mismo | base de datos clínica B | 98,5 % | 90,0 % |
| Agent de tienda online | entorno de compra | 96,3 % | 77,4 % |
| El mismo, con un modelo más nuevo | entorno de compra | 99,3 % | 98,9 % |
| Agent de preguntas y respuestas | preguntas de examen | 100,0 % | 68,9 % |
| La media publicada por el estudio | 98,2 % | 76,8 % |
El coste del ataque: de 10 a 15 consultas por pareja víctima-objetivo. Ni un zero day ni una clave filtrada: uso corriente.
Otro estudio, de 2024, midió la puerta trasera escondida en la memoria y en la base de conocimiento sobre tres tipos de agent reales: tasa de éxito del ataque por encima del 80 %, con una tasa de envenenamiento inferior al 0,1 % y menos del 1 % de efecto sobre el funcionamiento normal. Esto último es lo esencial: el agent con la memoria envenenada se porta bien hasta que se cumple la condición que lo dispara.
Tres casos documentados que muestran ese mismo patrón en real:
Febrero de 2025. Un investigador demostró que, mientras resume un documento no fiable, el asistente puede colocar una instrucción condicional: si el usuario dice más adelante una palabra concreta, que guarde algo en la memoria a largo plazo. El modelo cree entonces que está cumpliendo una petición directa del usuario. En el ejemplo de demostración entraron un apodo, una edad falsa y una visión del mundo manifiestamente falsa. La calificación del fabricante: «riesgo de abuso de baja probabilidad y bajo impacto.» El investigador no lo veía así.
Mayo de 2026. Un equipo de seguridad describió un caso en el que un flujo de trabajo de desarrollo corriente —clonar un repositorio, aprobar la instalación de un paquete— llegó hasta la memoria persistente, hasta los ajustes globales, e influyó también en la capa de instrucciones de mayor confianza. Su resumen describe con precisión por qué esto es distinto de una inyección normal: una sola acción ocasional moldeó el comportamiento futuro del modelo a través de sesiones, proyectos e incluso reinicios. La corrección del fabricante es instructiva: sacó los recuerdos del usuario del system prompt, es decir, de la capa de confianza alta.
Julio de 2026. El caso más reciente importa porque ahí la memoria es en sí misma el canal de fuga. El sistema prepara a partir de las conversaciones anteriores un resumen de unos párrafos sobre el usuario y lo mete en cada conversación nueva. El atacante montó una web que ofrecía enlaces organizados por orden alfabético, y el modelo, navegando letra a letra, fue deletreando el dato. Se filtraron el nombre completo, el empleador y la ciudad natal. Esto último el usuario no lo había dicho nunca: el sistema lo dedujo de la mención de un evento local, y al recuerdo entró ya la deducción.
Ese último detalle es el que conviene recordar: en la memoria no está lo que dijiste, sino lo que el modelo dedujo de ello. Y en ese caso la ciudad natal era además la respuesta a una pregunta de seguridad.
La defensa aquí no está dentro de la memoria, sino en el lado de la salida: lo detalla el post el agente con los permisos mínimos , y del lado de la entrada da una panorámica el artículo fundamentos del prompt injection , con casos.
Escribir en la memoria es tratamiento de datos
Mucha gente lo vive como una sorpresa, y sin embargo se desprende directamente del texto de la ley: el reglamento europeo de protección de datos menciona expresamente la conservación dentro del concepto de tratamiento. O sea, que si el agent escribe datos personales en su memoria, eso ya es tratamiento: con base jurídica, finalidad, plazo de conservación y documentación.
Hay cuatro principios que se traducen directamente en decisiones de diseño:
| Principio | Qué dice sobre la memoria |
|---|---|
| Limitación de la finalidad | No se puede guardar «por si acaso sirve para algo». La finalidad de la memoria tiene que estar definida de antemano. |
| Minimización de datos | Solo lo necesario para la finalidad. Esta es la respuesta jurídica a la pregunta de qué guardar. |
| Exactitud | El dato inexacto hay que rectificarlo o suprimirlo sin dilación. O sea, que el recuerdo obsoleto no es solo un problema de calidad, sino jurídico. |
| Limitación del plazo de conservación | En forma identificable solo mientras la finalidad lo justifique. Esta es la respuesta jurídica a la pregunta de qué olvidar. |
A eso se suma la responsabilidad proactiva: el cumplimiento también hay que poder demostrarlo. Así que para la memoria del agent conviene tener una política de conservación escrita, aunque esa memoria no sea más que un archivo JSON.
Y hay un punto que impone un requisito directo a la arquitectura. El derecho de supresión no se detiene en un único registro: el reglamento lo extiende expresamente a las copias y réplicas del dato personal. En un agent eso significa que, cuando llega una solicitud de supresión, hay que saber en qué resumen, en qué índice vectorial y en el contexto de qué ejecución anterior entró el dato.
Esto es técnicamente difícil, y justo por eso conviene escribir la memoria con indicación de origen: de qué conversación, cuándo y con qué base jurídica. Después ya no se puede reconstruir. Dónde se detiene físicamente el dato lo cuenta con más detalle el post el almacenamiento de datos en la UE , país por país.
(El comité europeo de protección de datos publicó en diciembre de 2024 un dictamen sobre los aspectos de protección de datos de los modelos de IA. No he encontrado orientación de las autoridades específica para la memoria de agents: en lo jurídico este terreno sigue abierto.)
¿Qué olvidamos?
Cinco criterios independientes, cada uno con su mecanismo concreto:
1. POR TIEMPO
Borra los archivos de memoria que hace mucho que
nadie LEE. Ojo: por acceso, no por escritura - un
recuerdo viejo pero muy usado es bueno.
2. POR TAMAÑO
Pon un límite máximo al tamaño del archivo y también
a cuántos caracteres devuelve una lectura. Sin límite
la memoria se come la ventana de contexto.
3. POR CONTENIDO
El dato sensible fíltralo ANTES DE ESCRIBIR, en código.
El modelo "suele negarse" - eso no es garantía.
4. POR BASE JURÍDICA
Cuando acaba la finalidad, acaba el dato. El dato
inexacto hay que corregirlo o borrarlo sin demora.
5. POR NIVEL DE CONFIANZA
No subas el contenido de la memoria al nivel del
system prompt. Ahí el modelo lo trata como orden.
El quinto punto es el menos evidente y el error más caro. Si la memoria forma parte del system prompt, con una grabación exitosa el atacante se ha hecho con una instrucción persistente, no solo con un dato persistente. La corrección mencionada antes revertía exactamente eso.
La guía práctica
1. ESCRIBE QUÉ GUARDAS - ANTES DE GUARDARLO
Campo a campo: qué, para qué, hasta cuándo, de dónde.
Sin esto, tu memoria no se puede gobernar.
2. ELIGE ESTRATEGIA, PERO MÍDELA TAMBIÉN
Por defecto, resumen recursivo.
Pero al cambiar de modelo el orden puede alterarse.
3. GUARDA APARTE EL HECHO Y LA INFERENCIA
"Dijo esto" y "de ahí deduje aquello" no tienen
la misma fiabilidad, y tampoco tienen la misma
situación jurídica.
4. ESCRIBE ESTRECHO, LEE ANCHO
Guarda pocas cosas, pero que lo que guardes
se pueda encontrar. Al revés, se te llena el
contexto de ruido.
5. CADUCIDAD EN CADA CAMPO
Sin una vida útil por defecto, la memoria crece
sin parar y los errores viejos nunca se borran.
6. TEN UN BOTÓN "QUÉ SABES DE MÍ"
Que el usuario lo vea y lo pueda borrar. Es a la vez
obligación legal y la mejor depuración que hay.
7. REVISA LA MEMORIA COMO UN REGISTRO
Una vez al mes, lee qué se ha ido acumulando.
El recuerdo envenenado se porta bien - hasta que no.
El sexto punto es además la mejor inversión desde el punto de vista comercial. Cuando el usuario se enfrenta a lo que el sistema guarda de él, llegan dos tipos de reacción: o lo corrige (y a partir de ahí el agent va mejor), o se asusta (y entonces estabas guardando demasiado). Las dos son información útil.
Malentendidos habituales
- «La ventana de contexto larga sustituye a la memoria.» No. La ventana de contexto dura dentro de una ejecución; la memoria, entre ejecuciones. Y el contexto largo también empeora por sí solo: de eso trae mediciones el post subagents y trabajo en paralelo , con tablas.
- «Con memoria el agent es más listo.» Sobre todo es más barato y capaz de correr más tiempo. Las cifras más potentes sobre mejora de precisión vienen de fabricantes o de fuentes interesadas.
- «Guardemos todo, ya filtraremos.» Según la medición, el almacenamiento en bruto es la estrategia más floja, y según la ley no puedes guardar datos innecesarios. Este es el caso raro en el que los dos criterios apuntan en la misma dirección.
- «El modelo no va a sacar datos sensibles.» La formulación prudente de la documentación es que «suele negarse». Para una garantía fuerte hay que filtrar desde el código, antes de escribir.
- «A la memoria solo la puede atacar quien tiene acceso.» Según la medición se alcanza un 98,2 % de éxito de grabación solo con consultas, en quince preguntas.
- «Si borro el registro, está borrado.» El registro entró también en resúmenes, en índices vectoriales y en las trazas de ejecuciones anteriores. Para borrarlo hay que saber adónde fue.
Lo que conviene llevarse
La memoria es la parte menos resuelta de los agents. Los números lo muestran sin ambigüedad: la media del grupo no llega al 30 % con ninguna estrategia, y en cada modelo gana una arquitectura distinta, o sea que aquí no hay receta probada, solo medición.
La consecuencia práctica no es «no uses memoria», sino trata la memoria como una base de datos, no como una función de comodidad. Tiene esquema, tiene plazo de conservación, tiene control de acceso, y de vez en cuando hay que repasar qué ha entrado en ella.
Y la comprobación más barata que puedes hacer hoy: lee qué guarda de ti el asistente que usas a diario. Es muy probable que haya dentro alguna deducción que nunca dijiste en voz alta, y muy probable que haya algo que ya no es cierto.
Por qué la fiabilidad empeora con el número de pasos lo cuenta el post la matemática de la fiabilidad , con cálculos; y de cómo montar el contexto a conciencia se ocupa el artículo context engineering al detalle.