Cómo gobernar memoria persistente en un agente de código con versiones, alcance y rollback

Paso 1: crea tipos de memoria con semántica distinta. Empieza con al menos cuatro: fact, para algo observado en el proyecto; decision, para una regla aprobada; preference, para una elección personal; y temporary, para una excepción con caducidad. Añade campos como fuente, timestamp, responsable y evidencia. Evita una bolsa única de notas. Cuando el agente recupera memoria, el tipo determina cuánto puede confiar y qué hacer si aparece información nueva. Este pequeño esquema reduce el riesgo de convertir una frase casual en una norma persistente del repositorio.

Paso 2: asigna alcance explícito. Una memoria puede pertenecer al usuario, repositorio, carpeta, rama, ticket o equipo. Guarda el scope y obliga al recuperador a filtrarlo antes de rankear relevancia. Una preferencia de formato del usuario no debería convertirse en regla global del proyecto; una instrucción del repositorio no debe contaminar otro cliente. El alcance también facilita borrar o exportar conocimiento. Cuando una relación laboral termina o un proyecto se archiva, puedes retirar el estado correspondiente sin destruir memorias no relacionadas.

Paso 3: versiona cada cambio como un commit pequeño. Cada alta, edición o retiro de memoria debe crear un evento inmutable con estado anterior y nuevo. Eso permite construir un memory diff por sesión y revertir cambios concretos. No necesitas copiar un sistema Git completo; necesitas identidad, orden y causación. Si una sesión de debugging agrega tres reglas, el equipo puede revisar exactamente esas tres. Una memoria que influye en acciones futuras merece el mismo cuidado que una configuración, porque su efecto puede ser repetitivo aunque el archivo de código nunca cambie.

Paso 4: define reglas de contradicción. Cuando evidencia actual choca con una memoria, no dejes que el modelo improvise. Compara autoridad de fuente, fecha y tipo. Un fact derivado del código actual puede invalidar un fact antiguo; una decision aprobada quizá requiera confirmación antes de cambiar. Guarda ambos estados durante la resolución y marca el conflicto. Esta mecánica evita una clase de errores donde el agente mezcla reglas incompatibles y produce una tercera interpretación que nadie autorizó. El conflicto es información útil, no un problema que ocultar.

Paso 5: registra qué memorias fueron usadas. En cada ejecución guarda IDs de memorias recuperadas y, para acciones sensibles, cuáles afectaron la decisión. No hace falta registrar razonamiento interno. Basta con poder conectar una salida a su contexto persistente. Cuando aparece un bug, soporte puede reproducir el estado: versión de código, herramientas, input y memoria. Esta trazabilidad también ayuda a limpiar el almacén, porque revela notas que nunca se usan y memorias que dominan demasiadas tareas aunque ya no tengan evidencia reciente.

Paso 6: prueba secuencias, no instantáneas. Diseña tests de cinco o diez sesiones: enseñar una convención, usarla, cambiarla, introducir una contradicción y verificar el rollback. Mide recuperación correcta, actualización y ausencia de contaminación entre scopes. Incluye casos donde el usuario se equivoca y luego corrige la instrucción. Un sistema que pasa una prueba en estado limpio puede fallar después de acumular semanas de notas. Los benchmarks longitudinales son la única forma de evaluar la característica que hace valiosa a la memoria: su comportamiento a través del tiempo.

Implementación Goatify. Podemos empezar con un ledger sencillo por agente: tabla de memorias, tabla de eventos y tabla de usos. La interfaz muestra un resumen de “qué aprendió hoy” y permite aprobar cambios sensibles. Para clientes enterprise, un administrador puede bloquear memorias de ciertos tipos o exigir revisión. Así la memoria deja de ser un truco de personalización y se convierte en infraestructura gobernable. El agente puede mejorar de sesión en sesión sin convertir el pasado en una caja negra que controle silenciosamente el presente.