Si has sentido el impuesto de la pérdida de contexto entre sesiones, el reflejo es querer que el agente «tenga memoria». Buen instinto, mal encuadre. La pregunta no es si un agente tiene memoria. Es qué merece recordarse, dónde debe vivir y en qué forma, para que un agente en frío pueda cargarlo y actuar sobre ello correctamente.
Casi todos los intentos de memoria de agentes fracasan porque contestan «recuérdalo todo» o «no recuerdes nada», y los dos están mal. Recuérdalo todo y reconstruyes el problema de la ventana de contexto en una base de datos: un montón de notas obsoletas y contradictorias sobre las que el agente no puede razonar. No recuerdes nada y cada sesión arranca en frío. La versión útil es selectiva y estructurada, y construirla empieza por una taxonomía.
Tres tipos de cosa que vale la pena persistir
No todo el conocimiento duradero es igual. Falla distinto, cambia a velocidades distintas y quiere casas distintas. Me encuentro con que tres categorías cubren casi todo lo que de verdad necesita sobrevivir a una sesión.
Decisiones
Una decisión es una elección entre alternativas, con una razón. «Usamos bloqueo optimista aquí porque la contención es baja y el coste de reintentar es trivial.» La parte valiosa no es la elección, son las alternativas descartadas y el razonamiento, porque es lo que impide que un agente futuro vuelva a proponer lo que ya descartaste.
Las decisiones son solo-append por naturaleza. No editas una decisión, la reemplazas con una más nueva, y la vieja queda como historia para que el rastro del porqué siga intacto. La forma correcta es un log: entradas con fecha, cada una con la elección, las alternativas y la razón. Un log de decisiones es la pieza de memoria de agente de más palanca, porque mata la forma más cara de pérdida de contexto, volver a litigar preguntas ya cerradas.
Invariantes
Un invariante es una regla que tiene que aguantar a través de los cambios. «Esta tabla es solo-append.» «Nunca llames a la red desde dentro de este módulo.» «Todo el dinero se guarda en céntimos enteros.» Los invariantes se diferencian de las decisiones en algo crítico: un agente necesita verlos al empezar cada sesión, antes de escribir nada, porque su trabajo entero es restringir lo que se escribe.
Eso significa que los invariantes van en el fichero que el agente lee primero, el fichero de reglas, no enterrados en un log que quizá consulte. Es justo el material de la sección de restricciones de una spec, y por eso memoria y especificación se difuminan aquí. Un invariante duradero es en realidad un trozo de una especificación viva que sigue viva entre sesiones en vez de degradarse en un chat. La restricción que sobrevive al viaje entre herramientas — una spec portable en vez de una nota atrapada en un chat — es la misma restricción que un agente tiene que honrar el martes que viene.
Estado
El estado es el status actual del trabajo: qué está hecho, qué está en marcha, qué está bloqueado, cuál es el siguiente paso. A diferencia de decisiones e invariantes, el estado no es solo-append ni permanente. Es una foto pensada para sobrescribirse. El «en progreso» de ayer es el «hecho» de hoy, y mantener la versión vieja es activamente dañino, porque un agente que carga estado viejo rehará trabajo terminado o reanudará desde el punto equivocado.
El estado quiere otra forma: un fichero pequeño, actual, que se sobrescribe en sitio y responde «dónde estamos». Un fichero de progreso, no un log. El modo de fallo de la memoria de estado es el opuesto al de la memoria de decisiones. Las decisiones se pudren si borras la historia. El estado se pudre si la conservas.
La forma importa tanto como el contenido
Fíjate en que cada categoría quiere una forma distinta, y equivocar la forma arruina el contenido.
- Las decisiones quieren un log solo-append. Una historia editable destruye el rastro.
- Los invariantes quieren un fichero de reglas al principio del contexto. Un log que el agente quizá no lea es inútil para una restricción que tiene que atar cada escritura.
- El estado quiere una sola foto sobrescrita. La historia aquí es ruido que despista.
Mete las tres en un solo documento, como crecen muchos ficheros CLAUDE.md, y cada una corrompe a las otras. Los invariantes quedan enterrados bajo el churn del estado. La historia de decisiones se aplana en un blob de status actual. El agente lee una sopa y no honra ninguna de forma fiable. Separar por categoría no es orden, es lo que hace la memoria cargable.
log de decisiones
- solo-append
- nunca se edita
- la historia es el valor
fichero de estado
- se sobrescribe
- sin historia
- solo lo actual
La memoria la escribe el trabajo, no se mantiene al lado
Esta es la trampa que mata a casi todos los sistemas de memoria: piden que un humano los mantenga, así que se pudren en cuanto el humano se lía. Un log de decisiones que nadie actualiza es peor que no tener log, porque miente con autoridad.
La única versión que sobrevive es memoria que el trabajo escribe como efecto secundario de hacer el trabajo. Cuando se toma una decisión en una sesión, se loguea ahí, en esa sesión, no en una pasada de documentación que nunca llega. Cuando se establece un invariante, aterriza en el fichero de reglas como parte de terminar la tarea, no después. En el momento en que la memoria se vuelve una tarea aparte, muere. El nombre del lado de producto de este patrón es un sistema que se mantiene solo, el argumento detrás de el cerebro de producto que se mantiene solo, y es el mismo requisito en la capa de código: si mantener la memoria al día no es parte del bucle, no se va a mantener al día.
Por qué esto es el antídoto contra la deriva
Memoria y deriva son dos caras de una moneda. Los agentes derivan justo cuando la cosa que debería restringirlos no está delante de ellos. Un invariante que vive en memoria duradera y se carga al empezar cada sesión es un invariante que el agente no puede violar en silencio, porque está ahí en el contexto, atando la escritura. Sácalo de la memoria y se convierte en una regla que existió una vez, en un chat, que ya nadie puede señalar.
Es también lo que hace sobrevivible correr trabajo en paralelo. Cuando mantienes varias sesiones vivas a la vez, no pueden cargar cada una las decisiones compartidas en una conversación privada, o divergirán. La memoria externa y compartida es lo único que todas pueden leer, y por eso persistir fuera del chat no es un lujo, es la precondición para que más de un agente trabaje sobre el mismo producto sin contradecirse.
La versión de una línea
Las decisiones van en un log solo-append. Los invariantes van en el fichero de reglas que el agente lee primero. El estado va en una sola foto sobrescrita. Las tres viven en el repo, fuera de cualquier chat, y las escribe el trabajo en vez de mantenerse al lado.
Haz eso y un agente en frío deja de ser un agente en blanco. Carga lo que el sistema sabe, honra las restricciones y retoma donde lo dejó la última sesión. Esa es la diferencia entre un agente con buena ventana de contexto y un agente que de verdad es parte de un sistema que recuerda. El primero es una herramienta lista. El segundo es lo que te deja dejar de ser el runtime a mano.
¿Cuál es la decisión que has tenido que re-explicarle a un agente más de dos veces? Cuéntame en el foro.
Preguntas frecuentes
¿Qué debería recordar un agente de código entre sesiones?
No todo. Tres tipos de cosa se ganan el sitio: decisiones (una elección entre alternativas, con el razonamiento que impide volver a proponerlas), invariantes (reglas que tienen que aguantar los cambios) y estado (el status actual del trabajo). Recuérdalo todo y reconstruyes el problema de la ventana en una base de datos; no recuerdes nada y cada sesión arranca en frío.
¿Dónde debería vivir cada tipo de memoria de agente?
En formas distintas, porque la forma es media parte del contenido. Las decisiones quieren un log solo-append donde la historia es el valor. Los invariantes quieren el fichero de reglas que el agente lee primero, para que aten cada escritura. El estado quiere una sola foto sobrescrita, sin historia. Mete las tres en un documento y cada una corrompe a las otras.
¿Por qué se pudren los sistemas de memoria de agentes?
Porque piden que un humano los mantenga, así que mueren en cuanto el humano se lía, y un log de decisiones que nadie actualiza miente con autoridad. La única versión que sobrevive es memoria que el trabajo escribe como efecto secundario: una decisión logueada en la sesión en que se toma, un invariante que aterriza en el fichero de reglas al terminar la tarea.
¿Debería meter todo en el CLAUDE.md?
No todo. Ahí es justo donde chocan los tres tipos: los invariantes quedan enterrados bajo el churn del estado, la historia de decisiones se aplana en un blob de status, y el agente lee una sopa que no honra de forma fiable. Guarda los invariantes en el fichero de reglas, las decisiones en un log, y el estado en su propia foto.