Vaig enviar onze versions de Neotoma entre el 26 de febrer i l'1 d'abril de 2026. La [versión del desenvolupador] inicial (/posts/neotoma-developer-release) era funcional però aproximada. Va funcionar a la meva màquina, en els meus fluxos de treball, amb els meus supòsits al forn. Cinc setmanes de comentaris de l'avaluador, proves diàries i ús del món real van sorgir allà on es va trencar per a tots els altres.

La categoria més gran de millores és la fiabilitat de la CLI, perquè la CLI és el primer que toca un nou usuari i el primer que pot fallar durant la incorporació.

El segon és l'estabilitat MCP, perquè el servidor MCP és el que els agents truquen centenars de vegades al dia i els errors silenciosos corrompeixen els fluxos de treball sense previ avís.

El tercer és la integritat de les dades en condicions reals. Aquesta publicació cobreix el que ha canviat al paquet npm, no el lloc ni els documents.

El ritme era un llançament cada tres o quatre dies. Algunes versions van solucionar un error de paginació únic. Altres van incloure setmanes d'enduriment a la CLI, les accions HTTP i el temps d'execució MCP. El fil comú és que cada llançament abordava alguna cosa que va trencar o va confondre una persona real que intentava utilitzar Neotoma per primera vegada.

## La CLI va deixar de suposar que era jo

La CLI de la versió del desenvolupador va funcionar des d'una comprovació d'origen a la meva màquina. Aquest era l'únic context que havia provat. La primera onada de comentaris va deixar clar que això no era suficient.

La primera solució va ser la resolució del camí. Quan instal·leu Neotoma a nivell global mitjançant npm i l'executeu des d'un directori arbitrari, la CLI ha de trobar els seus propis recursos sense que hi hagi una comprovació d'origen. v0.3.3 ha afegit una resolució alternativa des de la ubicació del paquet instal·lat. v0.3.8 va enviar `openapi.yaml` dins del fitxer tarball npm, de manera que el fitxer d'especificacions sempre estava disponible, no només quan vau clonar el repo.

La detecció del medi ambient va venir després. La CLI ara distingeix entre executar-se des d'una comprovació d'origen i executar-se des d'una instal·lació npm global. Les característiques que requereixen font (com el mode túnel) estan tancades amb missatges d'error clars en lloc de fallades críptices. La terminologia de la sortida de la CLI també ha canviat: "Camí de Neotoma" per a la ubicació del temps d'execució configurada, "comprovació de la font" per als fluxos de treball de desenvolupament. L'idioma anterior utilitzava "repo" per a tots dos, cosa que va confondre les persones que s'instal·laven mitjançant npm i no tenien repo.

El flux d'inici ha millorat en diverses versions. La v0.3.6 a la v0.3.9 va reforçar progressivament l'experiència de primera execució: millor orientació a l'entorn, UX d'inici més clar, maneig de camins de configuració més fort. A la v0.3.10, la CLI podria detectar el seu propi context d'instal·lació i ajustar el comportament sense que l'usuari li hagi de dir res.

v0.3.11 va ser la versió CLI única més gran. Va afegir una cerca flexible (`neotoma entities search` amb identificadors posicionals, `--identifier` i `--query` com a àlies), una ruta d'entrada estructurada preferida per a la botiga (`--entities` i `--file` juntament amb l'existent `--json=`) i `storage merge-db` per combinar bases de dades de modes de resolució de conflictes SQL. v0.4.0 va fer que el maneig d'arguments fos més fiable a través dels embolcalls de nodes, panets i deno.

L'efecte net: la CLI va passar de "funciona a la meva màquina" a "funciona amb una instal·lació nova de npm en un directori arbitrari a la màquina d'una altra persona". Aquesta bretxa era més gran del que esperava.

## MCP es va convertir en segur per a l'ús diari d'agents

El servidor MCP és com interactuen els agents amb Neotoma. Ha de ser fiable d'una manera diferent d'una CLI. Els agents no llegeixen missatges d'error. Tornen a intentar-ho, malinterpreten o abandonen el context en silenci.

La primera correcció MCP va ser trivial però important. La v0.3.8 ha desplaçat la sessió informativa del registre d'esquemes fora de stdout. MCP utilitza stdio per a la comunicació estructurada entre l'agent i el servidor. L'inici de sessió al mateix flux ha corromput el protocol. Els agents obtindrien respostes confuses o es penjaven. Moure els registres a stderr va solucionar una classe d'errors silenciosos que eren difícils de diagnosticar.

La v0.3.11 incloïa actualitzacions de temps d'execució MCP més àmplies juntament amb la capa d'acció HTTP i la gestió de consultes d'entitats. Els camins de recuperació es van fer més fiables per a consultes d'estil de llista versus d'identificador. La integració de la cerca lèxica va tenir cobertura de regressió. El servidor MCP i l'API HTTP ara comparteixen més comportament, de manera que els agents i els consumidors directes de l'API veuen resultats coherents.

