Saya mengirimkan sebelas rilis Neotoma antara 26 Februari dan 1 April 2026. [rilis pengembang](/posts/neotoma-developer-release) awal berfungsi tetapi kasar. Ini berhasil di mesin saya, dalam alur kerja saya, dengan asumsi-asumsi saya yang tertanam di dalamnya. Masukan evaluator selama lima minggu, dogfood harian, dan penggunaan di dunia nyata muncul ketika hal itu tidak berlaku bagi orang lain.

Kategori peningkatan terbesar adalah keandalan CLI, karena CLI adalah hal pertama yang disentuh oleh pengguna baru dan hal pertama yang dapat gagal selama orientasi.

Yang kedua adalah stabilitas MCP, karena server MCP adalah yang dihubungi agen ratusan kali sehari dan kegagalan diam-diam merusak alur kerja tanpa peringatan.

Yang ketiga adalah integritas data dalam kondisi nyata. Posting ini mencakup apa yang berubah dalam paket npm, bukan situs atau dokumennya.

Kecepatannya adalah satu rilis setiap tiga hingga empat hari. Beberapa rilis memperbaiki satu bug penomoran halaman. Lainnya menggabungkan proses pengerasan selama berminggu-minggu di seluruh CLI, tindakan HTTP, dan waktu proses MCP. Benang merahnya adalah bahwa setiap rilis membahas sesuatu yang mematahkan atau membingungkan orang yang mencoba menggunakan Neotoma untuk pertama kalinya.

## CLI berhenti berasumsi bahwa itu adalah saya

CLI rilis pengembang berfungsi dari checkout sumber di mesin saya. Itulah satu-satunya konteks yang saya uji. Umpan balik gelombang pertama memperjelas bahwa ini tidak cukup.

Perbaikan pertama adalah resolusi jalur. Saat Anda menginstal Neotoma secara global melalui npm dan menjalankannya dari direktori arbitrer, CLI perlu menemukan sumber dayanya sendiri tanpa adanya checkout sumber. v0.3.3 menambahkan resolusi cadangan dari lokasi paket yang diinstal. v0.3.8 mengirimkan `openapi.yaml` di dalam tarball npm sehingga file spesifikasi selalu tersedia, tidak hanya saat Anda mengkloning repo.

Deteksi lingkungan datang berikutnya. CLI sekarang membedakan antara menjalankan dari checkout sumber dan menjalankan dari instalasi npm global. Fitur yang memerlukan sumber (seperti mode terowongan) dilindungi dengan pesan kesalahan yang jelas, bukan kegagalan samar. Terminologi dalam keluaran CLI juga berubah: "Jalur Neotoma" untuk lokasi waktu proses yang dikonfigurasi, "pembayaran sumber" untuk alur kerja pengembang. Bahasa sebelumnya menggunakan "repo" untuk keduanya, yang membingungkan orang yang menginstal melalui npm dan tidak memiliki repo.

Aliran init meningkat di beberapa rilis. v0.3.6 hingga v0.3.9 semakin memperketat pengalaman pengoperasian pertama: penargetan lingkungan yang lebih baik, UX startup yang lebih jelas, penanganan jalur konfigurasi yang lebih kuat. Pada v0.3.10, CLI dapat mendeteksi konteks penginstalannya sendiri dan menyesuaikan perilaku tanpa pengguna harus memberi tahu apa pun.

v0.3.11 adalah rilis CLI tunggal terbesar. Ini menambahkan pencarian fleksibel (`pencarian entitas neotoma` dengan pengidentifikasi posisi, `--identifier`, dan `--query` sebagai alias), jalur input terstruktur pilihan untuk penyimpanan (`--entities` dan `--file` di samping `--json=` yang ada), dan `storage merge-db` untuk menggabungkan database SQLite dengan mode resolusi konflik. v0.4.0 menjadikan penanganan argumen lebih andal di seluruh pembungkus node, bun, dan deno.

Efek akhirnya: CLI berubah dari "berfungsi di mesin saya" menjadi "berfungsi pada instalasi npm baru di direktori arbitrer di mesin orang lain." Kesenjangan itu lebih besar dari perkiraan saya.

