Tu agente "recuerda" todo durante una conversación y olvida todo al reiniciar. Esa frase, que suena obvia, esconde el error conceptual que más sistemas agénticos hunde en producción: confundir el contexto (la RAM volátil de un turno) con la memoria (el estado durable que sobrevive a la compactación, al reset de sesión y a la rotación de ventana). Este módulo los separa. Trata el momento en que un dato no confiable se convierte en "memoria del agente" como una frontera de seguridad. Y te pide modelar el hecho más incómodo de la memoria real: que un dato verdadero ayer puede ser confiadamente falso hoy.
El modelo mental: el agente como par (θ, C)
El insight que reordena todo el diseño es formalizar al agente como un par (θ, C): θ son los pesos del modelo (lo que se fija al entrenar) y C es el contexto/memoria (lo que se actualiza en runtime). En 2025–2026 el aprendizaje continuo de un agente ocurre en el espacio de tokens: actualizas C, no θ. El agente mejora reescribiendo archivos y memorias legibles, no ajustando gradientes. Eso es enorme. El conocimiento del agente se vuelve interpretable, versionable, portable entre modelos y, como verás, atacable.
Una analogía de cocina, mía, no citada. Lo que un cocinero tiene en la encimera mientras emplata es el contexto: cabe poco, se limpia entre servicios, y un pedido nuevo lo barre. El recetario, la pizarra de alérgenos de cada habitual, la nota de "este proveedor falló en marzo" son la memoria: viven fuera de la encimera, persisten entre turnos y se consultan cuando hacen falta. Reentrenar el modelo sería mandar al cocinero a la escuela de cocina. Actualizar la memoria es escribir una línea nueva en la pizarra. En producción, el 99% del aprendizaje útil es lo segundo.
La taxonomía de Tulving aplicada: qué persistir y con qué política
El marco canónico para razonar qué persistir es CoALA, que adapta la taxonomía de Tulving y organiza la memoria del agente en cuatro tipos (working, episodic, semantic, procedural) y separa acciones internas (sobre la memoria) de externas (sobre el mundo). No es decoración cognitiva. Cada tipo exige una política distinta de escritura, retrieval, decay y validación de seguridad.
| Tipo | Qué guarda | Política de escritura/decay | Riesgo dominante |
|---|---|---|---|
| Working | El turno actual (lo que está en la ventana) | Volátil; se rota/compacta | Pérdida por compactación agresiva |
| Episodic | Eventos y trayectorias pasadas | Append con timestamp; decay por relevancia | Tratar una observación como verdad permanente |
| Semantic | Hechos del mundo/usuario | Versionado temporal, NO overwrite | Staleness ("confiadamente incorrecto") |
| Procedural | Skills / cómo-hacer | Validar el loop de refinamiento | El más peligroso de envenenar: se amplifica cada sesión |
El error de raíz es confundir tipos: tratar una observación episódica ("el usuario dijo hoy que prefiere las mañanas") como un hecho semántico permanente produce tanto staleness como el envenenamiento de precedentes falsos. La memoria procedural es la peor de todas para envenenar: un procedimiento malicioso sintetizado de una sola trayectoria se reinyecta, amplificado, en cada sesión futura, y casi nadie valida ese loop de refinamiento de skills.
La memoria vive fuera de la encimera: jerarquía tipo OS
MemGPT introdujo la metáfora sobre la que se apoyan casi todos los frameworks posteriores: tratar la ventana de contexto como RAM y un store externo como disco, con niveles core/recall/archival, y, lo que importa, con el agente mismo invocando funciones para paginar información entre niveles. El insight no es la jerarquía. Es que la gestión de memoria es tool-use que decide el modelo, no un pipeline pasivo de pre-carga. Eso es lo que habilita horizonte largo sin reentrenar.
Aprendizaje continuo en token-space, sin reentrenar
La palanca de mejora más infravalorada: un agente mejora acumulando experiencia textual. Reflexion lo demostró sin gradientes: el agente almacena auto-reflexiones verbales de sus fallos y las recupera en reintentos, mejorando su desempeño. Esto es aprendizaje continuo real: interpretable (lees la memoria), versionable (la diffeas), portable (la mueves entre modelos) y operacionalmente más seguro que tocar pesos. De nuevo, esto actualiza C, no θ. Aquí no hay fine-tuning.
Por qué el linaje de autoría importa aquí
Reflexion y CoALA comparten autores de Princeton (Narasimhan y Yao). No es casualidad: la memoria episódica útil de Reflexion es exactamente el tipo "episodic" que CoALA formaliza. El aprendizaje continuo en token-space no es una técnica aislada, es la operacionalización de la taxonomía.
El write-path es la verdadera frontera de confianza
Aquí está la tesis de seguridad del módulo. El momento más peligroso de toda la arquitectura es cuando contenido no confiable (un doc de la org, un mensaje de usuario) se convierte en memoria confiable: colapsa la atribución de origen y desde ahí se relee como conocimiento del propio agente. El estudio sistemático identifica una taxonomía de seis clases de poisoning y cuatro canales de escritura: C1 instrucción explícita, C2 política de system prompt, C3 compactación, C4 síntesis de experiencia a procedimiento. Cada canal es una superficie de ataque distinta. Defender solo el input no cubre bien ninguna.
Y la memoria es una superficie persistente, no de un turno. MINJA demuestra una tasa de inyección exitosa >95% (y ~70%+ de éxito de ataque end-to-end) envenenando la memoria de un agente solo con queries benignas, sin acceso privilegiado; la memoria envenenada dispara acciones maliciosas cuando otra víctima la recupera más tarde. Una inyección de un turno se convierte en una puerta trasera multisesión. Esto es lo que acopla la memoria a la seguridad: una memoria envenenada es estrictamente peor que una inyección normal porque sobrevive al turno que la plantó.
La defensa central es provenance / source-aware memory: etiquetar cada entrada con su origen y un nivel de confianza, y poner en cuarentena o degradar en el retrieval lo que viene de fuentes no confiables. La política de escritura también pesa: una política estrecha reduce el éxito de ataque casi a la mitad (un sistema con política agresiva muestra 66.67% de éxito de ataque frente a 34.25% de uno más estricto). La memoria pre-aprobada sin validación es un riesgo, no una optimización.
Tratar lo que se escribe en memoria como verdadero porque está "dentro" del agente. Sin origen, sin nivel de confianza, sin política de escritura. Es el default, y la puerta abierta al poisoning de señal débil. La atribución de origen ya se perdió cuando relees la entrada.
Cada entrada lleva source y trust_level. En el retrieval, las de origen no confiable se ponen en cuarentena o se degradan. El write-path impone una política estrecha: qué claves, qué campos, desde qué orígenes. Barato de añadir, desproporcionadamente efectivo contra los ataques que los filtros de input no atrapan.
Evolución temporal vs reemplazo: el "confiadamente incorrecto"
El gap de producción número uno hoy no es el retrieval de hechos: es la evolución temporal del estado. Los sistemas tratan el cambio como reemplazo (overwrite) en lugar de evolución (transición versionada). Un usuario que se muda de Nueva York a San Francisco debe mostrar una transición temporal, no un overwrite que borra la historia. Sin timestamps precisos, ordenamiento temporal y un mecanismo de decay/invalidación, los hechos de alta relevancia se vuelven confiadamente incorrectos.
Compactación: pérdida de información dirigida (y canal de ataque)
Compactar es resumir el contexto y reiniciar la ventana con el resumen, preservando decisiones y bugs sin resolver y descartando tool outputs redundantes. El riesgo es asimétrico: compactar demasiado pierde contexto cuya importancia solo se revela después. Y es el canal C3: un atacante puede repetir contenido para que parezca importante ("salience-driven") y sobreviva al resumen. La gente trata la compactación como pura optimización de costos e ignora su rol de seguridad.
Durable execution: el estado del workflow también es memoria
Hay una clase de memoria que se ignora hasta que falla en producción: el estado durable de ejecución. Un turno de agente con tool-calls, human-in-the-loop y un LLM no determinista necesita que su progreso sobreviva a crashes. La técnica es journal/replay: registrar cada paso, y en un crash re-ejecutar desde el inicio devolviendo los resultados journalizados: las llamadas al LLM se tratan como activities idempotentes y no se re-ejecutan en replay. Confundir "memoria del agente" con "estado de ejecución durable" da sistemas frágiles que pierden trabajo o duplican efectos secundarios, como crear o cancelar la misma cita dos veces.
Una última advertencia honesta. Los pipelines de embeddings/RAG suelen venderse como el sinónimo de "memoria de agente". Para memoria personal y episódica de usuario, la búsqueda agéntica sobre archivos legibles a menudo les gana en frescura y trazabilidad y elimina la deriva del índice vectorial, además de quitar una superficie de poisoning. RAG sigue ganándose su lugar en corpus enormes. Como default de memoria de usuario, es complejidad que probablemente todavía no necesitas.