La v0.4.0 va continuar aquest treball amb millores en la generació de la línia de temps, la projecció d'observació, el càlcul de les instantànies i el comportament del registre d'esquemes. Aquests són els mecanismes interns que determinen què veuen els agents quan consulten l'estat de l'entitat. Encertar-los significa que els agents obtenen respostes correctes i coherents entre les sessions.

## La paginació i el filtratge d'entitats es van fer honestos

v0.3.4 es va solucionar un error específic que exposava un problema més ampli. Quan vau consultar entitats per tipus (per exemple, totes les tasques), les entitats suprimides s'han inclòs al recompte de resultats però es van filtrar dels resultats visibles. Els desplaçaments de paginació utilitzaven el recompte no filtrat. El resultat: pàgines amb menys elements del que s'esperava, totals inconsistents i agents que pensaven que ho havien recuperat tot quan no ho havien fet.

La solució va ser paginar després de filtrar, no abans. El total ara reflecteix entitats visibles. Això sona menor, però és important per a qualsevol flux de treball d'agent que passa a través dels resultats, que és la majoria d'ells quan teniu més d'unes quantes desenes d'entitats de qualsevol tipus.

## La fusió de bases de dades es va convertir en una eina real

Vaig [va escriure sobre la pèrdua i la recuperació de 6.000 records](/posts/how-i-lost-and-recovered-6000-memories) al març. Aquesta experiència va motivar l'enviament de "storage merge-db" com a ordre CLI adequada a la v0.3.11.

L'ordre combina dues bases de dades SQLite amb una gestió explícita de conflictes. Tres modes: `safe` (per defecte, falla en qualsevol conflicte), `keep-target` (l'objectiu guanya en col·lisió), `keep-source` (la font guanya). El mode d'execució en sec mostra el que s'inseriria i el que entraria en conflicte abans de comprometre's. Després de la fusió, l'ordre torna a calcular les instantànies de l'entitat a partir del registre d'observació perquè l'estat derivat es mantingui correcte.

Aquesta no és només una eina de recuperació. Gestiona la combinació de dades de múltiples instàncies de Neotoma, la migració entre màquines i la fusió de bases de dades de desenvolupament i producció. L'arquitectura basada en observacions fa que totes aquestes operacions siguin segures perquè les observacions són immutables i l'estat de l'entitat és determinista donat el mateix conjunt d'observacions.

## S'ha ampliat el suport multieina

La versió per a desenvolupadors admetia Cursor, Claude i ChatGPT mitjançant MCP. La v0.3.11 va afegir documentació explícita d'integració de ChatGPT i va enviar `openapi_actions.yaml`, una superfície en forma d'OpenAPI per als fluxos de treball d'Accions HTTP i GPT personalitzades. Això significa que ChatGPT pot consumir Neotoma no només mitjançant MCP, sinó també mitjançant la interfície d'accions natives que utilitzen els GPT personalitzats.

El contracte OpenAPI en si es va actualitzar a les v0.3.11 i v0.4.0 per reflectir els canvis a la capa d'acció. Si consumeix Neotoma de manera programàtica mitjançant l'API, aquestes versions requereixen tornar a comprovar els clients generats.

## S'ha eliminat el camí d'extracció antic

v0.4.0 va eliminar la ruta del codi `llm_extraction`. Aquest va ser un enfocament heretat que utilitzava models de llenguatge en la canalització d'emmagatzematge. El principi de disseny de Neotoma és que cap LLM es troba en el camí crític per a l'emmagatzematge o la recuperació. L'extracció es produeix a la capa d'agent, no a l'interior de Neotoma. L'eliminació de la ruta antiga alinea la base de codi amb aquest principi i simplifica els elements interns.

Aquest és el tipus de canvi que és invisible per als usuaris, però que és important per a la direcció del projecte. Neotoma és una capa de veritat, no una capa d'inferència. El camí d'extracció va desdibuixar aquesta línia. Ara no ho fa.

## El que em va ensenyar el ritme

L'enviament d'onze llançaments en cinc setmanes no estava previst. Cada llançament responia a alguna cosa específica: un informe d'error, una experiència de primera execució confusa, un flux de treball que es va trencar en la producció, una inconsistència arquitectònica que no podia ignorar.

El patró que va sorgir va ser: l'ús diari aflora problemes, els comentaris de l'avaluador confirmen les prioritats i les petites versions els solucionen abans que es combinin. L'alternativa, agrupar els canvis en grans versions, hauria deixat els usuaris reals bloquejats durant setmanes amb un comportament trencat.

