Memoria y contexto en agentes de IA: qué recuerda un agente y qué no

Un agente de IA no recuerda como una persona. Recuerda lo que le pongas delante en cada momento y lo que hayas decidido guardar a propósito. Todo lo demás se olvida en cuanto termina el paso. Confundir esas dos cosas —lo que el modelo tiene a la vista ahora y lo que la operación conserva entre casos— es el origen de la mitad de los sustos con agentes: sistemas que “olvidan” lo que se les dijo hace diez minutos, o que “recuerdan” un dato personal que debería haberse borrado.

Para quien evalúa poner un agente a trabajar, esto no es un tecnicismo. Qué recuerda un agente y qué no es una decisión de diseño con consecuencias de negocio y de riesgo. Vale la pena entender las dos memorias por separado antes de decidir qué debe conservar tu operación.

Las dos memorias que hay que distinguir

La ventana de contexto es lo que el modelo tiene delante mientras trabaja: la instrucción, los datos del caso, los documentos que le has pasado, los pasos que lleva dados en esta misma tarea. Es memoria de trabajo, y es finita. Tiene un límite de tamaño, y cuando la conversación o el caso se alargan, lo primero deja de caber. El modelo no “sabe” que ha olvidado. Simplemente responde con lo que aún tiene a la vista. Cuando la tarea termina, esa ventana se descarta. Por defecto, el agente empieza el siguiente caso en blanco.

La memoria persistente es lo que decides guardar fuera de esa ventana para recuperarlo más tarde: el estado de un caso abierto, las preferencias de un cliente, una regla que se fijó, el historial de lo que ya se hizo. No es algo que el modelo tenga por naturaleza. Es una capa que se construye alrededor de él —una base de datos, un almacén, un índice— y de la que se traen los fragmentos oportunos a la ventana de contexto cuando hacen falta.

La distinción práctica: la ventana de contexto es memoria de trabajo, limitada y efímera; la memoria persistente es memoria de archivo, deliberada y gobernada. Un agente serio usa las dos, y la pregunta de diseño es qué va en cada una.

	Ventana de contexto	Memoria persistente
Qué es	Lo que el modelo tiene a la vista ahora	Lo que se guarda fuera para recuperarlo después
Duración	Se descarta al terminar la tarea	Persiste entre casos y sesiones
Límite	Finita: no cabe todo	La que decidas, con su coste de gobierno
Riesgo típico	”Olvida” lo importante al llenarse	”Recuerda” lo que no debía conservar

Traer información de un corpus de documentos a esa ventana para responder es un patrón vecino pero distinto —eso es RAG empresarial—: RAG recupera de un archivo estable de documentos. La memoria conserva lo que el agente vive caso a caso. Se confunden porque ambos “meten datos en el contexto”, pero uno consulta un manual y el otro recuerda su propia historia.

Cómo se diseña qué debe recordar una operación

Aquí es donde el trabajo deja de ser técnico y pasa a ser de negocio. “Que recuerde todo” es la respuesta perezosa y la equivocada. Una memoria que lo guarda todo se llena de ruido, encarece cada consulta y acumula datos que después hay que justificar. La disciplina es decidir, para cada proceso, qué merece conservarse. En mis despliegues distingo tres tipos.

El estado del caso. Un proceso que dura más de un paso necesita saber por dónde va: qué se ha pedido, qué se ha resuelto, qué queda pendiente, a qué se está esperando. Sin esto el agente no puede retomar un caso a medias, y cualquier operación real está llena de casos a medias. Es la memoria más obvia y la que más se descuida.

Las reglas. Las políticas, límites y criterios que gobiernan cómo se decide no cambian caso a caso, pero tienen que estar disponibles en cada uno. Esto no es tanto “memoria” en el sentido de historia como la definición explícita de la operación, y es una de las razones por las que insisto en tratar el modelo operativo como código, porque las reglas que un agente aplica deberían estar escritas y versionadas, no dispersas en la cabeza de quien las conocía.

El historial. Lo que ya pasó con este cliente, este proveedor, este expediente. Es lo más útil y lo más delicado a la vez: útil porque da continuidad, delicado porque acumula datos —a menudo personales— cuya retención hay que justificar y limitar.

