Reparar memory drift, cuando la memoria de tu agente empieza a contradecirse

En algún momento le pasa a todo el que usa memoria en serio. Le preguntas algo a la IA y recibes dos respuestas en una misma sesión. En una frase dice "Usas Postgres" y en la siguiente "Usas Supabase". Ambas fueron ciertas alguna vez, ahora solo confunden. Eso es memory drift. Los síntomas son sutiles al principio, se vuelven más agresivos con el tiempo, y en algún momento la memoria está tan saturada de afirmaciones viejas que la IA alucina más de lo que ayuda.

Este playbook es la caja de herramientas para el día en que notas que tu memoria está rota. Recorremos paso a paso diagnóstico, limpieza y verificación. A diferencia de la rutina de higiene de memoria (L4-09), esto no es un ritual de mantenimiento sino una reparación de emergencia. Una hora hasta 90 minutos, y la memoria vuelve a estar en pie.

1. Detectar el drift, tres síntomas

Antes de echar mano de las herramientas, pregúntate si los síntomas son realmente de memoria y no variación del modelo. Tres señales claras.

Primero, la IA cita hechos que ya no son válidos. Hace seis meses dijiste "Usamos MySQL", luego migraste a Postgres, ambos están en la memoria, y elige al azar. Segundo, da nombres contradictorios para la misma cosa. "Aklow Memory" y "StudioMeyer Memory" son dos entidades separadas en tu knowledge graph aunque sea el mismo producto. Tercero, hace sugerencias que rechazaste explícitamente. Lodash por ejemplo, porque en mayo dijiste usa vanilla, en julio lo olvidaste y usaste lodash un rato, y ahora ambas cosas están guardadas como "preferencia del usuario".

Si ves dos de estos tres, el drift ya está aquí. Hora de diagnosticar.

2. Sacar un inventario, cuantificar el daño

Antes de borrar nada, mira qué tan grave es de verdad. nex_contradictions(action: "stats") es el punto de entrada. Eso te da el número de contradicciones encontradas, ordenadas por estado.

Regla aproximada: por debajo de 10 contradicciones abiertas es desgaste normal, de 10 a 50 es un backlog de mantenimiento, por encima de 50 es drift agudo. Si pending o unresolved está por encima de 50, sigue con este playbook. Si está por debajo de 10, solo necesitas la rutina de L4-09.

Apunta el número. Lo vas a necesitar al final para la comparación antes y después.

3. Listar y agrupar las contradicciones

nex_contradictions(action: "pending") saca la lista abierta. Mira las primeras 20, no todas.

Lo que buscas son clústeres. Misma entidad, varias versiones. "Elección de base de datos" muy probablemente aparecerá diez veces, porque cada migración hizo una afirmación nueva. Cuando detectas un clúster, has identificado el problema real. Vistas por separado las contradicciones parecen casualidad, en el clúster queda claro que una entidad se fue enredando durante meses.

Anota los tres clústeres principales. Esos reciben trato especial enseguida, el resto va a auto-resolve.

4. Identificar observaciones obsoletas

Las contradicciones son un tipo de drift, los hechos viejos sin usar son el otro. nex_consolidate(action: "cleanup_stale_obs", dryRun: true) te muestra observaciones con confianza por debajo de 0.5 que tienen más de 30 días. Filtro por defecto, bueno para empezar.

Lee la salida con cuidado. Si matched supera el 50 por ciento de scanned, el servidor te bloqueó antes de la limpieza real. Eso es intencional, de lo contrario borrarías media base de datos sin querer.

En ese caso comprueba si el filtro era demasiado amplio. Quizás maxAgeDays: 30 es demasiado joven para tu flujo de trabajo, súbelo a 60 o 90. Quizás maxConfidence: 0.5 es demasiado laxo, bájalo a 0.3.

5. Leer el dry run, no pasarlo por encima

La salida del dry run te muestra ejemplos de los aciertos. Lee de cinco a diez de ellos a mano. Pregúntate por cada acierto, ¿esto es realmente obsoleto?

Si ves aciertos que no deberían irse ("del 15 de enero, el stack técnico de MeetMyAgent es Next.js 16"), tu filtro está mal y tienes que volver al paso 4. Si los aciertos parecen basura ("del 3 de febrero, entrada de prueba, foo bar"), el filtro está bien y pasas al paso 6.

