Empecé a realizar un seguimiento de mis entrenamientos en ChatGPT. Repeticiones, pesas, cómo se sintió la sesión. Después de unas semanas le pedí que comparara el rendimiento de hoy con las sesiones anteriores. Me dio una comparación detallada y segura. Los números estaban equivocados.

No ligeramente apagado. Equivocado. Citó sesiones que no coincidían con lo que realmente había registrado. Revisé mi historial de conversaciones. Los datos con los que estaba "comparando" no existían en la forma que afirmaba. Parte parecía un resumen sin pérdidas de lo que le había contado semanas antes. Algunas cosas parecían inventadas.

El diagnóstico natural es alucinación. La modelo inventó cosas. No pude confirmar eso. ¿ChatGPT nunca había almacenado los datos originales? ¿Había almacenado algo y luego lo había resumido? ¿El recuerdo había vagado entre sesiones? No tenía forma de ver qué creía el sistema en la fecha en que registré esas sesiones, o si alguna vez había tenido los números reales. No podía descartar una alucinación. Tampoco podía descartar la corrupción.

Esa incapacidad para distinguir es el verdadero problema. Con la mayoría de los sistemas de memoria de IA no se puede saber qué modo de falla está viendo. La herramienta de diagnóstico no existe. Casi nadie lo está construyendo.

## Dos modos de falla, no uno

La industria tiene una palabra para "la modelo dijo algo mal": alucinación. Es el comodín para cada resultado incorrecto. Cuando los agentes utilizan memoria persistente, existen dos modos de error distintos. Necesitan soluciones diferentes.

**La alucinación** es un fallo a nivel de modelo. El LLM genera contenido sin base en sus aportaciones. La recuperación estuvo bien. La generación salió mal. Las correcciones son a nivel de modelo: mejor conexión a tierra, generación con recuperación aumentada, decodificación restringida, cadenas de verificación.

**La corrupción de la memoria** es una falla a nivel de infraestructura. Los datos almacenados son incorrectos. El modelo lo recupera fielmente. La respuesta parece correcta porque la recuperación fue correcta. Lo que se recuperó había cambiado.

La corrupción de la memoria pasa todos los controles diseñados para las alucinaciones. El pasaje coincide con la consulta. La modelo cita su fuente. La salida se basa en datos almacenados. Cada barandilla dice que la respuesta se basa en información real. La información es incorrecta.

## Por qué la corrupción es la opción predeterminada

Cada categoría principal de memoria de agente almacena estados mutables de forma predeterminada.

La memoria de la plataforma (ChatGPT, Claude, Gemini, Copilot) sobrescribe las entradas durante la actualización. No hay rastro de versión. Los sistemas de recuperación (Mem0, Zep, LangChain Memory) fusionan o reemplazan memorias cuando se consolidan.

