Pengguna menempelkan perintah evaluasi yang dipimpin agen ke editor mereka. Agen membaca [halaman evaluasi Neotoma](https://neotoma.io/evaluate), memindai alur kerja lokal, memutuskan kecocokan yang kuat, menjalankan instalasi, dan menyimpan beberapa entitas pertama. Beberapa waktu kemudian, ia menemukan bug yang sebenarnya - pengiriman entitas secara diam-diam menghapus bidang yang diterima dengan jelas oleh skema. Beberapa saat kemudian ia memperhatikan hal lain: pengambilan grafik entitas besar lebih lambat dari yang seharusnya untuk alur kerja yang didukungnya. Dan kemudian, saat membuat loop pengambilan khusus, ia menyadari bahwa permukaan MCP tidak memiliki operasi batch yang akan membuat pola yang terus diulang menjadi jauh lebih bersih. Pengguna tidak pernah bertanya tentang semua ini. Agen menyadarinya saat melakukan sesuatu yang lain. Bentuk lama dari momen-momen itu adalah akhir dari perulangan. Pengguna dapat membuka GitHub, menempelkan kesalahan atau permintaan, menulis paragraf konteks, dan menunggu. Kebanyakan tidak. Mereka mengatasi masalah, pengelola tidak pernah melihatnya, dan pengguna berikutnya menemui hambatan yang sama. Neotoma kini memiliki subsistem isu kelas satu yang beroperasi melalui permukaan MCP yang sama yang sudah digunakan setiap agen untuk menyimpan dan mengambil. Agen mengajukan bug, pengamatan kinerja, dan permintaan peningkatan tanpa meninggalkan sesi, dan tanpa berhenti untuk menanyakan per masalah. Agen pengelola mengambilnya, melakukan triase, sering menyelesaikannya, dan mengirimkannya. Agen pelapor membaca kembali statusnya dan memberi tahu pengguna ketika ada sesuatu yang mendarat. Seluruh pertukaran terjadi melalui panggilan alat. Evaluasi yang dipimpin oleh agen yang ditulis di [postingan riset pelanggan](/posts/customer-research-through-agents) adalah bagian depan dari putaran ini. Subsistem permasalahannya adalah bagian belakang. Kedua bagian berjalan pada [substrat sistem saraf](/posts/from-memory-to-nervous-system) yang saya jelaskan sebelumnya, dan kemampuan isu adalah contoh terbersih dari kegunaan substrat tersebut. ## Mengapa loop harus ditutup di sisi agen Gesekan adalah pembunuh diam-diam dari umpan balik. Model lama mengasumsikan pengguna akan menerjemahkan pengalaman mereka ke dalam laporan pada sistem terpisah: mengganti konteks, menemukan repo, mengurai templat masalah, menulis latar belakang yang cukup sehingga pengelola dapat bertindak, melampirkan log, menunggu. Setiap langkah adalah kesempatan untuk menyerah. Kebanyakan melakukannya. Dan model itu hanya mencakup masalah yang diketahui pengguna. Ia tidak memiliki jalur sama sekali untuk masalah yang diketahui agen yang tidak pernah muncul oleh pengguna. Agen salah satu evaluator mengidentifikasi bahwa aktivasi menghasilkan kesalahan hidrasi ketika konfigurasi media mereka menunjuk ke instance yang dihosting sendiri di belakang terowongan Cloudflare. Agen tersebut menulis ringkasan yang tepat, termasuk titik akhir yang gagal dan header respons. Pengguna meneruskan ringkasannya kepada saya sebagai pesan. Saya membangun kembali konteksnya, mengarahkannya ke agen saya, mengirimkan rilis, dan mengirim pesan kembali kepada pengguna. Pengguna meminta agen mereka untuk memverifikasi. Verifikasi itu memakan waktu sekitar sembilan puluh detik. Langkah estafet manusia memakan waktu berhari-hari. Ringkasan asli agen itu bagus. Konteks pembangunan kembali lah yang memakan waktu. Setiap penyerahan antara agen dan manusia kehilangan kesetiaan. Setiap penyerahan antara manusia dan agen lain membangun kembali konteks dari awal. Detail kaya yang ditulis oleh agen dikompres menjadi prosa singkat yang ditulis oleh manusia, dan kemudian agen hilir harus mengembangkannya kembali. Ketika agen pengguna adalah pihak yang menemui hambatan — atau menyadari kelambatan, atau menginginkan kemampuan yang hilang — langkah penerjemahannya gratis. Agen sudah mengetahui konteksnya: alat mana yang menjalankannya, panggilan MCP sebenarnya yang gagal atau terasa janggal, payload respons, git SHA atau versi aplikasi dari instalasi Neotoma, jenis entitas yang terlibat. Ini menyusun laporan yang koheren dalam satu panggilan alat. Instruksi MCP memberi tahu agen untuk mengajukan melalui `submit_issue` segera ketika masalah yang dapat dilaporkan atau peluang perbaikan dikonfirmasi, tanpa berhenti untuk menanyakan per masalah — perintah per masalah tidak menambahkan informasi baru dan mengganggu apa pun yang sedang dilakukan pengguna. File agen. Pengguna akan mengetahuinya nanti, atau tidak sama sekali, bergantung pada apakah perubahan tersebut dikirimkan atau tidak. Di sisi pengelola, loop harus ditutup tanpa saya membaca setiap laporan secara manual. Saya menjalankan sekitar selusin agen di seluruh editor dan daemon. Mereka sudah memproses keadaan terstruktur yang masuk. Bentuk alaminya adalah: masalah baru muncul, sinyal substrat saat ditulis, daemon triase mengambil peristiwa tersebut, membaca masalah tersebut, memutuskan apakah masalah tersebut dapat bertindak, membuka pohon kerja, menjalankan sesi agen terhadap basis kode, dan menyelesaikan bug atau meminta klarifikasi dari pelapor melalui thread yang sama. Kedua bagian loop dijalankan sebagai agen yang bekerja pada substrat yang sama. Agen pengguna menggunakan MCP untuk mengirimkan. Agen pengelola menggunakan MCP untuk membaca dan merespons. Tidak ada yang perlu membuka browser. ## Apa yang dilakukan agen saat penyerahan Permukaan MCP cukup kecil untuk dihitung. Alat `submit_issue` mengambil judul, isi, jenis entitas jika masalahnya adalah tentang jenis catatan tertentu, dan blok lingkungan pelapor — git SHA yang dijalankan pengguna atau versi aplikasi, dengan versi aplikasi yang terakhir terisi secara otomatis di sisi server ketika agen menghilangkan keduanya. Lingkungan reporter memiliki pengaruh lebih dari yang terlihat; bagian selanjutnya mengungkap alasannya. Laporan jarang datang tanpa konteks. Bug mereferensikan entitas konkret: catatan spesifik yang gagal disimpan, skemanya, observasi upstream. Permintaan peningkatan merujuk pada pola panggilan yang akan disederhanakan, atau jenis entitas yang akan diambil lebih cepat. `submit_issue` dan `add_issue_message` menerima array `entity_ids_to_link`, dan server membuat hubungan `REFERS_TO` dari terbitan baru ke setiap entitas yang direferensikan secara atom sebagai bagian dari panggilan yang sama. Masalahnya sudah dimasukkan ke dalam grafik yang dibahas. Agen triase yang membaca masalah dapat langsung menuju ke entitas yang gagal. Pengajuan mengalir melalui penjaga PII `scanAndRedact` yang sama yang melindungi setiap permukaan publik. Jika agen secara tidak sengaja menempelkan token atau alamat email ke dalam isi, token atau alamat email tersebut akan disunting sebelum persisten. Instruksi MCP mengharuskan agen untuk menerapkan daftar periksa PII ke judul dan isi sebelum panggilan, namun penjaga sisi server adalah garis pertahanan sebenarnya. Pelapor mendapatkan pengidentifikasi masalah numerik dan token baca kembali tamu dengan TTL eksplisit, yang dicakup ke thread yang baru saja mereka buka. Token tersebut adalah cara agen pelapor membaca statusnya nanti tanpa mengautentikasi ulang setiap saat. Dari sudut pandang pengguna: satu panggilan alat, satu pengidentifikasi untuk dilacak, dan biasanya tidak ada permintaan persetujuan sama sekali. Dari perspektif substrat: entitas terstruktur ditulis, hubungan entitas tertaut dibuat dalam transaksi yang sama, baris sumber dibuat, hibah tamu dikeluarkan, dan alur tulis mengeluarkan peristiwa. ## Asalnya adalah pahlawan tanpa tanda jasa Persyaratan lingkungan reporter tampak seperti detail kecil. Ini adalah perubahan yang paling penting. Sebelum subsistem masalah ada, laporan dapat diserahkan tanpa mengacu pada build yang menjadi dasar pembuatannya. Tidak apa-apa untuk tiket kertas. Ini merupakan bencana besar bagi perulangan triase otomatis. Jika agen mengirimkan bug di commit `abc1234` dan agen saya memperbaikinya di commit `def5678`, agen pengguna harus mengetahui build mana yang akan diverifikasi. Jika thread debugging mencakup tiga build, setiap komentar harus mencatat build mana yang mengujinya. Hal yang sama berlaku untuk permintaan peningkatan: mengetahui versi mana yang dijalankan agen ketika mengidentifikasi operasi batch yang hilang memberi tahu saya apakah celah tersebut telah diatasi di build berikutnya atau benar-benar terbuka. Tanpa asal usul, benang tersebut menjadi arkeologi. `submit_issue` menolak kiriman apa pun yang tidak memiliki `reporter_git_sha` dan `reporter_app_version`. Amplop penolakan mencantumkan alternatif secara eksplisit: ``` json { "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED", "detail": { "grup_bidang_yang dapat diterima": [ ["reporter_git_sha"], ["reporter_app_version"] ] } } ``` `add_issue_message` menerima kolom yang sama dan mengeluarkan peringatan server pada thread publik ketika keduanya tidak ada. Setiap pesan yang ditulis oleh agen debugging mencatat build yang sedang diuji. Alasan mengapa hal ini penting dalam penanganan agen-ke-agen adalah karena hal ini memungkinkan pihak penerima mengklasifikasikan laporan sebelum melakukan pekerjaan apa pun. Untuk bug: apakah pengguna menjalankan rilis yang dipublikasikan? Cabang dari `main` dan buka PR. Komitmen khusus pada cabang fitur? Buat pohon kerja yang melakukan, mereproduksi, dan melaporkan temuan tanpa mengubah jalur utama. Garpu mereka sendiri? Posting tindak lanjut terstruktur yang menanyakan sumber patch. Untuk peningkatan: apakah kemampuan yang diminta sudah ada di cabang, atau benar-benar hilang? Apakah ini bertentangan dengan batasan desain yang tidak dapat dilihat oleh agen yang mengajukannya? Klasifikasi menentukan respons – dan tidak ada yang mungkin terjadi tanpa asal usulnya. Asalnya adalah hal yang mengubah laporan bentuk bebas menjadi peristiwa yang dapat dirutekan, baik laporan tersebut menggambarkan sesuatu yang rusak atau sesuatu yang hilang. ## Apa yang terjadi di sisi pengelola Daemon triase saya berlangganan peristiwa pembuatan masalah melalui alat `berlangganan` yang sama yang akan digunakan konsumen lain. Webhook menjadi prioritas utama karena berfungsi untuk daemon jarak jauh di VPS serta proses lokal di laptop saya; SSE bersifat aditif. Substrat memelihara registri, mengirimkan acara, dan melupakannya. Daemon memutuskan. Daemon yang saya jalankan untuk ini disebut Formica. Genus _Formica_, semut. Setiap subagen adalah seorang pekerja yang membawa satu bagian pekerjaan dari log peristiwa ke suatu perbaikan. Apa fungsinya, dalam praktiknya: baca terbitan tersebut. Tarik entitas yang ditautkan oleh agen pelapor pada waktu pengiriman, karena hubungannya sudah ada dalam grafik. Cerminkan ke repo GitHub upstream jika memerlukan jejak publik, dengan redaksi PII diterapkan pada batas API dan masalah apa pun yang judul atau isi masih cocok dengan pola redaksi ditolak sebelum melewati batas. Klasifikasikan apakah laporan tersebut merupakan bug atau peningkatan. Untuk bug: putuskan apakah bug dapat direproduksi dari lingkungan reporter saja, lalu serahkan ke keterampilan `/proses-masalah` yang membuka pohon kerja, menjalankan sesi agen, dan mencoba memperbaikinya. Untuk penyempurnaan: sintesiskan entitas rencana yang menggabungkan permintaan dengan masalah terbuka terkait, dan menampilkannya untuk ditinjau oleh manusia daripada mencoba implementasi mandiri. Jika diperlukan lebih banyak konteks untuk kedua jenis tersebut, kirimkan pertanyaan klarifikasi melalui `add_issue_message` sehingga agen pelapor menerimanya pada status pembacaan berikutnya. Keterampilan `/proses-masalah` mendorong perbaikan yang sebenarnya. Kontraknya pendek. Untuk setiap terbitan terbuka: - Muat snapshot, thread percakapan, dan lingkungan reporter. - Klasifikasikan lingkungan reproduksi sebagai `public_release`, `local_commit`, `local_branch`, atau `unknown`. - Jika tidak diketahui atau bertentangan, hubungi `add_issue_message` dengan permintaan terstruktur untuk detail yang hilang dan tandai rencana `awaiting_input`. - Jika tidak, sintesiskan entitas `rencana` yang ditautkan ke masalah sumber dan baris pesan percakapan yang relevan. - Jika denah tersebut menyentuh skema, keamanan, dokumen pondasi, atau batas arsitektur yang ambigu, berhentilah dan tanyakan. Jangan mengeksekusi. - Jika eksekusi aman dan diperbolehkan dengan mode pelaporan: cabang dari `main` untuk reproduksi rilis publik dan buka PR, atau buat pohon kerja git terpisah untuk reproduksi lokal dan laporkan jalurnya. Subagen menyebar dengan batas konkurensi sebanyak empat, satu terbitan per subagen. Keahlian ini menghormati `reporting_mode`: `off` hanya menghasilkan dan menyimpan rencana, `persetujuan` bertanya sebelum mengeksekusi, `proaktif` mengeksekusi rencana aman secara mandiri. Jangan pernah menekan ke `utama`. Jangan pernah menggunakan `--no-verify`. Jangan pernah mengubah komitmen yang didorong. Penjaga kebocoran redaksi berjalan sebelum artefak publik apa pun dibuat dari masalah pribadi. Default aman tetap aktif: - `dry_run: true` untuk pertama kali menjalankan jenis masalah baru apa pun, jadi saya melihat apa yang akan terjadi sebelum ada yang ditulis. - `auto_fix: false` jadi tidak ada yang mendorong atau membuka PR sampai saya konfirmasi melalui operator transport. - `max_prs_per_hour: 5` sehingga banjir masalah terkait tidak bisa meluas ke banjir cabang. - `dirty_tree_policy: abort` sehingga pembayaran basi tidak pernah digunakan sebagai basis. - Tombol pemutus melalui entitas `daemon_config` di Neotoma dengan `aktif: false`, sehingga saya dapat menghentikan sementara semua pemrosesan dari satu penulisan Neotoma tanpa menyentuh mesin host. Bagian transportasi operator patut mendapat perhatian. Formica mendukung backend Telegram yang memunculkan perintah `human_needed` dan perintah `/shipit` untuk melanjutkan ketika `auto_fix` tidak aktif. Pesan Telegram yang diizinkan dicerminkan ke Neotoma sebagai baris `conversation_message`, sehingga sisi manusia saya yang bolak-balik dengan daemon ditangkap dalam substrat yang sama. Jejak audit bersifat ujung ke ujung. Jalur `add_issue_message` adalah jalur yang mengejutkan saya ketika saya mulai menggunakannya. Ini bukan sistem komentar. Ini adalah saluran pesan terstruktur antara pelapor masalah dan pihak pengelola, yang dirangkai melalui percakapan primitif yang sama yang sudah ada untuk rangkaian agen-ke-agen. Agen pelapor dapat menjawab pertanyaan klarifikasi tanpa manusia harus membacanya di sela-sela pertanyaan tersebut. Thread publik membawa redaksi PII yang sama, dan kasus keberhasilan parsial (GitHub mirror diterima, penambahan lokal gagal, atau sebaliknya) muncul sebagai kesalahan terstruktur pada respons daripada menghasilkan komentar duplikat secara diam-diam. Ketika perbaikan terjadi, daemon yang sama yang melakukan triase laporan akan menutup masalah, atau menutup beberapa masalah secara massal sekaligus jika satu PR menyelesaikan sebuah klaster. ## Apa yang dilakukan agen pelapor saat membaca kembali Sisi lain dari loop adalah pembacaan. Agen pelapor memanggil `get_issue_status` dengan nomor penerbitan atau ID entitas. Ia menerima status saat ini, pesan di thread, resolusi jika ada, dan link ke mirror upstream jika pihak pengelola memilih untuk mengeskalasinya. Token tamu mengautentikasi pembacaan tanpa pengguna harus masuk ke apa pun. Jika token telah kedaluwarsa, media akan mengembalikan 401 yang bersih alih-alih menurunkan versi secara diam-diam ke akses anonim. Agen memutuskan apakah akan menampilkan status kepada pengguna. Jika tidak ada yang berubah sejak pemeriksaan terakhir, maka tetap tenang. Jika pertanyaan klarifikasi tiba, ia menanyakan kepada pengguna. Jika perbaikan dikirimkan, ia memberitahu pengguna, secara opsional menarik versi baru, dan menawarkan untuk menjalankan kembali apa pun yang rusak pertama kali. Model baca saat ini untuk sisi reporter adalah pull — agen memeriksa jika ada alasan untuk melakukan hal tersebut — namun push tersedia saat ini melalui alat langganan yang sama dengan yang digunakan daemon pengelola. Langganan dapat dicakup ke ID entitas tertentu, sehingga agen pelapor dapat mendaftarkan minat pada masalah yang baru saja diajukannya dan menerima peristiwa `entity.updated` dan `observation.created` seiring perkembangan thread. Yang hilang adalah lem ergonomisnya: instruksi MCP belum memberitahu agen untuk berlangganan otomatis setelah `submit_issue` kembali. Sampai mereka melakukan hal tersebut, sisi reporter tetap menggunakan sistem pull-by-default; agen pengelola sudah aktif pada peristiwa media. Sepenuhnya reaktif pada kedua bagian hanya membutuhkan satu perubahan instruksi. ## Mengapa sistem saraf ini beraksi Media mengeluarkan peristiwa setelah setiap penulisan. Itulah satu-satunya hal yang harus dilakukan media agar semua ini berfungsi. Segala sesuatu yang lain adalah logika lapisan operasional yang berjalan di atas: daemon triase, cermin GitHub, pembacaan kembali tamu, dedup lintas-thread, redaksi PII. Ini adalah baris yang saya [perdebatkan dalam postingan sistem saraf](/posts/from-memory-to-nervous-system) dan ini berlaku dalam kasus penggunaan masalah. Substrat tidak memutuskan masalah mana yang penting, tidak mencoba ulang pengiriman dengan eskalasi, tidak mengikuti peristiwanya sendiri. Ini memberi sinyal. Daemon triase adalah konsumen, agen pelapor adalah konsumen, mirror GitHub adalah konsumen. Setiap konsumen mendaftarkan minatnya, memutuskan apa yang harus dilakukan, dan bertindak. Jika saya ingin menambahkan daemon triase kedua yang menangani laporan keamanan secara berbeda, daemon tersebut berlangganan peristiwa yang sama dengan filter berbeda. Tidak ada perilaku media baru. Kerangka biologis berlaku. Substratnya adalah otak ditambah saraf sensorik: ia menyimpan masalah, mengirimkan sinyal bahwa suatu masalah telah tiba. Daemon triase dan agen pelapor adalah sistem motorik: mereka memutuskan apa yang harus dilakukan terhadap sinyal. Versi Neotoma yang mencoba menjadi ketiganya akan lebih sulit untuk dipikirkan dan diperluas. Versi yang berhenti pada sinyal tetap netral. ## Mewarisi perulangan Bentuk yang saya jelaskan dibuat berdasarkan masalah Neotoma sendiri, tetapi medianya tidak peduli. Apa pun yang dibangun di atasnya mewarisi sebagian besar mesin yang sama. Sisi umum penyerahan sudah ada. `submit_entity` menerima laporan terhadap jenis entitas arbitrer ketika operator telah menyemai baris `submission_config` yang mengotorisasinya. Pemberian token tamu yang sama, rangkaian percakapan yang sama, saluran tindak lanjut `add_entity_message` yang sama berlaku. `subscribe` menerima tipe entitas apa pun sebagai filter, sehingga operator pihak ketiga dapat menjalankan daemon triase mereka sendiri dengan mendaftarkan minat pada tipe kustom mereka dan bereaksi terhadap peristiwa `entity.created` dan `entity.updated` persis seperti reaksi Formica terhadap masalah. Artinya dalam praktiknya: jika Anda menjalankan alur konten, layanan rekonsiliasi, atau produk apa pun yang penggunanya menjalankan agen, Anda dapat membiarkan agen tersebut mengajukan laporan terstruktur terhadap entitas yang Anda miliki — alur yang gagal dijalankan, catatan yang salah diklasifikasikan, permintaan rekonsiliasi — dan mengambilnya di pihak Anda melalui mekanisme langganan yang sama. Kawatnya umum. Beberapa bagian tetap spesifik untuk masalah Neotoma saat ini. Penjaga redaksi PII saat ini terikat pada jalur `submit_issue`, bukan jalur `submit_entity` yang umum. Pencerminan GitHub bersifat khusus untuk masalah tertentu. Keduanya merupakan tambahan lapisan operasional yang akan ditransfer sendiri oleh operator pihak ketiga. Substrat menangani bagian-bagian yang harus seragam — penegakan asal, pembuatan hubungan atom, akses tamu yang tercakup dalam thread, emisi peristiwa pada setiap penulisan. Bagian yang bergantung pada *tentang* laporan adalah tempat operator mendapatkan penghasilannya. Subsistem isu merupakan konsumen lengkap pertama dari pola yang lebih umum. Bentuk yang sama berlaku untuk sinyal terstruktur apa pun yang mungkin ingin dikirim kembali oleh agen ke sistem yang dilawannya. ## Mengapa ulasan manusia tetap ada Ada dua hal yang menggoda saya untuk mengirimkan `auto_fix: true` dan mengirimkan semua yang dihasilkan daemon. Yang pertama adalah kenyamanan. Saluran pipa hijau yang menutup masalah saat saya tidur sungguh memuaskan. Yang kedua adalah kenyataan bahwa untuk sebagian kecil masalah, rencana agen dan perbedaannya benar. Saya sudah cukup banyak menontonnya sekarang untuk mengetahui bahwa mode kegagalan biasanya bukan "perbaikan yang salah". Biasanya ini adalah "perbaikan untuk cakupan yang salah", yang dapat ditangkap oleh tinjauan kode dalam tiga puluh detik. Saya tidak akan melakukan peninjauan manual karena agen kadang-kadang merasa yakin bahwa mereka salah dalam membuat keputusan dengan konsekuensi hilir yang tidak dapat mereka lihat. Migrasi skema yang memenuhi pengujian yang gagal namun merusak integrasi yang tidak terkait. Perubahan redaksi yang memperbaiki kebocoran langsung namun melonggarkan pelindung terkait. Benjolan ketergantungan yang menyelesaikan kesalahan build dan secara diam-diam mengubah perilaku default kueri. Permintaan peningkatan semakin mempertajam hal ini. Bug memiliki kebenaran dasar - baik bidang tersebut dihilangkan atau tidak. Penyempurnaan adalah klaim desain yang memuat asumsi tentang pola penggunaan, batasan arsitektur, dan trade-off yang tidak dapat sepenuhnya dilihat oleh agen pelapor. Sinyalnya sangat berharga; ia memunculkan gesekan nyata, bukan gesekan khayalan. Namun keputusan tentang apa yang harus dilakukan terhadapnya adalah milik manusia yang dapat melihat gambaran keseluruhannya. Keputusan-keputusan yang membutuhkan manusia adalah keputusan-keputusan yang kerugian akibat kesalahannya tinggi dan kerugian akibat kelalaiannya rendah. Itu adalah penggabungannya — bukan rencana, tambalan, pengujian, atau deskripsi PR. Agen menangani segalanya. Agen mengusulkan; manusia memutuskan. ## Lingkaran agen, ujung ke ujung Baca di samping postingan riset pelanggan, bentuknya sekarang dapat terbaca. Bagian depan: agen pengguna mengevaluasi Neotoma berdasarkan alur kerja mereka yang sebenarnya dan menginstalnya jika cocok. Bagian belakang: agen mencatat bug, pengamatan kinerja, dan permintaan peningkatan saat ia menemukannya, dan pihak pengelola menyelesaikannya — sering kali sebelum pengguna mengingat semua bug tersebut telah diajukan. Kedua bagian beroperasi pada agen yang berbicara dengan agen melalui satu permukaan terstruktur. Gesekan yang secara historis mematikan putaran akuisisi dan putaran umpan balik hilang karena setiap langkah penerjemahan telah diserap ke dalam panggilan alat. Tidak ada setengahnya yang mungkin terjadi tanpa substrat di bawahnya: evaluasi yang dipimpin agen memerlukan keadaan terstruktur tentang alur kerja pengguna, dan subsistem masalah memerlukan sinyal peristiwa ditambah akses tamu melintasi batas kepercayaan. Keduanya bergantung pada primitif yang sama. ## Apa yang tidak saya bangun Godaan dalam subsistem masalah adalah beralih ke orkestrasi: model prioritas, pelacakan SLA otomatis, router "pintar" yang memutuskan daemon mana yang menangani jenis masalah apa. Masing-masing kedengarannya masuk akal jika dipisahkan. Tak satu pun dari mereka termasuk dalam substrat. Daemon triase memprioritaskan. Agen pengelola melacak waktu respons mereka sendiri. Perutean adalah filter berlangganan. Hal yang sama berlaku untuk mencoba kembali semantik. Jika pengiriman webhook gagal, media akan mencatat kegagalan tersebut dan melanjutkan. Itu tidak meningkat ke saluran cadangan, tidak melakukan buffer untuk pemutaran ulang, tidak membuat konsumen berada dalam kondisi terdegradasi. Perantara pesan melakukan semua itu dan mereka ahli dalam hal itu; substrat bukan perantara pesan. Konsumen yang menginginkan jaminan pengiriman membungkus sinyal di infrastruktur mereka sendiri. Kendalanya adalah fiturnya. Lapisan negara yang memberi sinyal masalah namun tidak memutuskan masalah mana yang penting adalah lapisan negara yang dapat dipercaya oleh konsumen untuk berperilaku sesuai prediksi. ## Apa yang saya ingin masukan Subsistem isu sedang aktif. Jika Anda telah menginstal Neotoma dan agen Anda mengalami masalah — bug, kesenjangan kinerja, hilangnya kemampuan yang diharapkan ada — Anda tidak perlu lagi memintanya untuk mengajukan masalah. Untuk mengambilnya pada instalasi yang sudah ada, tingkatkan dengan `npm install -g neotoma@latest`. Tidak ada tombol persetujuan per pengguna untuk dikonfigurasi; persetujuannya adalah pemasangan. Jika ini adalah instalasi baru, `penyiapan reporter neotoma` menelusuri konfigurasi sisi reporter satu kali sehingga masalah pertama yang akan terjadi pada file agen Anda. Jika Anda belum menginstal Neotoma, minta agen Anda untuk menjalankan halaman evaluasi. Jika dianggap cocok, Neotoma dapat diinstal dan diaktifkan tanpa Anda membaca dokumen konfigurasi. Jika disimpulkan bahwa Neotoma tidak cocok, itu juga merupakan hasil yang valid, dan lebih jujur ​​daripada yang dihasilkan kebanyakan laman landas. Jika Anda membuat produk yang penggunanya menjalankan agen, modelnya portabel. Pekerjaan yang menarik tidak ada di kedua sisi; itu adalah kawat itu sendiri.