## MCP menjadi aman untuk penggunaan agen sehari-hari

Server MCP adalah cara agen berinteraksi dengan Neotoma. Itu harus dapat diandalkan dengan cara yang berbeda dari CLI. Agen tidak membaca pesan kesalahan. Mereka mencoba ulang, salah menafsirkan, atau diam-diam mengabaikan konteks.

Perbaikan MCP yang pertama adalah hal yang sepele namun penting. v0.3.8 memindahkan log informasi registri skema dari stdout. MCP menggunakan stdio untuk komunikasi terstruktur antara agen dan server. Masuk ke aliran yang sama merusak protokol. Agen akan mendapat tanggapan yang kacau atau hang. Memindahkan log ke stderr memperbaiki kelas kegagalan diam-diam yang sulit didiagnosis.

v0.3.11 menyertakan pembaruan waktu proses MCP yang lebih luas bersama dengan lapisan tindakan HTTP dan penanganan kueri entitas. Jalur pengambilan menjadi lebih andal untuk kueri gaya daftar versus pengidentifikasi. Integrasi pencarian leksikal mendapat cakupan regresi. Server MCP dan API HTTP kini berbagi lebih banyak perilaku, sehingga agen dan konsumen API langsung melihat hasil yang konsisten.

v0.4.0 melanjutkan pekerjaan ini dengan peningkatan pada pembuatan garis waktu, proyeksi observasi, komputasi snapshot, dan perilaku registri skema. Ini adalah mekanisme internal yang menentukan apa yang dilihat agen ketika mereka menanyakan status entitas. Melakukannya dengan benar berarti agen mendapatkan jawaban yang konsisten dan benar di seluruh sesi.

## Penomoran halaman dan pemfilteran entitas menjadi jujur

v0.3.4 memperbaiki bug tertentu yang mengungkap masalah yang lebih luas. Saat Anda menanyakan entitas berdasarkan jenisnya (misalnya, semua tugas), entitas yang dihapus disertakan dalam jumlah hasil tetapi difilter dari hasil yang terlihat. Offset penomoran halaman menggunakan hitungan tanpa filter. Hasilnya: halaman dengan item lebih sedikit dari yang diharapkan, jumlah total yang tidak konsisten, dan agen mengira mereka telah mengambil semuanya padahal sebenarnya belum.

Cara mengatasinya adalah dengan membuat halaman setelah pemfilteran, bukan sebelumnya. Jumlah totalnya sekarang mencerminkan entitas yang terlihat. Ini kedengarannya kecil tetapi penting untuk alur kerja agen apa pun yang menelusuri hasil, yang sebagian besar terjadi setelah Anda memiliki lebih dari beberapa lusin entitas jenis apa pun.

## Penggabungan basis data menjadi alat yang nyata

Saya [menulis tentang kehilangan dan memulihkan 6.000 kenangan](/posts/how-i-lost-and-recovered-6000-memories) pada bulan Maret. Pengalaman tersebut memotivasi pengiriman `storage merge-db` sebagai perintah CLI yang tepat di v0.3.11.

Perintah ini menggabungkan dua database SQLite dengan penanganan konflik eksplisit. Tiga mode: `aman` (default, gagal pada konflik apa pun), `keep-target` (target menang jika terjadi tabrakan), `keep-source` (sumber menang). Mode uji coba mempratinjau apa yang akan dimasukkan dan apa yang akan bertentangan sebelum Anda berkomitmen. Setelah penggabungan, perintah menghitung ulang snapshot entitas dari log observasi sehingga status turunan tetap benar.

Ini bukan hanya alat pemulihan. Ini menangani penggabungan data dari beberapa instance Neotoma, migrasi antar mesin, dan menggabungkan database pengembangan dan produksi. Arsitektur berbasis observasi membuat semua operasi ini aman karena observasi tidak dapat diubah dan status entitas bersifat deterministik dengan kumpulan observasi yang sama.