El llançament del desenvolupador es va posicionar com a "brut a propòsit". Això va ser honest. El que vaig subestimar va ser quantes de les vores aspres eren específiques de la meva pròpia configuració. Resolució de camins, detecció d'entorns, seguretat stdio, coherència de la paginació: cap d'aquests va ser problemes per a mi perquè vaig executar des de la font, al meu terminal, amb les meves dades. Cadascun d'ells va ser un problema per a algú que instal·lava mitjançant npm per primera vegada.

La següent fase és diferent. Les primeres cinc setmanes van respondre "funciona per a algú que no sóc jo". El següent tram respon "per què algú canviaria del que ja va construir".

Almenys deu persones del meu [grup d'avaluadors](/posts/customer-research-through-agents) estan construint la seva pròpia memòria d'agent. Fitxers Markdown, SQLite, batecs del cor JSON, CRM de fitxer pla. Mateix problema, implementacions diferents. Diversos d'ells van anomenar els desencadenants exactes de quan es trencaria la seva solució: escriptures concurrents de diversos agents, preguntes de procedència que no poden respondre, escalar més enllà d'unes quantes dotzenes d'entitats actives. Aquests desencadenants són el meu full de ruta.

Els propers objectius concrets provenen del que van demanar els avaluadors, no d'una llista de desitjos de funcions.

- **Incorporació trivial amb un benefici immediat.** La CLI funciona en altres màquines ara, però "funciona" no és el mateix que "cinc minuts per valorar". Un avaluador va passar una hora llegint documents abans de configurar-se en una màquina virtual. Això ha de ser de cinc minuts i el primer que passa després de la instal·lació no hauria de ser una base de dades buida. La incorporació impulsada per l'agent hauria d'escanejar els vostres fitxers locals, emplenar Neotoma amb registres reals i mostrar una línia de temps o una visió que no teníeu abans. El moment aha no és "instal·lat". El moment aha és "ja sap alguna cosa útil sobre les meves dades".
- **Una història de convivència clara.** Diversos avaluadors van preguntar si Neotoma hauria de conviure al costat de la memòria automàtica de Claude o la memòria integrada de ChatGPT, o substituir-los. La resposta està al costat, i el producte ha de fer-ho evident.
- **Profunditat en dominis on la procedència no és negociable.** Sanitat, compliment, auditoria financera: els avaluadors d'aquests espais van dir que el llenguatge ja encaixa. El treball està fent els esquemes i garanties concretes per a aquestes verticals.

El treball arquitectònic més profund prové del meu propi ús diari, no de les peticions de l'avaluador. L'execució de Neotoma com a capa de memòria principal durant mesos va sorgir problemes estructurals que ningú de l'exterior encara no notaria.

- **Convergència limitada.** Els agents són estocàstics. El mateix missatge d'usuari pot produir diferents tipus d'entitats, noms de camp i estructures de relació segons l'estat d'ànim del model. La meva instància té 170 tipus d'entitats, i part d'aquesta varietat és deriva, no ontologia real. Les properes versions afegeixen la normalització del temps d'escriptura: els mapes d'àlies de manera que "compra" i "transacció" es resolen amb el mateix tipus canònic, la concordança de camps difusos perquè "import" i "import_eur" no bifurquin l'esquema, i l'emmagatzematge augmentat per la recuperació perquè el sistema comprovi si hi ha duplicats abans que l'agent els creï.
- **Governança de l'esquema.** Ara mateix, qualsevol agent pot inventar un nou tipus d'entitat a la primera botiga. Aquesta llibertat és útil d'hora, però crea un problema de neteja a escala. La capa de govern planificada afegeix el registre d'àlies, els cicles de vida d'abandonament i els avisos de diagnòstic quan una botiga s'allunya de l'esquema canònic. El sistema es manté permissiu a l'hora d'escriure, però dóna comentaris a la resposta perquè els agents s'autocorregin.
- **Aplicació progressiva.** Els esquemes d'avui es dedueixen una vegada i mai no s'ajusten. El següent pas és el seguiment de la confiança: després de prou observacions d'un tipus, l'esquema es cristal·litza i el sistema pot advertir sobre camps comuns que falten, desajustos de tipus i patrons de relació trencats. No bloquejar botigues, només emergir allò que sembla malament. El mode estricte esdevé activat per a tipus d'apostes altes, com ara els registres financers on la variació d'extracció és important.

Neotoma és [codi obert a GitHub](https://github.com/markmhendrickson/neotoma). Si vau provar la versió per a desenvolupadors i vau arribar a les vores aspres, moltes d'elles s'han abordat en aquestes versions. Si encara no ho heu provat, el millor punt de partida és [demanar al vostre agent que avalui si Neotoma s'adapta al vostre flux de treball](https://neotoma.io/evaluate). L'agent llegeix la pàgina, inspecciona la vostra configuració i us diu sincerament si és adequat abans d'instal·lar qualsevol cosa.