La regla que aplico es sencilla de enunciar y difícil de sostener. Se conserva lo que una operación bien hecha necesitaría recordar para dar continuidad y rendir cuentas, y no más. Todo lo que se guarda “por si acaso” es coste y riesgo esperando a materializarse. Cómo se ensambla esta capa con el resto —modelo, orquestación, conexiones— lo desarrollo en la arquitectura de agentes de IA, y cómo un agente alcanza los sistemas donde vive parte de ese estado, en el Model Context Protocol (MCP).

Los riesgos: memoria envenenada y datos retenidos

La memoria persistente introduce dos riesgos que la ventana de contexto efímera no tiene, y ninguno se gobierna solo.

Memoria envenenada. Si un agente guarda como cierto algo que era falso —un dato erróneo, una instrucción colada en un documento que procesó, una conclusión mal sacada—, ese error deja de ser un fallo aislado y se convierte en una premisa que arrastra en cada caso siguiente. Peor aún, como viene de su propia memoria, el sistema lo trata con más confianza que a una entrada nueva. Una memoria sin validación es un canal por el que un error, o un ataque deliberado, se hace permanente. Por eso lo que entra en la memoria persistente merece el mismo escrutinio que una acción del agente sobre un sistema: es parte de la superficie de seguridad, un asunto que trato en gobernanza de agentes.

Datos personales retenidos. Una memoria que acumula historia acumula, casi siempre, datos personales: nombres, correos, lo que dijo un cliente, el contenido de una gestión. Eso cae de lleno bajo las obligaciones de protección de datos: base legal para conservarlo, límite de tiempo, derecho de la persona a que se borre, control de quién accede. Una memoria de agente montada sin pensar en esto es un problema de cumplimiento esperando una auditoría. Lo desarrollo en protección de datos con IA. Aquí basta con fijar el principio: la retención es una decisión que se justifica, no un efecto secundario que se tolera.

Memoria bien pensada, operación que aguanta

Junto todo en una idea que repito en cada comité: la memoria de un agente no es una función que venga de fábrica y se active, es una decisión de diseño que tomas tú sobre tu operación. Qué recuerda define si el agente da continuidad o repite preguntas, qué olvida define si arrastra errores o parte limpio, y qué retiene define tu exposición legal. Diseñarla bien es parte del trabajo específico de codificar tu operación en agentes que funcionen, el mismo que describo en el pilar sobre agentes de IA para empresas. Un agente con buena memoria no es el que más guarda, sino el que guarda exactamente lo que su trabajo exige y puede rendir cuentas de ello.

Preguntas frecuentes

¿Cuál es la diferencia entre ventana de contexto y memoria en un agente?

La ventana de contexto es lo que el modelo tiene a la vista mientras resuelve una tarea: instrucción, datos del caso, pasos dados. Es finita y se descarta al terminar. La memoria persistente es lo que decides guardar fuera de esa ventana —estado del caso, reglas, historial— para recuperarlo en casos futuros. Una es memoria de trabajo; la otra, de archivo.

¿Un agente de IA recuerda las conversaciones anteriores?

Solo si se ha diseñado para hacerlo. Por defecto, el agente empieza cada tarea sin memoria de las anteriores. Recordar entre sesiones requiere construir una capa de memoria persistente que guarde lo relevante y lo traiga de vuelta cuando corresponda. No es un comportamiento automático del modelo, sino algo que se decide y se monta.

¿Qué es la memoria envenenada?

Es cuando un agente guarda como cierto algo falso —un dato erróneo, una instrucción maliciosa colada en un documento, una conclusión mal sacada— y ese error contamina todos los casos siguientes, porque el sistema confía en su propia memoria. Se previene validando qué entra en la memoria y tratando esa entrada como parte de la superficie de seguridad.

¿La memoria de un agente afecta a la protección de datos?

Sí, y bastante. Una memoria que conserva historial suele acumular datos personales, y eso obliga a tener base legal para conservarlos, un límite de tiempo, control de acceso y capacidad de borrarlos si la persona lo pide. La retención tiene que ser una decisión justificada, no un subproducto de “guardarlo todo por si acaso”.