## Dukungan multi-alat diperluas

Rilis pengembang mendukung Cursor, Claude, dan ChatGPT melalui MCP. v0.3.11 menambahkan dokumentasi integrasi ChatGPT eksplisit dan mengirimkan `openapi_actions.yaml`, sebuah permukaan berbentuk OpenAPI untuk alur kerja GPT Kustom dan Tindakan HTTP. Ini berarti ChatGPT dapat menggunakan Neotoma tidak hanya melalui MCP tetapi juga melalui antarmuka tindakan asli yang digunakan GPT Kustom.

Kontrak OpenAPI sendiri telah diperbarui pada v0.3.11 dan v0.4.0 untuk mencerminkan perubahan pada lapisan tindakan. Jika Anda menggunakan Neotoma secara terprogram melalui API, rilis ini memerlukan pemeriksaan ulang setiap klien yang dihasilkan.

## Jalur ekstraksi lama dihapus

v0.4.0 menghapus jalur kode `llm_extraction`. Ini adalah pendekatan lama yang menggunakan model bahasa di jalur penyimpanan. Prinsip desain Neotoma adalah tidak ada LLM yang berada di jalur kritis untuk penyimpanan atau pengambilan. Ekstraksi terjadi pada lapisan agen, bukan di dalam Neotoma. Menghapus jalur lama akan menyelaraskan basis kode dengan prinsip tersebut dan menyederhanakan internal.

Ini adalah jenis perubahan yang tidak terlihat oleh pengguna namun penting bagi arah proyek. Neotoma adalah lapisan kebenaran, bukan lapisan inferensi. Jalur ekstraksi mengaburkan garis itu. Sekarang tidak.

## Apa yang diajarkan langkah ini kepada saya

Pengiriman sebelas rilis dalam lima minggu tidak direncanakan. Setiap rilis merespons sesuatu yang spesifik: laporan bug, pengalaman pertama kali yang membingungkan, alur kerja yang terhenti dalam produksi, inkonsistensi arsitektur yang tidak dapat saya abaikan.

Pola yang muncul adalah: penggunaan sehari-hari memunculkan masalah, umpan balik evaluator mengonfirmasi prioritas, dan rilis kecil memperbaikinya sebelum masalah tersebut bertambah parah. Alternatifnya, mengelompokkan perubahan ke dalam rilis besar, akan membuat pengguna sebenarnya terjebak pada perilaku yang rusak selama berminggu-minggu.

Rilis pengembang diposisikan sebagai "sengaja kasar". Itu jujur. Apa yang saya anggap remeh adalah berapa banyak sisi kasar yang spesifik untuk pengaturan saya sendiri. Resolusi jalur, deteksi lingkungan, keamanan stdio, konsistensi penomoran halaman: tidak ada satupun yang menjadi masalah bagi saya karena saya menjalankan dari sumber, di terminal saya, dengan data saya. Semuanya merupakan masalah bagi seseorang yang menginstal melalui npm untuk pertama kalinya.

Fase selanjutnya berbeda. Lima minggu pertama menjawab "apakah ini berhasil untuk seseorang yang bukan saya." Bagian berikutnya menjawab "mengapa seseorang beralih dari apa yang sudah mereka bangun."

Setidaknya sepuluh orang di [grup evaluator](/posts/customer-research-through-agents) saya sedang membangun memori agen mereka sendiri. File penurunan harga, SQLite, detak jantung JSON, CRM file datar. Masalah yang sama, implementasi yang berbeda. Beberapa dari mereka menyebutkan pemicu pasti kapan solusi mereka akan gagal: penulisan bersamaan dari beberapa agen, pertanyaan asal yang tidak dapat mereka jawab, melewati beberapa lusin entitas aktif. Pemicu tersebut adalah peta jalan saya.

Sasaran konkrit berikutnya datang dari apa yang diminta oleh evaluator, bukan dari daftar keinginan fitur.