Nunca te saltes el paso 5. Limpieza sin revisar el dry run es como rm -rf sin --preview.

6. Ejecutar la limpieza

Si el dry run se veía bien, el mismo comando con dryRun: false. El servidor invalida las observaciones de forma suave (pone valid_to), no borra de forma dura. Es decir, puedes recuperarlas vía SQL si hace falta.

Si en el dry run viste un bloqueo masivo (matched por encima del 50 por ciento de scanned) y estás seguro de que es lo que quieres, añade force: true. Hazlo solo si entiendes por qué saltó el umbral de protección. Force sin entenderlo lleva regularmente a borrados de memoria tras los cuales la IA de repente no sabe nada de ti.

Apunta cuántas observaciones se invalidaron. Segundo número para la comparación antes y después.

7. Fusionar duplicados

El drift suele producir duplicados. "StudioMeyer Memory" y "studiomeyer-memory-server" son técnicamente dos entidades, de hecho una. nex_deduplicate(action: "scan", autoMergeThreshold: 0.85) encuentra los duplicados de alta confianza y los fusiona automáticamente.

El umbral por defecto es 0.85, eso solo capta coincidencias estrechas. Para una limpieza más agresiva puedes bajar a 0.75, así se auto-fusionan más pares pero el riesgo de fusiones erróneas sube. Recomendación personal, quédate en 0.85 y fusiona el resto a mano con nex_entity_merge.

Las operaciones de fusión son reversibles vía nex_entity_history si cometes un error, pero solo en los primeros segundos antes de que entren las cachés. Cuidado.

8. Ejecutar el confidence decay

El drift también viene de que afirmaciones viejas disfrutan de la misma confianza que las frescas. El decay lo resuelve. nex_decay(action: "run") reduce la confianza de observaciones que llevan mucho tiempo sin consultarse.

Bueno saberlo, el decay no es destructivo. Solo cambia el orden. Una observación con confianza bajada aparece más tarde en la recuperación, pero no se borra. Al consultarse de nuevo la confianza vuelve a subir.

Para drift agudo ejecútalo una vez, luego mensualmente. La rutina mensual es L4-09.

9. Verificar el always-on switch

Después de la limpieza compruebas si la IA realmente lee la nueva memoria. Si no, limpiaste y nadie se entera.

Abre una sesión fresca, una herramienta que no quieras mencionar. Haz una pregunta específica del proyecto, sin pista de que tienes memoria. "¿Qué base de datos uso para el proyecto X?" Si la respuesta es concreta y correcta, el always-on switch funciona. Si la IA se va por las ramas o da respuestas genéricas, el switch está desactivado.

Reparación, nex_profile(action: "save") escribe un snapshot en el auto-context, que se carga en cada sesión nueva. Después la misma pregunta en una sesión nueva, ahora debería acertar.

10. Guardar el patrón para que no vuelva

Último paso, el más importante. Apunta qué causó el drift. Con tres frases basta.

Por ejemplo: "El drift vino de una migración de DB en marzo, las afirmaciones viejas de MySQL se quedaron como fuente de verdad junto a las nuevas de Postgres. La solución fue guardar la migración explícitamente como decisión e invalidar las viejas. Prevención, en cada decisión de arquitectura marcar el estado anterior explícitamente como invalidado."

Guarda eso como aprendizaje con categoría mistake y etiqueta memory-drift. Efecto compuesto, en un año tienes de cinco a diez entradas así y el próximo drift se detecta temprano.

Ahora compara los números del paso 2 (contradicciones) y del paso 6 (observaciones obsoletas) con los valores actuales. Si las contradicciones están por debajo de 10 y la tasa de obsoletas por debajo del 5 por ciento, la memoria está reparada. Si no, vuelve al paso 3 con un ajuste de filtro más fino.

Qué viene después

Evitar el drift de nuevo es L4-09, la lección de higiene de memoria orientada al mantenimiento. Si quieres mantener la memoria sincronizada entre varias herramientas de IA, el playbook "memory-portabel-nutzen". Para la pregunta de por qué la memoria tiene sentido en absoluto y qué pasa sin ella, L4-01 "warum-memory".