Los sistemas basados ​​en archivos (markdown, JSON) permanecen mutables a menos que agregues git. Git te brinda historial real y diferencias para repositorios pequeños. [Se adapta mal a escala de gigabytes](https://x.com/garrytan/status/2040797478434549792) para datos escritos por agentes, y pocos equipos lo tratan como un registro de escritura anticipada para la memoria.

Las bases de datos estándar (SQLite, Postgres) pueden implementar fuentes de eventos, tablas temporales y activadores de auditoría. Su ruta predeterminada todavía se sobrescribe: `ACTUALIZAR` reemplaza la fila y el valor anterior desaparece.

Ninguno de estos preserva [el historial versionado o previene la mutación silenciosa](/memory-guarantees) listo para usar. Cualquiera de ellos *podría*. Casi ninguno *lo hace*.

Incluso los nuevos diseños bien pensados ​​pueden caer en la misma trampa. La [especificación GBrain] de Garry Tan (https://gist.github.com/garrytan/49c88e83cf8d7ae95e087426368809cb) acierta en muchos aspectos: SQLite, FTS5, búsqueda vectorial, MCP desde el primer día. La especificación todavía reescribe la verdad compilada en lugar de agregarla. Su agente reescribe 7.471 páginas con una combinación incorrecta. La versión incorrecta se vuelve canónica. Sin pista de auditoría. Arquitectura limpia, mismo modelo de mutación.

Este no es un mal lanzamiento. Es una cultura de referencia para toda la categoría. Métricas de recuperación de seguimiento de adopción, estrellas y financiación: recuperación en k (a menudo escrito R@k), precisión, latencia, relación de compresión. Esas métricas importan. Es necesaria una buena recuperación. No es suficiente que los agentes escriban en su propia memoria. Ningún punto de referencia ampliamente utilizado prueba lo que sucede con los datos almacenados después de escribirlos.

[MemPalace](https://github.com/milla-jovovich/mempalace) es un ejemplo reciente. El proyecto alcanzó 19.000 estrellas de GitHub en dos días con "puntuaciones de referencia perfectas". [Análisis independiente](https://penfieldlabs.substack.com/p/milla-jovovich-just-released-an-ai) encontró que las cifras de los titulares eran [métricas de recuperación, no precisión de un extremo a otro](https://github.com/milla-jovovich/mempalace/issues/27). La copia de lanzamiento engañosa es un problema de MemPalace. La estructura de incentivos es el problema de la categoría: 19.000 estrellas para puntuaciones de recuperación, cero preguntas sobre integridad de escritura. Supermemory, Mem0 y al menos una docena más que sigo compiten en el mismo eje. Ninguno publica métricas sobre si los datos almacenados sobreviven una semana de escrituras del agente sin cambios.

Para aplicaciones tradicionales, el estado mutable está bien. Para la memoria del agente es un problema. Los agentes escriben con frecuencia, entre sesiones, a veces con conflictos. Dos sesiones escriben valores diferentes para el mismo campo. La última escritura gana. El primer valor desaparece. Nadie es notificado. No hay constancia de que alguna vez fuera diferente.

El resumen impulsado por LLM empeora esto. Los sistemas fusionan registros antiguos en resúmenes nuevos. El resumen reemplaza a los originales. Si la fusión fue incorrecta (dos personas se fusionaron en una, se perdió un detalle, se resolvió mal una ambigüedad), los originales desaparecieron. No se puede comparar el resumen con lo que reemplazó. Lo que reemplazó ya no existe.

Esto no es teórico. Cuando [recuperé mi base de datos de producción](/posts/how-i-lost-and-recovered-6000-memories) después de borrarla, tenía copias de seguridad de diferentes fechas. Podría comparar el estado de la entidad a lo largo del tiempo. Algunas entidades difirieron entre las copias de seguridad del 3 y el 9 de marzo. En un sistema de solo anexos, ambos valores sobreviven como observaciones con marca de tiempo. En un sistema mutable, sólo sobrevive lo último. Nunca sabrías que existía el valor anterior.

## La auditoría que nadie ejecuta

La mayoría de los equipos comprueban si hay alucinaciones. Verifican que el resultado del modelo se base en el contexto recuperado. Prueban si el modelo inventa hechos.

Casi nadie comprueba si los datos almacenados han cambiado. Preguntar:

**¿Puedes ver qué cambió?** Si un valor difiere del de la semana pasada, ¿puedes ver ambos valores? ¿Cuándo cambió y qué lo desencadenó?

**¿Puedes reproducir el estado anterior?** ¿Puedes reconstruir lo que el agente creía en una fecha específica, no solo la instantánea de hoy?

**¿Puedes rastrear la fuente?** Para cualquier hecho almacenado, ¿puedes nombrar el agente, la sesión y la entrada que lo creó o lo cambió?

Si alguna respuesta es no, la corrupción puede ser indetectable. No imposible. Indetectable. Podría estar sucediendo ahora. No lo sabrás hasta que algo se rompa y alguien pregunte de dónde vino ese número.

## ¿Qué lo impide?

La corrupción de la memoria es estructural, no un problema modelo. Mejores indicaciones y una recuperación más inteligente no solucionan el problema. La solución es arquitectónica.

**Inmutabilidad.** Las observaciones no cambian después de la escritura. La nueva información es una nueva observación. Los viejos se quedan. El estado de la entidad se deriva del historial completo, no de una sola fila mutable.

**Procedencia.** Cada hecho contiene metadatos: qué agente lo escribió, cuándo, desde qué entrada, en qué sesión. Cuando un valor parece incorrecto, se rastrea la custodia. Cuando dos agentes entran en conflicto, ves a ambos y eliges.

**Repetición temporal.** El estado proviene de un registro de observación, no de una fila actual. Puedes reconstruir la creencia en cualquier momento pasado. La corrupción se vuelve visible cuando los estados actuales y pasados ​​divergen.

Estas propiedades cuestan algo. Los registros de solo agregar crecen. Volver a calcular el estado a partir del historial cuesta más que leer una fila. Los sistemas que se consolidan intercambian almacenamiento y latencia con el historial completo. La inmutabilidad cambia escrituras simples y almacenamiento estricto por auditabilidad. Ese intercambio vale la pena cuando los agentes escriben recuerdos que afectan los resultados reales. En muchos casos de producción, ya lo es.

Construí estas propiedades en [Neotoma](https://neotoma.io). No predije todos los escenarios de corrupción. Seguí alcanzando un estado mutable que producía respuestas incorrectas sin forma de diagnosticarlas. Neotoma necesita tiempo de instalación. No es una configuración cero. No edita la memoria como un archivo simple. Esos son costos reales. La apuesta es que la historia versionada, la procedencia y la repetición importan más que la conveniencia una vez que los agentes escriben el estado que impulsa las decisiones.

## El riesgo compuesto

La corrupción se agrava de una manera que las alucinaciones normalmente no lo hacen. Una respuesta alucinada muchas veces muere cuando alguien la lee y dice "eso está mal". Una conversación, un error.

Persiste una entrada de memoria dañada. Se recupera nuevamente. Da forma a decisiones posteriores. Mis comparaciones de ejercicios no fallaron ni una sola vez. Cada comparación posterior se basó en los mismos datos desviados o faltantes. Cada respuesta parecía bien por sí sola. El error era invisible a menos que verificara mis propios registros, lo que anula el objetivo de un rastreador de agentes.

Escala eso a lo que está en juego. Un correo electrónico incorrecto en la memoria significa que cada envío se envía a la persona equivocada hasta que alguien se da cuenta. Un monto en dólares incorrecto significa más de una factura mala.

La corrupción vive en la capa de la memoria, no en el modelo. La depuración normal lo omite. El modelo funciona. La recuperación funciona. Los datos almacenados son incorrectos o nunca se almacenaron correctamente. No se puede diseñar rápidamente una infraestructura pasada que deja caer su propia historia.

## Qué comprobar

Si usa memoria de agente, intente esto. Elija cinco entidades que su agente almacenó hace más de dos semanas. Recuperarlos. Compare los valores actuales con los que cree que almacenó originalmente.

Si no puede hacer esa comparación, su sistema no conserva el historial. Estás ciego a la corrupción. Eso no significa que haya habido corrupción. Significa que no sabrías si así fuera. "No sabríamos" no es suficiente una vez que los agentes gastan dinero, contactan a los clientes o desencadenan acciones en el mundo real.

Un punto de referencia serio de integridad de escritura se ejecutaría así. Semilla N entidades con valores conocidos. Ejecute sesiones de agente M que lean y escriban las mismas entidades. Espera una semana. Compare los valores almacenados con los originales.

Dos puntuaciones importan. **Tasa de deriva:** ¿qué porcentaje de valores cambió sin una corrección explícita del usuario? **Detectabilidad:** para cada cambio, ¿puede el sistema mostrar cuándo ocurrió, qué lo causó y el valor anterior? En la actualidad, tampoco hay informes de referencia de memoria de IA ampliamente utilizados.

La industria tiene razón al luchar contra las alucinaciones. El problema más difícil ya está dentro de los sistemas que parecen saludables, porque casi nadie comprueba si los datos almacenados siguen siendo los mismos que estaban almacenados.

## ¿Cuándo comenzará la industria a preguntar?

La integridad de escritura deja de ser opcional cuando los errores de los agentes tienen un precio. Hoy en día muchos errores reciben una regeneración o un rápido ajuste. Los agentes cada vez más [pagan, envían correos electrónicos, ejecutan código y actúan en el mundo real](/posts/six-agentic-trends-betting-on). Cuando un costoso fracaso se debe a una memoria perdida en lugar de a una confabulación del modelo, la autopsia agrega una segunda pregunta después de "¿alucinó el modelo?" ¿Cambiaron los datos almacenados?

Esa presión no permanecerá dentro de las empresas con equipos de cumplimiento. [La presión de la auditoría se mueve hacia abajo en el mercado](/posts/six-agentic-trends-betting-on) donde los errores cuestan dinero. Los consultores, los constructores individuales y los equipos pequeños necesitarán la misma respuesta: ¿qué creía el sistema cuando produjo ese resultado? Si su capa de memoria no puede decirlo, la capa de memoria es la responsabilidad.

El detonante es económico, no filosófico. La primera autopsia pública que culpe a la memoria silenciosamente corrupta, no a las alucinaciones, cambiará la forma en que la industria habla de confiabilidad. Esa autopsia es un cuándo, no un si.