Por qué duermen nuestros agentes de IA: una memoria que se actualiza sola

En marzo le das a un agente la dirección del servidor de pruebas. En junio, el servidor cambia de lugar y le das la nueva dirección. Una memoria que solo acumula cosas ahora guarda las dos. La primera no es exactamente incorrecta. Era correcta en su momento. Pero, de vez en cuando, el agente elegirá esa dirección con total seguridad, como alguien que te indica cómo llegar a un restaurante que cerró hace años.

Ese es el problema de la mayoría de las memorias para agentes de IA. Conseguir que un agente recuerde algo es fácil. Las dificultades empiezan cuando lo que recuerda deja de estar al día.

Terminamos creando nuestra propia memoria en Sno Station. No era algo que me entusiasmara especialmente. Ya hay buenas herramientas de memoria, algunas con decenas de miles de estrellas en GitHub, y el mundo no necesita un décimo proveedor de memoria. No intentamos serlo. Pero necesitábamos tres cosas y no logramos encontrarlas juntas.

Una memoria para todos los agentes

La primera es fácil de explicar. Usamos más de un agente. Claude Code, Codex y, a veces, OpenClaw y Hermes. Cada uno tiene su propia idea de lo que es la memoria, y la memoria de cada uno termina en su propia puerta.

Así que le dices a Claude Code que el equipo despliega los jueves y el viernes Codex no lo sabe. Eres tú quien lleva la información de uno a otro. Tú eres el cable.

En Sno Station hay un almacén de memoria por persona, en tu propia máquina y cifrado. Todos los agentes leen y escriben en él mediante un complemento sencillo. El complemento registra discretamente lo que vale la pena conservar mientras trabajas y recupera lo pertinente al comenzar una sesión. Por debajo hay exactamente un proceso que escribe, así que dos agentes no pueden sobrescribirse mutuamente.

Eso también hace posible el relevo. Supongamos que un agente se queda sin cuota a mitad de una tarea y otro toma el relevo. El segundo no empieza de cero. Sabe lo que sabía el primero. Sin una memoria compartida, un relevo no es más que un segundo agente que te pide que se lo expliques todo otra vez.

También significa que la memoria te pertenece a ti y no al entorno que ejecuta al agente. Si el año que viene cambias el agente por otro, lo que aprendió sobre ti y tu trabajo se queda donde está.

Reemplazar en vez de acumular

La segunda cosa es el servidor de pruebas.

Muchos sistemas de memoria solo añaden. Cada dato nuevo va al montón. Nada sale de él. La demostración funciona bien. Unos meses después has cambiado de trabajo, la API ha cambiado y el agente todavía recuerda a tu antiguo jefe. Una memoria que solo agrega conserva todas las versiones y deja que el modelo las ordene en el peor momento posible.

La nuestra funciona de otra forma, y la regla es estricta. Cuando un dato nuevo contradice a uno anterior, un modelo examina ambos y da una de tres respuestas: reemplazar, conservar o no estar seguro. No se le permite decir nada más. El modelo juzga. El código corriente hace el resto. La entrada antigua se marca como retirada, la nueva ocupa su lugar y ante un agente solo se presentan recuerdos vigentes.

El modelo no tiene botón de borrar. Quiero subrayarlo. No puede eliminar nada por su cuenta, y una entrada retirada sigue ahí por si alguna vez necesitas comprobar lo que antes era cierto. Es más o menos la diferencia entre tachar una línea de un libro de cuentas y arrancar la página.

Qué tal funciona esa decisión

Decidir es la parte arriesgada. Si el modelo reemplaza un dato que debería haber conservado, has perdido algo verdadero. Eso es peor que el desorden.

Por eso entrenamos un modelo pequeño propio para esa única decisión y lo comparamos con un modelo de vanguardia de uno de los grandes laboratorios. Ambos hicieron el mismo examen: 223 pares de datos, uno anterior y otro más reciente, cada par con una respuesta correcta conocida.

Nuestro modelo eligió la acción correcta el 97,5 por ciento de las veces. El modelo de vanguardia, el 96,8.

La cifra que más me importa es la de los reemplazos incorrectos: los casos en que se habría descartado un dato verdadero. El nuestro lo hizo el 3,2 por ciento de las veces. El modelo de vanguardia, el 4,1.

No quiero exagerar este resultado. Es un examen pequeño, de 223 preguntas, de junio, y ambos modelos están cerca de la puntuación máxima. Desde entonces hemos preparado otro más difícil. Tampoco es una comparación con otras herramientas de memoria. Aún no la hemos hecho, y no voy a citar las cifras de otros como si fueran nuestras.

Lo que sí nos dice es que un modelo pequeño, ejecutado en una sola tarjeta gráfica, puede tomar esta decisión casi tan bien como los más grandes. Eso importa porque hay que decidir constantemente y porque se decide sobre cosas que preferirías no enviar a nadie.

Por qué dormir

La tercera cosa es cuándo se hace el trabajo.

No puedes hacer todo esto mientras el agente trabaja. Cada dato nuevo obliga a volver a revisar todo lo que el agente ya recuerda. Es lento, y el agente tiene una tarea que terminar. Por eso la parte pesada se hace cuando los agentes están inactivos.

Dentro de la empresa llamamos a ese proceso REM, por la fase del sueño en la que parece que las personas ordenan lo vivido durante el día. Al principio me resistí al nombre. Me parecía demasiado ingenioso. Pero es preciso. El proceso recorre las sesiones del día. Los datos antiguos se retiran y las contradicciones se resuelven. Después queda menos por recordar, y lo que queda se ajusta mejor a cómo trabajas ahora. La memoria debería reducirse durante la noche, justo lo contrario de lo que ocurre con un montón.

Tú eliges cuánto de esto sale de tu máquina. En la configuración más privada, no sale nada. El modelo de tu propio agente hace la consolidación y todo permanece en local. En la configuración predeterminada, las suscripciones de tus propios agentes se encargan de pensar. Y, si lo autorizas, nuestros modelos toman las decisiones más difíciles, como la de reemplazar o conservar que describí antes.

También debo explicar en qué punto estamos. El almacén compartido y la regla de reemplazo ya se usan a diario aquí. El proceso de sueño es la parte más reciente, y en nuestras propias máquinas todavía no se ejecuta todas las noches. Había estado omitiéndose por un error de configuración, y estamos corrigiéndolo. Prefiero contártelo yo a que lo descubras por tu cuenta.

Por qué está debajo de todo

Hay algo que no entendía cuando empezamos. Pensaba que la memoria era una función. Se parece más a un suelo sobre el que se construye.

La revisión nocturna, en la que los agentes leen sus propias sesiones y anotan lo aprendido, necesita un lugar donde guardar esas lecciones. El relevo entre agentes también lo necesita. Lo mismo ocurre con un registro de lo que ha hecho un agente y de cuántas veces acertó a la primera. Más adelante, cualquier cosa que construyamos en la nube se extraerá de lo que guarda esta memoria.

Nada de eso valdría la pena si se construyera sobre un montón que no deja de crecer. Necesita una memoria que pueda estar equivocada el lunes y corregida el martes, sin que una persona tenga que intervenir para arreglarla.

Cuando la memoria se equivoca, el siguiente agente hereda el error y tú tienes que explicarlo otra vez.

Hasta que el servidor vuelva a cambiar de lugar.

Sno Station es de código abierto. Está en sno.ai.