TLDR: La mayoría de los agentes se reinician y olvidan. Aquí está la pila de memoria exacta que he construido para que mis agentes compartan contexto entre reinicios, se coordinen sin pisarse y retengan decisiones durante meses.
El problema que nadie resuelve
Así es la configuración de memoria típica de un agente de IA. Meter cosas importantes en el prompt del sistema. Esperar que la ventana de contexto no se acabe. Reiniciar y perderlo todo.
He ejecutado dos agentes coordinados (Ella en OpenClaw, Lyra en Hermes) a través de cientos de sesiones durante 6 meses. Lo que más los hace útiles no son los modelos ni las herramientas. Es la arquitectura de memoria.
Cuando Lyra envía una corrección a las 2 a.m., Ella lo sabe por la mañana. Cuando decidí en enero cómo se deben almacenar los secretos, ambos agentes siguen esa decisión en julio. Cuando una sesión falla a mitad de una tarea, la siguiente retoma exactamente donde se quedó.
Aquí está el sistema exacto de 4 capas.
Capa 1: Contexto dentro de la sesión
Cada sesión comienza leyendo dos archivos. El archivo de identidad es la identidad permanente del agente. No un prompt del sistema enterrado en la configuración. Un archivo Markdown real que puedo editar. Contiene cómo debe comportarse el agente, qué prioriza, qué nunca hace sin preguntar y su relación con los otros agentes.
El archivo de índice de memoria es el índice de todo lo que vale la pena recordar entre sesiones. No una base de datos vectorial. No embeddings. Una tabla de contenido simple que apunta a archivos de memoria individuales. Cada archivo de memoria es una nota corta con un nombre, una descripción, un tipo y un cuerpo breve. El índice siempre se carga. Los archivos individuales se leen bajo demanda cuando son relevantes.
¿Por qué Markdown? Porque puedo leerlo, editarlo y depurarlo. Cuando un agente comienza a actuar mal, abro el índice y encuentro la instrucción incorrecta. Cuando quiero cambiar un comportamiento, edito el archivo. Sin API. Sin panel de control. Sin reentrenamiento.
Capa 2: Retención posterior a la sesión (Hindsight)
El problema con la memoria solo en Markdown: solo captura lo que alguien escribe explícitamente. El contexto más valioso es implícito. Decisiones tomadas durante una ejecución. Hechos inferidos de una tarea. Cosas que resultaron ser importantes.
Hindsight es un backend de retención de hechos local que se ejecuta en localhost. Al final de cada sesión significativa, el agente envía automáticamente un conjunto curado de hechos retenidos a un banco con nombre. Cada agente tiene su propio banco.
Lo que se retiene: decisiones tomadas durante la sesión, hechos no obvios sobre el usuario o el proyecto, patrones de fallo y las correcciones que adoptamos, y preferencias que el usuario confirmó o corrigió.
Cuando comienza una nueva sesión, se consulta a Hindsight para obtener contexto relevante antes de que el agente responda. No es una búsqueda de texto completo en las transcripciones. Son hechos curados, etiquetados por tipo, que el agente ha aprendido que vale la pena conservar.
La ruta promovida: hecho de Hindsight, revisión humana, entrada en el índice de memoria. Retención automática con una puerta de aprobación humana.
Capa 3: Estado compartido a largo plazo (Nexus)
La memoria de un solo agente se rompe cuando agregas un segundo agente. Se desvían. Uno piensa que X es el estado actual del proyecto. El otro piensa Y. En una semana se están contradiciendo.
La solución es un archivo de estado compartido e inspeccionable que ambos agentes leen y escriben. Usamos una bóveda de Obsidian que llamo Nexus. Contiene un registro de contexto en vivo al que ambos agentes añaden después de cada turno significativo, un archivo de estado del proyecto, un registro de decisiones y un punto de control del contexto de trabajo por agente que se actualiza cada pocas llamadas a herramientas durante tareas largas.
El archivo de contexto en vivo es el apretón de manos en tiempo real. La invariante: antes de cada respuesta, léelo. Después de cada turno significativo, añade a él.
Cuando Lyra termina un PR a las 2 a.m. y Ella responde a mi pregunta matutina, Ella ya lo sabe. Leyó el registro. Sin paso de mensajes. Sin API entre agentes. Sin sondeo. Un archivo compartido, dos agentes, registro de solo añadido.
Capa 4: Conocimiento buscable (gbrain)
Las primeras tres capas manejan la memoria episódica. Qué pasó, qué se decidió, qué es importante conservar. gbrain es la capa semántica. Es una wiki compilada que se ejecuta como un servidor MCP sobre la bóveda de Nexus. Búsqueda de texto completo y semántica sobre todo lo que se ha escrito.
Cuando un agente necesita responder una pregunta de investigación, encontrar una síntesis previa o buscar cómo hemos manejado una clase de problema antes, consulta gbrain en lugar de releer cada archivo. La salida es una lista clasificada de páginas relevantes con procedencia. El agente lee lo que es relevante. No vuelca toda la bóveda en el contexto.
Esta es la diferencia entre memoria y recuerdo. Las capas 1 a 3 manejan lo que el agente lleva consigo. La capa 4 maneja lo que el agente puede buscar.
La invariante de sincronización entre agentes
Dos agentes, un archivo de contexto en vivo. El riesgo: que se sobrescriban entre sí, o que se pierdan las entradas del otro. La invariante que ejecutamos: cada entrada está firmada con el nombre del agente, el canal, el tipo y un resumen de una línea. Solo añadir. Nunca editar la entrada de otro. Si Lyra ha registrado algo relevante, Ella lo reconoce explícitamente en la siguiente respuesta. Para decisiones significativas, ambos agentes también escriben en el registro de decisiones con una marca de tiempo y una justificación.
Esto se ha ejecutado a través de cientos de sesiones. Hemos tenido un conflicto: una condición de carrera donde ambos agentes añadieron dentro del mismo minuto durante una transferencia. Resolución: leer ambas entradas, conciliar en el siguiente turno. No se necesita fusión automatizada.
Lo que esto reemplaza
Antes de esta arquitectura: cinco sesiones de chat desconectadas, cada una con su propio contexto obsoleto. Agentes contradiciéndose porque ninguno podía ver lo que el otro sabía. Instrucciones que di hace tres semanas, olvidadas. Decisiones que vivían en mi cabeza en lugar de en un archivo.
Después: dos agentes que se informan antes de cada respuesta. Un registro de estado compartido que ninguno puede negar. Decisiones retenidas que sobreviven meses de reinicios de contexto. Cada preferencia de comportamiento en un archivo que puedo editar y verificar.
La compensación honesta: este sistema requiere disciplina. Tienes que escribir las cosas. Tienes que mantener los archivos. Tienes que revisar lo que se retiene antes de que se vuelva permanente. No es un sistema mágico siempre activo. Es disciplina manual estructurada más automatización en las costuras.
Cómo empezar
No necesitas dos agentes ni una bóveda completa para ejecutar la versión uno de esto.
Paso 1: Un archivo de identidad más un índice de memoria. Créalos. Léelos al inicio de la sesión. Escribe cada preferencia de comportamiento en el índice la segunda vez que corrijas al agente por lo mismo.
Paso 2: Un archivo de estado compartido. Si ejecutas más de un agente, o usas Claude en múltiples ventanas, crea un archivo de contexto en vivo. Cada sesión añade a él al final y lo lee al inicio.
Paso 3: Una regla de retención. Cuando una sesión produce una decisión que debe sobrevivir, escríbela en el índice manualmente. Hazlo a mano hasta que confíes en el patrón. Luego automatiza el marcado.
Paso 4: Un archivo por hecho, no un documento grande. El índice apunta a archivos individuales. Esto facilita eliminar una memoria obsoleta sin tocar otras.
La pila completa de 4 capas tomó unos 6 meses en estabilizarse. Las capas 1 y 3 tomaron un fin de semana. Empieza ahí.
Conclusión
La mayoría de las configuraciones de memoria de agentes son gestión de ventanas de contexto con pasos adicionales. Funcionan hasta que la ventana se reinicia o agregas un segundo agente.
La memoria duradera del agente es un problema de infraestructura, no un problema de prompting. La respuesta son múltiples capas con diferentes horizontes de tiempo: contexto dentro de la sesión, hechos entre sesiones, estado compartido, conocimiento buscable.
Todo el nuestro es Markdown simple. Sin base de datos vectorial. Sin embeddings. Sin reentrenamiento. Solo archivos que puedo abrir, editar y depurar.
Los agentes que son realmente útiles no son los que tienen la ventana de contexto más grande. Son los que recuerdan lo que importa y olvidan lo que no.
Si estás construyendo agentes en los que quieras confiar para trabajo real, comienza con la arquitectura de memoria antes de agregar más herramientas.
Herramientas referenciadas
Hindsight (retención de memoria local): https://github.com/vectorize-io/hindsight
gbrain (wiki compilada / búsqueda semántica): https://github.com/garrytan/gbrain
OpenClaw (entorno de ejecución de agentes): https://openclaw.ai
Hermes (entorno de ejecución de agentes): hermes-agent.nousresearch.com
