Envié once versiones de Neotoma entre el 26 de febrero y el 1 de abril de 2026. La [versión para desarrolladores](/posts/neotoma-developer-release) inicial fue funcional pero tosca. Funcionó en mi máquina, en mis flujos de trabajo, con mis suposiciones incorporadas. Cinco semanas de comentarios de los evaluadores, pruebas internas diarias y uso en el mundo real surgieron donde fue un fracaso para todos los demás. La categoría más importante de mejoras es la confiabilidad de la CLI, porque la CLI es lo primero que toca un nuevo usuario y lo primero que puede fallar durante la incorporación. El segundo es la estabilidad de MCP, porque el servidor MCP es lo que los agentes llaman cientos de veces al día y las fallas silenciosas corrompen los flujos de trabajo sin previo aviso. El tercero es la integridad de los datos en condiciones reales. Esta publicación cubre lo que cambió en el paquete npm, no en el sitio ni en los documentos. El ritmo fue un lanzamiento cada tres o cuatro días. Algunas versiones solucionaron un error de paginación única. Otros incluyeron semanas de refuerzo en la CLI, las acciones HTTP y el tiempo de ejecución de MCP. El hilo común es que cada lanzamiento abordó algo que rompió o confundió a una persona real que intentaba usar Neotoma por primera vez. ## La CLI dejó de asumir que era yo La CLI de la versión del desarrollador funcionó desde un pago de origen en mi máquina. Ese fue el único contexto que había probado. La primera ola de comentarios dejó claro que esto no era suficiente. La primera solución fue la resolución de ruta. Cuando instala Neotoma globalmente a través de npm y lo ejecuta desde un directorio arbitrario, la CLI necesita encontrar sus propios recursos sin un control de origen presente. v0.3.3 agregó resolución alternativa desde la ubicación del paquete instalado. v0.3.8 envió `openapi.yaml` dentro del tarball npm para que el archivo de especificaciones siempre estuviera disponible, no solo cuando clonaste el repositorio. Luego vino la detección del entorno. La CLI ahora distingue entre ejecutar desde una extracción de origen y ejecutar desde una instalación global de npm. Las funciones que requieren fuente (como el modo túnel) están cerradas con mensajes de error claros en lugar de fallas crípticas. La terminología en la salida de la CLI también cambió: "Ruta de Neotoma" para la ubicación del tiempo de ejecución configurada, "compra de origen" para los flujos de trabajo de desarrollo. El lenguaje anterior usaba "repo" para ambos, lo que confundía a las personas que instalaban a través de npm y no tenían repositorio. El flujo de inicio mejoró en varias versiones. Las versiones 0.3.6 a 0.3.9 mejoraron progresivamente la experiencia de primera ejecución: mejor orientación del entorno, UX de inicio más claro, manejo de rutas de configuración más sólido. En la versión 0.3.10, la CLI podía detectar su propio contexto de instalación y ajustar el comportamiento sin que el usuario tuviera que decirle nada. v0.3.11 fue la versión CLI más grande. Agregó búsqueda flexible (`búsqueda de entidades neotoma` con identificadores posicionales, `--identifier` y `--query` como alias), una ruta de entrada estructurada preferida para la tienda (`--entities` y `--file` junto con el `--json=` existente) y `storage merge-db` para combinar bases de datos SQLite con modos de resolución de conflictos. v0.4.0 hizo que el manejo de argumentos fuera más confiable en contenedores de nodo, bun y deno. El efecto neto: la CLI pasó de "funciona en mi máquina" a "funciona en una nueva instalación de npm en un directorio arbitrario en la máquina de otra persona". Esa brecha era mayor de lo que esperaba. ## MCP se volvió seguro para el uso diario del agente El servidor MCP es la forma en que los agentes interactúan con Neotoma. Debe ser confiable en formas diferentes a una CLI. Los agentes no leen mensajes de error. Lo vuelven a intentar, malinterpretan o abandonan silenciosamente el contexto. La primera solución de MCP fue trivial pero importante. v0.3.8 movió los registros informativos del registro de esquema fuera de la salida estándar. MCP utiliza stdio para una comunicación estructurada entre el agente y el servidor. El inicio de sesión en la misma secuencia corrompió el protocolo. Los agentes recibirían respuestas confusas o se colgarían. Mover registros a stderr solucionó una clase de fallas silenciosas que eran difíciles de diagnosticar. v0.3.11 incluyó actualizaciones más amplias del tiempo de ejecución de MCP junto con la capa de acción HTTP y el manejo de consultas de entidades. Las rutas de recuperación se volvieron más confiables para consultas de estilo lista versus consultas de estilo identificador. La integración de búsqueda léxica obtuvo cobertura de regresión. El servidor MCP y la API HTTP ahora comparten más comportamiento, por lo que los agentes y los consumidores directos de API ven resultados consistentes. La v0.4.0 continuó este trabajo con mejoras en la generación de líneas de tiempo, proyección de observaciones, cálculo de instantáneas y comportamiento del registro de esquemas. Estos son los mecanismos internos que determinan qué ven los agentes cuando consultan el estado de la entidad. Hacerlas bien significa que los agentes obtienen respuestas correctas y consistentes en todas las sesiones. ## La paginación y el filtrado de entidades se volvieron honestos v0.3.4 solucionó un error específico que exponía un problema más amplio. Cuando consultaba entidades por tipo (por ejemplo, todas las tareas), las entidades eliminadas se incluían en el recuento de resultados, pero se filtraban de los resultados visibles. Los desplazamientos de paginación utilizaron el recuento sin filtrar. El resultado: páginas con menos elementos de los esperados, totales inconsistentes y agentes que pensaron que habían recuperado todo cuando no fue así. La solución fue paginar después del filtrado, no antes. El total ahora refleja entidades visibles. Esto suena menor, pero es importante para cualquier flujo de trabajo de agente que revise los resultados, que son la mayoría una vez que tiene más de unas pocas docenas de entidades de cualquier tipo. ## La combinación de bases de datos se convirtió en una herramienta real [Escribí sobre la pérdida y recuperación de 6000 recuerdos](/posts/how-i-lost-and-recovered-6000-memories) en marzo. Esa experiencia motivó el envío de `storage merge-db` como un comando CLI adecuado en v0.3.11. El comando fusiona dos bases de datos SQLite con manejo explícito de conflictos. Tres modos: "seguro" (predeterminado, falla en cualquier conflicto), "mantener el objetivo" (el objetivo gana en caso de colisión), "mantener la fuente" (la fuente gana). El modo de ejecución en seco muestra una vista previa de lo que se insertará y lo que entrará en conflicto antes de confirmar. Después de la fusión, el comando vuelve a calcular las instantáneas de la entidad del registro de observación para que el estado derivado siga siendo correcto. Esta no es sólo una herramienta de recuperación. Maneja la combinación de datos de múltiples instancias de Neotoma, la migración entre máquinas y la fusión de bases de datos de desarrollo y producción. La arquitectura basada en observaciones hace que todas estas operaciones sean seguras porque las observaciones son inmutables y el estado de la entidad es determinista dado el mismo conjunto de observaciones. ## Compatibilidad con múltiples herramientas ampliada La versión para desarrolladores admitía Cursor, Claude y ChatGPT a través de MCP. v0.3.11 agregó documentación explícita de integración de ChatGPT y envió `openapi_actions.yaml`, una superficie con forma de OpenAPI para flujos de trabajo de acciones HTTP y GPT personalizadas. Esto significa que ChatGPT puede consumir Neotoma no solo a través de MCP sino a través de la interfaz de acciones nativas que utilizan los GPT personalizados. El contrato OpenAPI en sí se actualizó en las versiones 0.3.11 y 0.4.0 para reflejar los cambios en la capa de acción. Si consume Neotoma mediante programación a través de la API, estas versiones requieren volver a verificar los clientes generados. ## Se eliminó la ruta de extracción anterior v0.4.0 eliminó la ruta del código `llm_extraction`. Este era un enfoque heredado que utilizaba modelos de lenguaje en el proceso de almacenamiento. El principio de diseño de Neotoma es que ningún LLM se encuentra en la ruta crítica para el almacenamiento o la recuperación. La extracción ocurre en la capa del agente, no dentro del Neotoma. Eliminar la ruta anterior alinea el código base con ese principio y simplifica los aspectos internos. Este es el tipo de cambio que es invisible para los usuarios pero que es importante para la dirección del proyecto. Neotoma es una capa de verdad, no una capa de inferencia. El camino de extracción desdibujó esa línea. Ahora no es así. ## Lo que me enseñó el ritmo No estaba previsto enviar once lanzamientos en cinco semanas. Cada versión respondió a algo específico: un informe de error, una experiencia de primera ejecución confusa, un flujo de trabajo que se interrumpió en producción, una inconsistencia arquitectónica que no podía ignorar. El patrón que surgió fue: el uso diario saca a la luz los problemas, los comentarios de los evaluadores confirman las prioridades y los pequeños lanzamientos los solucionan antes de que se agraven. La alternativa, agrupar los cambios en versiones grandes, habría dejado a los usuarios reales atrapados en un comportamiento incorrecto durante semanas. La versión del desarrollador se posicionó como "brusca a propósito". Eso fue honesto. Lo que subestimé fue cuántas de las asperezas eran específicas de mi propia configuración. Resolución de ruta, detección de entorno, seguridad estándar, coherencia de paginación: ninguno de estos fue un problema para mí porque ejecuté desde la fuente, en mi terminal, con mis datos. Cada uno de ellos fue un problema para alguien que instalaba a través de npm por primera vez. La siguiente fase es diferente. Las primeras cinco semanas respondieron "¿funciona para alguien que no soy yo?". El siguiente tramo responde "¿por qué alguien cambiaría lo que ya construyó?". Al menos diez personas en mi [grupo de evaluadores](/posts/customer-research-through-agents) están construyendo su propia memoria de agente. Archivos Markdown, SQLite, latidos JSON, CRM de archivos planos. Mismo problema, diferentes implementaciones. Varios de ellos nombraron los desencadenantes exactos de cuando su solución fallaría: escrituras simultáneas de múltiples agentes, preguntas de procedencia que no pueden responder, escalar más allá de unas pocas docenas de entidades activas. Esos factores desencadenantes son mi hoja de ruta. Los próximos objetivos concretos provienen de lo que pidieron los evaluadores, no de una lista de deseos de funciones. - **Incorporación trivial con recompensa inmediata.** La CLI ahora funciona en otras máquinas, pero "funciona" no es lo mismo que "cinco minutos para obtener valor". Un evaluador pasó una hora leyendo documentos antes de configurar una máquina virtual. Deben ser cinco minutos y lo primero que suceda después de la instalación no debería ser una base de datos vacía. La incorporación impulsada por agentes debería escanear sus archivos locales, completar Neotoma con registros reales y mostrar una línea de tiempo o información que no tenía antes. El momento ajá no es "está instalado". El momento ajá es "ya sabe algo útil sobre mis datos". - **Una historia de coexistencia clara.** Varios evaluadores preguntaron si Neotoma debería vivir junto con la memoria automática de Claude o la memoria integrada de ChatGPT, o reemplazarlas. La respuesta está al lado y el producto debe hacerlo obvio. - **Profundidad en dominios donde la procedencia no es negociable.** Atención médica, cumplimiento, auditoría financiera: los evaluadores en esos espacios dijeron que el lenguaje ya encaja. El trabajo es concretar los esquemas y garantías para esas verticales. El trabajo arquitectónico más profundo proviene de mi propio uso diario, no de las solicitudes de los evaluadores. Al utilizar Neotoma como mi capa de memoria principal durante meses, surgieron problemas estructurales que nadie en el exterior notaría todavía. - **Convergencia acotada.** Los agentes son estocásticos. El mismo mensaje de usuario puede producir diferentes tipos de entidades, nombres de campos y estructuras de relaciones según el estado de ánimo del modelo. Mi instancia tiene 170 tipos de entidades, y parte de esa variedad es deriva, no ontología real. Las próximas versiones agregan normalización del tiempo de escritura: asignaciones de alias para que "compra" y "transacción" se resuelvan en el mismo tipo canónico, coincidencia difusa de campos para que "cantidad" y "cantidad_eur" no bifurquen el esquema, y ​​almacenamiento con recuperación aumentada para que el sistema busque duplicados antes de que el agente los cree. - **Gobierno del esquema.** En este momento, cualquier agente puede inventar un nuevo tipo de entidad en la primera tienda. Esa libertad es útil desde el principio, pero crea un problema de limpieza a escala. La capa de gobernanza planificada agrega registro de alias, ciclos de vida de desuso y advertencias de diagnóstico cuando una tienda se desvía del esquema canónico. El sistema sigue siendo permisivo al escribir, pero brinda retroalimentación en la respuesta para que los agentes se autocorrijan. - **Aplicación progresiva.** Los esquemas actuales se infieren una vez y nunca se endurecen. El siguiente paso es el seguimiento de la confianza: después de suficientes observaciones de un tipo, el esquema cristaliza y el sistema puede advertir sobre campos comunes faltantes, discrepancias de tipos y patrones de relación rotos. No bloquear tiendas, simplemente sacar a la luz lo que parece mal. El modo estricto se convierte en opción para tipos de alto riesgo, como registros financieros, donde la variación de extracción es importante. Neotoma es [código abierto en GitHub](https://github.com/markmhendrickson/neotoma). Si probó la versión para desarrolladores y encontró problemas, muchos de ellos se han solucionado en estas versiones. Si aún no lo ha probado, el mejor punto de partida es [pedirle a su agente que evalúe si Neotoma se adapta a su flujo de trabajo](https://neotoma.io/evaluate). El agente lee la página, inspecciona su configuración y le dice honestamente si es adecuada antes de instalar algo.