He estado trabajando en algo llamado **[Neotoma](/posts/truth-layer-agent-memory)**.[^1] No hay nada que probar todavía. Esta no es una publicación de lanzamiento y no estoy anunciando un producto ni solicitando suscripciones. El problema me ha estado molestando por un tiempo y, lo que es más importante, ha estado interfiriendo activamente en el trabajo que he estado tratando de hacer. Durante el año pasado, pasé mucho tiempo experimentando con sistemas de agentes: automatizando flujos de trabajo, delegando tareas a los agentes, permitiendo que los sistemas funcionen en varias sesiones en lugar de comenzar desde cero cada vez. Una y otra vez me he topado con la misma pared. Los sistemas eran capaces, a menudo de manera impresionante, pero no podía confiarles un estado real y continuo. Esa limitación no ha sido sólo teórica. Ha sido un obstáculo práctico para la automatización. ## Los sistemas de IA están cambiando silenciosamente de funciones Solían ser algo que simplemente consultabas: hacías una pregunta, obtenías una respuesta y seguías adelante. Cada vez más actúan. Escriben archivos y documentos, llaman a herramientas y API, hacen referencia a conversaciones pasadas entre sesiones y encadenan decisiones a lo largo del tiempo sin que se les solicite explícitamente cada paso. En ese momento, los datos personales dejan de ser material de referencia y pasan a convertirse en *estado*. Y el estado tiene requisitos diferentes. ## Lo que sigue rompiéndose no es la inteligencia, sino la confianza. Los sistemas de memoria de IA actuales se basan en la conveniencia. Optimizan el recuerdo, la velocidad y la fluidez, y si el sistema *siente* que te recuerda. Ninguno se basa en la procedencia, la inspeccionabilidad, la repetición o una causalidad clara. En la práctica, eso significa que puedo conseguir que un agente haga algo una vez, pero dudo en dejar que haga algo *otra vez*. La memoria cambia implícitamente. El contexto se desplaza. Las suposiciones se acumulan. Y cuando algo sale mal, no puedo responder qué cambió, por qué cambió o si el sistema tomaría la misma decisión si lo volviera a ejecutar desde cero. Esto es tolerable cuando la IA es de asesoramiento, pero no cuando está operativa. ## Parte del problema es una falta de coincidencia de categorías Seguimos tratando datos personales como notas, blobs de texto o contexto suelto. Mientras tanto, los agentes tratan esos mismos datos como entradas, restricciones, desencadenantes y estados de larga duración. No se puede automatizar de forma segura con datos que no se pueden inspeccionar, diferenciar, auditar o reproducir. Este no es un problema de UX. Es un problema de sistemas. ## Lo que parece faltar es una primitiva básica Estado personal explícito, inspeccionable y reproducible. Otros dominios resolvieron esto hace mucho tiempo. Las bases de datos hicieron que el estado de la aplicación fuera confiable. Los registros de eventos hicieron comprensibles los sistemas distribuidos. Los libros de contabilidad hicieron que el historial financiero fuera auditable. Los datos personales nunca antes necesitaron ese nivel de rigor, porque los humanos podían llevar el contexto en sus cabezas o reconstruirlo revisando registros manualmente. Los agentes cambian esa suposición. ## La implicación incómoda es que hacer esto correctamente agrega fricción Los cambios de estado no pueden ser implícitos. Las actualizaciones de memoria deben denominarse operaciones en lugar de efectos secundarios. Los aportes deben ser visibles y no inferidos. La historia tiene que ser reconstruible en lugar de ser algo manual. Renuncias a algo de magia y aceptas más ceremonia. De lo contrario, usted y sus agentes terminarán viviendo juntos de manera poco confiable a través de lentes de realidad divergentes. No existe un atajo para evitar esta compensación. Los sistemas que priorizan la comodidad y los sistemas seguros para los agentes van en direcciones opuestas. ## Estoy tratando los datos personales de la misma manera que los sistemas de producción tratan el estado. Esto lleva a algunas consecuencias inevitables. El comportamiento debe ser primero el contrato: los cambios de estado son operaciones escritas explícitas, no actualizaciones ad hoc. Las mutaciones tienen que ser explícitas. Nada "simplemente actualiza la memoria". Si los agentes van a actuar, necesitan interfaces restringidas y auditables en lugar de indicaciones opacas o incrustaciones. La repetición importa tanto como la respuesta actual: poder explicar cómo llegaste aquí es parte de la verdad. La misma entrada siempre produce la misma salida ya que la capa de memoria es determinista y los agentes tienen un sustrato confiable. Los cambios son inmutables y consultables para que pueda ver el estado de la entidad en cualquier momento. La memoria proviene tanto de los documentos que usted carga como de los datos que los agentes escriben durante las conversaciones, un gráfico estructurado que unifica entidades y eventos para que los agentes puedan razonar en todos ellos. Estas no son preferencias estéticas. Dejan de intentar, y fracasan repetidamente, automatizar flujos de trabajo reales sin perder la confianza en el sistema que realiza el trabajo. ## Por qué lo estoy diseñando de esta manera Lo mantendré primero en MCP y CLI. No hay interfaz de usuario web ni memoria oculta. Es local primero de forma predeterminada, con interfaces explícitas para los agentes. Solo ingiero lo que proporciono explícitamente, sin escaneo automático ni ingesta en segundo plano. Esas no son omisiones, son barreras de seguridad. Hacen que sea más difícil, accidentalmente o no, mentir sobre lo que sabe el sistema y cómo llegó allí. También lo estoy haciendo multiplataforma y priorizando la privacidad por diseño. Funciona con ChatGPT, Claude y Cursor a través de MCP, no está vinculado a un único proveedor. Sus datos siguen siendo suyos, controlados por el usuario y nunca utilizados para capacitación. Esas no son comodidades; son requisitos previos para la confianza. ## Lo que no es No es una aplicación para tomar notas ni un "segundo cerebro"; es un sustrato de memoria estructurada para los agentes. No se trata de memoria ChatGPT ni de proyectos Claude controlados por el proveedor; es su propio sustrato, expuesto a través de MCP para que cualquier agente pueda usarlo. No es un almacén de vectores ni una capa RAG; es una memoria estructurada que prioriza el esquema y tiene procedencia. No es un agente autónomo ni un motor de flujo de trabajo ni un asistente de IA con memoria invisible; son los agentes de la capa de memoria los que leen y escriben, y usted controla. Y todavía no es algo que yo llamaría confiable. Estoy intentando construir la capa base antes de fingir que existen garantías. ## ¿Por qué ahora? Estamos normalizando sistemas que toman acciones en nuestro nombre, persisten en creencias y acumulan decisiones a lo largo del tiempo. Cuando esos sistemas fallen, y lo harán, la primera pregunta será: "¿Cómo sucedió esto?" En este momento, la mayoría de las herramientas no podrán responder a esa pregunta. Y durante el año pasado, esa incapacidad ha sido lo principal que me ha impedido confiar a los agentes cualquier cosa importante. Ese problema está a punto de escalar. La red agente está surgiendo. Necesitamos uno en el que los usuarios mantengan el control de la memoria, no uno en el que se la entreguemos a plataformas centralizadas y los agentes actúen en nuestro nombre utilizando métodos opacos y poco confiables. Estoy construyendo Neotoma para proporcionar eso: un sustrato que sea inspeccionable, reproducible y controlado por el usuario a medida que crece la red agente. ## Próxima vista previa para desarrolladores Estoy trabajando para lanzar una vista previa para desarrolladores para mi propio uso y pruebas públicas. Será tosco y explícitamente poco confiable (por ejemplo, las API pueden cambiar). Su propósito será probar estas ideas en uso real, no vender nada. Cómo me estoy acercando a la compilación: primero lo estoy probando internamente en mi propia pila de agentes para poder ver dónde ayudan realmente el determinismo y la procedencia y dónde se interponen en el camino. Los casos de uso incluyen: - **Tareas y ejecución**: tareas, planes, proyectos y resultados con fechas de vencimiento y recordatorios de seguimiento. - **Contactos y relaciones**: registros de contactos y gráfico de relaciones vinculados a comunicaciones, tareas y eventos. - **Comunicaciones**: clasificación de correo electrónico, procesamiento activado por flujo de trabajo y seguimiento de conversaciones. - **Finanzas** — Transacciones, flujos, ingresos, tenencias, transferencias y registro de costos - **Mantenimiento de registros**: compras, cuentas, propiedades e informes de análisis únicos - **Contenido**: publicaciones, historial personal, medios favoritos y fuentes de consumo. - **Salud**: hábitos, ejercicios y seguimiento continuo Estoy priorizando la estabilidad de MCP y una CLI mínima antes de agregar más área de superficie, entidad de prueba de estrés y resolución de relaciones y consultas de cronograma a medida que aumenta el uso. Si este marco resuena, el trabajo se está desarrollando abiertamente aquí: [https://github.com/markmhendrickson/neotoma](https://github.com/markmhendrickson/neotoma) Destacar el repositorio es la forma más sencilla de realizar un seguimiento a medida que evoluciona. Las aportaciones de personas que piensan en sistemas agentes y estados escalables siempre son bienvenidas. [^1]: lleva el nombre del género *Neotoma* (ratas de carga), conocido por recolectar y preservar material.