- **Orientasi sepele dengan imbalan langsung.** CLI kini berfungsi di komputer lain, namun "berfungsi" tidak sama dengan "lima menit untuk menilai". Seorang evaluator menghabiskan waktu satu jam untuk membaca dokumen sebelum menyiapkan VM. Itu perlu waktu lima menit, dan hal pertama yang terjadi setelah instalasi tidak boleh berupa database kosong. Orientasi berbasis agen akan memindai file lokal Anda, mengisi Neotoma dengan catatan nyata, dan memunculkan garis waktu atau wawasan yang belum pernah Anda miliki sebelumnya. Momen aha bukanlah "sudah terpasang". Momen aha adalah "ia sudah mengetahui sesuatu yang berguna tentang data saya."
- **Kisah hidup berdampingan yang jelas.** Beberapa evaluator bertanya apakah Neotoma harus hidup berdampingan dengan memori otomatis Claude atau memori internal ChatGPT, atau menggantikannya. Jawabannya ada di samping, dan produk perlu memperjelasnya.
- **Kedalaman dalam domain yang asal usulnya tidak dapat dinegosiasikan.** Layanan kesehatan, kepatuhan, audit keuangan: evaluator di bidang tersebut mengatakan bahwa bahasa yang digunakan sudah sesuai. Pekerjaan ini adalah membuat skema dan menjamin konkritnya vertikal tersebut.

Karya arsitektur yang lebih dalam berasal dari penggunaan saya sehari-hari, bukan permintaan evaluator. Menjalankan Neotoma sebagai lapisan memori utama saya selama berbulan-bulan memunculkan masalah struktural yang belum disadari oleh siapa pun di luar.

- **Konvergensi terbatas.** Agen bersifat stokastik. Pesan pengguna yang sama dapat menghasilkan tipe entitas, nama bidang, dan struktur hubungan yang berbeda bergantung pada mood model. Contoh saya memiliki 170 tipe entitas, dan beberapa di antaranya adalah drift, bukan ontologi sebenarnya. Rilis berikutnya menambahkan normalisasi waktu tulis: pemetaan alias sehingga `pembelian` dan `transaksi` diselesaikan ke jenis kanonik yang sama, pencocokan bidang fuzzy sehingga `jumlah` dan `jumlah_eur` tidak membuat fork skema, dan penyimpanan ditambah pengambilan sehingga sistem memeriksa duplikat sebelum agen membuatnya.
- **Tata kelola skema.** Saat ini agen mana pun dapat membuat jenis entitas baru di penyimpanan pertama. Kebebasan ini berguna pada tahap awal, namun menimbulkan masalah pembersihan dalam skala besar. Lapisan tata kelola terencana menambahkan pendaftaran alias, siklus hidup penghentian, dan peringatan diagnostik ketika penyimpanan menyimpang dari skema kanonik. Sistem tetap permisif saat menulis tetapi memberikan umpan balik sebagai respons sehingga agen mengoreksi dirinya sendiri.
- **Penegakan progresif.** Skema saat ini disimpulkan sekali dan tidak pernah diperketat. Langkah selanjutnya adalah pelacakan keyakinan: setelah observasi yang cukup terhadap suatu tipe, skema mengkristal dan sistem dapat memperingatkan jika ada bidang umum yang hilang, ketidakcocokan tipe, dan pola hubungan yang rusak. Bukan memblokir toko, hanya memunculkan apa yang tampaknya salah. Mode ketat menjadi pilihan untuk tipe berisiko tinggi seperti catatan keuangan di mana varian ekstraksi penting.

Neotoma adalah [sumber terbuka di GitHub](https://github.com/markmhendrickson/neotoma). Jika Anda mencoba rilis pengembang dan mengalami kesulitan, banyak di antaranya telah diatasi dalam rilis ini. Jika Anda belum mencobanya, titik awal terbaik adalah [meminta agen Anda mengevaluasi apakah Neotoma cocok dengan alur kerja Anda](https://neotoma.io/evaluate). Agen membaca halaman tersebut, memeriksa pengaturan Anda, dan memberi tahu Anda dengan jujur ​​apakah pengaturan tersebut sesuai sebelum Anda menginstal apa pun.