un sistema distribuido multiagente tanto en OpenClaw como en AWS AgentCore desde hace un tiempo. Solo en mi configuración de OpenClaw, tiene un agente de investigación, un agente de escritura, un motor de simulación, un programador de latidos y varios más. Colaboran de forma asincrónica, transmiten contexto a través de archivos compartidos y mantienen el estado durante sesiones que duran días o semanas.
Cuando incorporo otros sistemas de agentes como Claude Code o los agentes que he implementado en AgentCore, la coordinación, la memoria y el estado se vuelven más difíciles de resolver.
Finalmente, me di cuenta de que la mayor parte de lo que hace que estos agentes realmente funcionen no es la elección del modelo. Es la arquitectura de la memoria.
Entonces, cuando me encontré con “Memoria para agentes autónomos de LLM: mecanismos, evaluación y fronteras emergentes” (arxiv 2603.07670), sentí curiosidad por saber si la taxonomía formal coincidía con lo que había construido mediante sensación e iteración. Lo hace, bastante de cerca. Sin embargo, codifica mucho de lo que encontré por mi cuenta y me ayudó a ver que algunos de mis puntos débiles actuales no son exclusivos de mí y se están viendo de manera más amplia.
Repasemos la encuesta y analicemos sus hallazgos mientras comparto mis experiencias.
Por qué la memoria importa más de lo que piensas
El artículo comienza con una observación empírica que debería recalibrar sus prioridades si aún no lo ha hecho:
"La brecha entre 'tiene memoria' y 'no tiene memoria' es a menudo mayor que la brecha entre diferentes pilares de LLM".
Este es un reclamo enorme. Cambiar su modelo subyacente importa menos que si su agente puede recordar cosas. Lo he sentido intuitivamente, pero es útil verlo expresado claramente en una encuesta formal. Los profesionales dedican enorme energía a la selección de modelos y a la rápida sintonización, mientras tratan la memoria como una ocurrencia tardía. Eso es al revés.
El artículo enmarca la memoria del agente dentro de una estructura de Proceso de Decisión de Markov Parcialmente Observable (POMDP), donde la memoria funciona como el estado de creencia del agente en un mundo parcialmente observable. Esa es una formalización ordenada. En la práctica, significa que el agente no puede verlo todo, por lo que construye y mantiene un modelo interno de lo que es verdad. La memoria es ese modelo. Si se hace mal, cada decisión posterior se degradará.
El bucle de escritura, gestión y lectura
El artículo caracteriza la memoria del agente como un bucle de escritura, gestión y lectura, no sólo de "almacenamiento y recuperación".
Escribir: nueva información ingresa a la memoria (observaciones, resultados, reflexiones) Administrar: la memoria se mantiene, se poda, se comprime y se consolida Lectura: la memoria relevante se recupera y se inyecta en el contexto
En la mayoría de las implementaciones veo que "escriben" y "leen" y descuidan por completo "administrar". Se acumulan sin curación. El resultado es ruido, contradicción y contexto inflado. La gestión es la parte difícil y es allí donde la mayoría de los sistemas tienen dificultades o fracasan rotundamente.
Antes de las mejoras más recientes de OpenClaw, manejaba esto con una política de control heurístico: reglas sobre qué almacenar, qué resumir, cuándo escalar a la memoria a largo plazo y cuándo dejar que las cosas caduquen. No es elegante, pero me obliga a ser explícito sobre el paso de gestión en lugar de ignorarlo.
En otros sistemas que construyo, a menudo confío en mecanismos como la memoria AgentCore a corto y largo plazo, bases de datos vectoriales y sistemas de memoria Agent. El sistema de memoria basado en archivos no se adapta bien a sistemas grandes y distribuidos (aunque para agentes o chatbots, no está descartado).
Cuatro ámbitos temporales (y dónde los veo en la práctica)
El artículo divide la memoria en cuatro ámbitos temporales.
Memoria de trabajo
Esta es la ventana de contexto.
Es efímero, de gran ancho de banda y limitado. Todo vive aquí brevemente. El modo de falla es la dilución de la atención y el efecto "perdido en el medio", donde el contenido relevante se ignora porque la ventana está demasiado llena. He logrado esto, al igual que la mayoría de los equipos con los que he trabajado.
Cuando el contexto de OpenClaw, Claude Code o su chatbot se alarga, el comportamiento del agente se degrada de maneras que son difíciles de depurar porque el modelo técnicamente "tiene" la información pero no la usa. Lo más común que veo en los equipos (y en mí) es crear nuevos hilos para diferentes partes del trabajo. No mantienes abierto Claude Code todo el día mientras trabajas en más de 20 tareas JIRA diferentes; se degrada con el tiempo y funciona mal.
Memoria episódica
Esto captura experiencias concretas; qué pasó, cuándo y en qué secuencia.
En mi instancia de OpenClaw, estos son los registros de actividad diarios. Cada agente escribe un breve resumen de lo que hizo, lo que encontró y lo que intensificó. Estos se acumulan como una línea de tiempo con capacidad de búsqueda. El valor práctico es enorme: los agentes pueden mirar hacia atrás en el trabajo de ayer, detectar patrones y evitar repetir fallas. Herramientas como Claude Code tienen problemas, a menos que configures instrucciones para forzar el comportamiento.
Los agentes de producción pueden aprovechar cosas como la memoria a corto plazo del Agent Core para conservar estos recuerdos episódicos. Incluso existen mecanismos para comprender qué merece persistir más allá de una sola interacción.
El documento valida esto como un nivel distinto e importante.
Memoria semántica
Es responsable del conocimiento, los hechos, la heurística y las conclusiones aprendidas abstraídos y destilados.
En mi OpenClaw, este es el archivo MEMORY.md en el espacio de trabajo de cada agente. Está curado. No todo entra. El agente (o yo, periódicamente) decidimos qué vale la pena preservar como verdad duradera versus qué era situacional.
En Agent Core Memory, esta es principalmente la función de memoria a largo plazo.
Este paso de curación es fundamental; sin ella, la memoria semántica se convierte en un cajón de basura.
Memoria Procesal
Se trata de habilidades ejecutables codificadas, patrones de comportamiento y comportamiento aprendido.
En OpenClaw, esto se asigna principalmente a los archivos AGENTS.md y SOUL.md, que contienen instrucciones personales, restricciones de comportamiento y reglas de escalamiento. Cuando el agente los lee al inicio de la sesión, está cargando la memoria de procedimiento. Estos deben actualizarse en función de los comentarios de los usuarios, o incluso mediante procesos de "sueño" que analicen las interacciones.
Esta es un área en la que he sido negligente (al igual que los equipos con los que he trabajado). Dedico tiempo a ajustar un mensaje, pero los mecanismos de retroalimentación que impulsan el almacenamiento de la memoria procedimental y la iteración de estas personas a menudo quedan fuera.
El documento formaliza esto como un nivel distinto, lo que encontré validador. Estas no son sólo indicaciones del sistema. Son una forma de comportamiento aprendido a largo plazo que da forma a cada acción.
Cinco familias de mecanismos
Ahora que tenemos algunas definiciones comunes sobre los tipos de recuerdos, profundicemos en los mecanismos de la memoria.
Compresión residente en contexto
Esto cubre ventanas deslizantes, resúmenes continuos y compresión jerárquica. Estas son las estrategias de “mantenerse en contexto”. Los resúmenes continuos son seductores porque se sienten limpios (no lo son, explicaré por qué en un momento).
Estoy seguro de que todos se han topado con Claude Code o Kiro CLI comprimiendo una conversación cuando se vuelve demasiado grande para la ventana contextual. A menudo, es mejor reiniciar un hilo nuevo.
Tiendas con recuperación aumentada
Este es RAG aplicado al historial de interacción del agente en lugar de documentos estáticos. El agente incorpora observaciones pasadas y las recupera por similitud. Esto es poderoso para agentes de larga trayectoria con un historial profundo, pero la calidad de la recuperación se convierte rápidamente en un cuello de botella. Si sus incrustaciones no capturan bien la intención semántica, perderá recuerdos relevantes y sacará a la luz recuerdos obsoletos.
También te encuentras con problemas en los que preguntas como "qué pasó el lunes pasado" no recuperan recuerdos de calidad.
Superación personal reflexiva
Esto incluye sistemas como Reflexion y ExpeL, donde los agentes escriben autopsias verbales y almacenan conclusiones para ejecuciones futuras. La idea es convincente; Los agentes aprenden de los errores y mejoran. Sin embargo, el modo de falla es severo (lo cubriremos con más detalle en un minuto).
Creo que otros sistemas y reflexiones basados en 'sueños', como el patrón Google Memory Agent, también pertenecen a esta clase.
Contexto virtual jerárquico
Una arquitectura inspirada en el sistema operativo de MemGPT (consulte también el repositorio de GitHub). Una ventana de contexto principal es "RAM", una base de datos de recuperación es el "disco" y el almacenamiento de archivos es "almacenamiento en frío", mientras que el agente gestiona su propia paginación. Si bien esta categoría es interesante, los gastos generales y el trabajo de mantener estos niveles separados son onerosos y tienden a fallar.
El documento MemGPT y el repositorio de git tienen casi 3 años y todavía no he visto ningún uso real en producción.
Gestión basada en políticas
Este es un enfoque de nueva frontera, donde los operadores capacitados en RL (como almacenar, recuperar, actualizar, resumir y descartar) que los modelos aprenden a invocar de manera óptima. Creo que hay muchas promesas aquí, pero no he visto arneses reales para que los utilicen los constructores ni ningún uso real en producción.
Modos de falla
Hemos cubierto los tipos de recuerdos y los sistemas que los crean. Lo siguiente es cómo pueden fallar.
Fallos residentes en el contexto
La desviación del resumen se produce cuando se comprime repetidamente el historial para ajustarlo a una ventana contextual. Cada compresión/resumen descarta detalles y, eventualmente, te quedas con recuerdos que realmente no coinciden con lo que sucedió. Nuevamente, verá este Claude Code y Kiro CLI cuando las sesiones de codificación cubren demasiadas funciones sin crear nuevos hilos. Una forma en que he visto a los equipos combatir esto es mantener los recuerdos en bruto vinculados a los recuerdos resumidos/consolidados.
La dilución de la atención es el otro modo de falla en esta categoría. Incluso si puedes mantener todo en contexto (como ocurre con las nuevas ventanas de 1 millón de tokens), los mensajes más grandes “pierden” información en el medio. Si bien los agentes técnicamente tienen todos los recuerdos, no pueden concentrarse en las partes correctas en el momento correcto.
Fallos de recuperación
El desajuste semántico versus causal ocurre cuando las búsquedas de similitud devuelven recuerdos que parecen relacionados pero no lo están. Las incrustaciones son excelentes para determinar cuándo los textos "se parecen" entre sí, pero son terribles para saber "esta es la causa". En la práctica, a menudo veo esto cuando depuro mediante asistentes de codificación. Ven errores similares pero pueden pasar por alto la causa subyacente, lo que a menudo conduce a agitación y muchos cambios, pero nunca soluciona el problema real.
La ceguera de la memoria ocurre en sistemas escalonados cuando los hechos importantes nunca resurgen. Los datos existen, pero el agente nunca los vuelve a ver. Esto puede deberse a que una ventana deslizante se ha movido, porque solo recupera 10 recuerdos de una fuente de datos, pero lo que necesitaría habría sido el undécimo recuerdo.
Los fallos de orquestación silenciosa son los más peligrosos de esta categoría. Las políticas de paginación, desalojo o archivo hacen cosas incorrectas, pero no se generan errores (ni se pierden en el ruido del sistema autónomo o de los humanos que lo ejecutan). El único síntoma será que las respuestas empeorarán, se volverán más genéricas y menos fundamentadas. Si bien he visto esto surgir de varias maneras, la más reciente para mí fue cuando OpenClaw no pudo escribir archivos de memoria diarios, por lo que los resúmenes/resúmenes diarios no tuvieron nada que ver. Sólo me di cuenta porque seguía olvidando cosas en las que trabajamos durante esos días.
Fallos de integridad del conocimiento
El estancamiento es probablemente el más común. El mundo exterior cambia, pero la memoria de su sistema no. Las direcciones, los estados de los dispositivos, las preferencias del usuario y cualquier cosa en la que se base su sistema para tomar decisiones pueden variar con el tiempo. Los agentes de larga duración actuarán sobre la base de datos de 2024 incluso en 2026 (¿quién no ha visto a un LLM insistir en que la fecha es incorrecta, que el presidente equivocado está en el cargo o que la última tecnología aún no ha aparecido en escena?).
Los errores de autorrefuerzo (bucles de confirmación) ocurren cuando un sistema trata una memoria como una verdad fundamental, pero esa memoria es incorrecta. Si bien generalmente se desea que los sistemas aprendan y construyan una nueva base de verdad, si un sistema crea una mala memoria, su visión del mundo se ve afectada. En mi instancia de OpenClaw, decidió que mi integración de SmartThings con mi Home Assistant era defectuosa; por lo tanto, toda la información de un dispositivo SmartThings se consideró errónea y lo ignoró todo (de hecho, solo había algunas baterías agotadas en mi sistema).
La generalización excesiva es una versión más tranquila del autorrefuerzo. Los agentes aprenden una lección en un contexto limitado y luego la aplican en todas partes. Una solución alternativa para un solo cliente o un solo error es un patrón predeterminado.
Fallo ambiental
El manejo de contradicciones puede resultar increíblemente frustrante. A medida que se recopila nueva información, si entra en conflicto con la información existente, los sistemas no siempre pueden determinar la verdad real. En mi sistema OpenClaw, le pedí que creara algunos flujos de trabajo N8N. Todos crearon correctamente, pero la acción expiró, por lo que pensó que había fallado. Verifiqué que existían los flujos de trabajo, le dije a mi agente de OpenClaw que los recordara y estuvo de acuerdo. Durante las siguientes interacciones, el agente osciló entre creer que el flujo de trabajo estaba disponible y creer que no se había configurado.
Tensiones de diseño
Habrá tira y afloja contra todo esto para los agentes y los sistemas de memoria.
Utilidad versus eficiencia
Una mejor memoria normalmente significa más tokens, más latencia, más almacenamiento, más sistemas.
Utilidad versus adaptabilidad
La memoria que es útil ahora estará obsoleta en algún momento. La actualización es costosa y arriesgada.
Adaptabilidad versus fidelidad
Cuanto más actualice, revise y comprima, mayor será el riesgo de distorsionar lo que realmente sucedió.
Fidelidad versus Gobernanza
La memoria precisa puede contener información confidencial (PHI, PII, etc.) que es posible que deba eliminar, ofuscar o proteger.
Todo lo anterior versus Gobernanza
Las empresas tienen requisitos de cumplimiento complejos que pueden entrar en conflicto con todos ellos.
Conclusiones prácticas para los constructores
A menudo los equipos de ingeniería me preguntan cuál es el mejor sistema de memoria o dónde deberían comenzar su viaje. Esto es lo que digo.
Comience con ámbitos temporales explícitos
No construyas “memoria”. Cuando necesites memoria episódica, constrúyela. Cuando su caso de uso crezca y necesite memoria semántica, constrúyalo. No intente encontrar un sistema que lo haga todo y no cree todas las formas de memoria antes de que la necesite.
Tome en serio el paso de gestión
Planifica cómo mantener tu memoria. No planee acumular indefinidamente; averigüe si necesita compresión o conexión de memoria/comportamiento de sueño. ¿Cómo sabrás qué se incluye en la memoria semántica versus la memoria RAG? ¿Cómo manejas las actualizaciones? Sin saber esto, acumularás ruido, tendrás contradicciones y tu sistema se degradará.
Mantenga registros episódicos sin procesar
No confíe sólo en resúmenes; pueden desviarse o perder detalles. Los registros sin procesar le permiten volver a lo que realmente sucedió y recuperarlos cuando sea necesario.
Versión de memoria reflectante
Para ayudar a evitar contradicciones en resúmenes, recuerdos a largo plazo y compresiones, agregue marcas de tiempo o versiones a cada uno. Esto puede ayudar a sus agentes a determinar qué es cierto y cuál es el reflejo más preciso del sistema.
Trate la memoria procedimental como código
En OpenClaw, sus Agents.MD, Memory.MD, archivos personales y configuraciones de comportamiento son parte de su arquitectura de memoria. Revísalos y mantenlos bajo control de código fuente para que puedas examinar qué cambios y cuándo. Esto es especialmente importante si su sistema autónomo puede alterarlos en función de la retroalimentación.
Resumen
El encuadre escribir-gestionar-leer es la conclusión más útil de este artículo. Es simple, completo y te obliga a pensar en las tres fases en lugar de simplemente "almacenar cosas, recuperar cosas".
La taxonomía se corresponde sorprendentemente bien con lo que construí en OpenClaw mediante iteración y frustración. Eso es una validación o una lección de humildad, dependiendo de cómo se mire (probablemente ambas cosas). El artículo formaliza patrones que los profesionales han estado descubriendo de forma independiente, que es lo que debería hacer una buena encuesta.
La sección de problemas abiertos es honesta sobre cuánto queda sin resolver. La evaluación es todavía primitiva. En la práctica, la gobernanza se ignora en gran medida. La gestión basada en políticas es prometedora pero inmadura. Hay mucha pista aquí.
La memoria es donde ocurre la verdadera diferenciación en los sistemas de agentes. Ni el modelo, ni las indicaciones. La arquitectura de la memoria. El documento le brinda un vocabulario y un marco para pensar más claramente al respecto.
Acerca de
Nicholaus Lawson es un arquitecto de soluciones con experiencia en ingeniería de software y AIML. Ha trabajado en muchos sectores verticales, incluidas empresas de automatización industrial, atención médica, servicios financieros y software, desde nuevas empresas hasta grandes empresas.
Este artículo y cualquier opinión expresada por Nicholaus son suyos y no un reflejo de sus empleadores actuales, pasados o futuros ni de ninguno de sus colegas o afiliados.
No dude en conectarse con Nicholaus a través de LinkedIn en https://www.linkedin.com/in/nicholaus-lawson/