Pusat komando agen memerlukan satu sumber kebenaran

[Pawel Jozefiak baru-baru ini menulis tentang menjalankan agen AI pribadi](https:// Thoughts.jock.pl/p/wiz-1-5-ai-agent-dashboard-native-app-2026) dan peralatan yang ia buat untuk mengelolanya. Dia berpindah dari Notion ke Obsidian ke papan khusus yang didukung SQLite, lalu ke aplikasi SwiftUI asli dengan mode fokus dan visibilitas bilah menu.

Bug kritis yang dia temui adalah tugas yang dijalankan ulang karena penyelesaiannya tidak dicatat dengan andal. Dia berakhir dengan sistem memori enam lapis (memori kerja, rollover mingguan, indeks permanen, profil mendalam, pencarian semantik, jalur pengembangan diri) dan kesimpulan yang jelas. Ada kesenjangan antara alat tugas umum dan IDE agen lengkap. Yang hilang adalah "Pusat Komando" untuk siklus hidup agen: mengklaim, mengeksekusi, meninjau, mengulangi, dengan visibilitas waktu nyata.

Saya sedang membangun Neotoma, lapisan kebenaran untuk memori agen. Itu tidak membangun dasbor atau agen. Ini menyediakan lapisan yang akan digunakan oleh pusat komando.

Kesenjangan yang dia gambarkan

Pilihan Jozefiak terlalu umum (Trello, Linear) atau terlalu teknis (terminal, JSON). Dewan generik tidak tahu tentang status agen. Siapa yang mengklaim apa? Apakah agen bekerja atau menunggu peninjauan? Bagaimana penyelesaian dicatat sehingga agen tidak menjalankan tugas yang sama dua kali? Log mentah dan JSON tidak memberi Anda papan sama sekali.

Dia membutuhkan sesuatu di antaranya: satu tempat di mana agen dan manusia berbagi tugas, dengan semantik yang jelas untuk klaim, kelengkapan, dan status, dan cukup cepat sehingga jajak pendapat atau pembaruan waktu nyata tidak gagal. "Satu tempat" itu adalah masalah data. Pusat komandonya adalah UI. Hal yang dibaca dan ditulisnya adalah media.

Apa yang disediakan oleh lapisan kebenaran

Neotoma menyimpan entitas, pengamatan, dan hubungan yang diketik. Ini mengekspos mereka melalui MCP sehingga agen mana pun (Kode Claude, Kursor, pelari terjadwal) dapat menyimpan dan memperbaiki status. ID idempotensi dan deterministik sudah ada di dalamnya.

Ketika agen mengklaim suatu tugas, ia menyimpan atau memperbaiki entitas dengan status "sedang berlangsung". Jika sudah selesai, koreksi lagi dengan status “selesai”. Kunci idempotensi yang sama, hasil yang sama setiap saat. Bug yang dialami Jozefiak (penyelesaian tidak dicatat, tugas dijalankan kembali) adalah hal yang ingin dicegah oleh penulisan idempoten dan tahan lama.

Dasbor atau aplikasi asli yang ingin menampilkan "apa yang dilakukan agen" akan menanyakan toko yang sama: mencantumkan entitas berdasarkan jenis (misalnya tugas), memfilter berdasarkan status, menampilkan penerima tugas, dan stempel waktu. Agen dan dasbor berbagi satu sumber kebenaran. Tidak ada SQLite khusus, tidak ada lapisan sinkronisasi yang dapat melayang. Dasbornya menghadap Neotoma.

Di mana memori enam lapis cocok

Enam lapisan Jozefiak (memori kerja, rollover mingguan, indeks permanen, profil mendalam, pencarian semantik, pengembangan diri) adalah masalah lapisan strategi dan lapisan aplikasi. Mereka memutuskan apa yang harus dipertahankan, apa yang harus dikompres, apa yang harus diringkas, dan apa yang harus dimasukkan kembali ke dalam perilaku agen.

Neotoma tidak melakukan pemadatan atau peringkasan. Ini adalah penyimpanan yang tahan lama dan terstruktur tempat lapisan-lapisan tersebut membaca dan menulis. Memori kerja mungkin berupa "N observasi terakhir" atau "entitas yang disentuh dalam 48 jam terakhir". Rollover mingguan mungkin menulis observasi baru (ringkasan, indeks) kembali ke Neotoma. Penelusuran semantik mungkin dijalankan pada grafik entitas yang sama. Batasannya jelas: Neotoma adalah lapisan kebenaran; lapisan di atasnya menerapkan kebijakan penyimpanan dan strategi pengambilan.

Mengapa hal ini penting bagi pembangun

Jika Anda sedang membangun agen pribadi dan memerlukan status tugas, pelacakan status, dan visibilitas, Anda memiliki dua jalur. Anda dapat menggabungkan penyimpanan Anda sendiri (SQLite, file, API khusus) dan kemudian membuat papan atau dasbor di atasnya. Anda sendiri akan menemukan semantik penyelesaian, idempotensi, dan konsistensi lintas sesi. Atau Anda dapat menggunakan media yang sudah memberi Anda entitas, pengamatan, asal, dan akses MCP. Pusat komando menjadi klien media tersebut. Agen adalah klien lain. Keduanya membaca dan menulis keadaan yang sama.

Saya tidak sedang membangun pusat komando. Saya sedang membangun lapisan tempat ia akan diletakkan. Neotoma adalah bidang data untuk dasbor agen dan perkakas siklus hidup. Jika celah yang dijelaskan Jozefiak diisi oleh produk (gaya WizBoard atau lainnya), produk tersebut akan memerlukan backend. Lapisan kebenaran adalah backend itu.

Bagaimana hal ini sesuai dengan tren yang saya pertaruhkan

Dalam enam tren agen yang saya tulis baru-baru ini, saya berpendapat bahwa agen akan menjadi pelaku ekonomi negara, kesalahan akan terlihat secara ekonomi, fragmentasi alat akan terus berlanjut, dan penggunaan akan diukur. Kesenjangan pusat komando yang dialami Jozefiak berada di persimpangan tekanan-tekanan tersebut.

Ketika agen bersifat stateful dan berjalan lama, Anda perlu melihat apa yang mereka lakukan. Tren 1: "Antarmuka produk memperlihatkan riwayat agen sebagai sesuatu yang dapat diperiksa dan bukan bersifat sementara" adalah apa yang dimaksud dengan pusat komando. Ketika kesalahan membutuhkan uang atau reputasi, Anda perlu mengetahui apa yang diketahui agen pada saat itu. Tren 2: ketertelusuran dan “apa yang diketahui agen?” menjadikan satu sumber kebenaran untuk tugas dan status sebagai hal yang perlu, bukan hal yang baik untuk dimiliki.

Saat Anda menggunakan beberapa alat dan model, nyatakan fragmennya. Tren 5: pusat komando dan agen perlu membaca dan menulis keadaan yang sama, itulah sebabnya media harus berada di bawah UI. Ketika penggunaan diberi harga, menjalankan kembali tugas yang sama karena penyelesaian tidak dicatat adalah pemborosan yang terlihat. Tren 6: penyelesaian yang idempoten dan tahan lama merupakan optimasi sekaligus jaminan kebenaran.

Saya melakukan dogfood Neotoma dalam alur kerja agen saya sendiri dan mendokumentasikan pola "siklus hidup tugas agen": menyimpan entitas tugas, menggunakan pengamatan untuk status dan riwayat, memperbarui melalui MCP dengan benar dengan kunci idempotensi sehingga penyelesaiannya tidak ambigu. Pola itulah yang akan mendukung tampilan pusat perintah (klaim, jalankan, tinjau, ulangi) tanpa setiap pembuat menciptakan kembali logika SQLite dan sinkronisasi mereka sendiri. Saya juga menambahkan "dasbor agen / backend pusat perintah" pada cara saya mendeskripsikan Neotoma sehingga orang lain yang ingin membuat alat semacam itu mengetahui bahwa ada substrat yang dapat mereka gunakan untuk membangun.