Kenapa Muse Code membiarkan agent-nya hidup sepanjang sesi
Keputusan arsitektur diam-diam di balik cepatnya Muse Code: background agent yang bertahan sepanjang sesi, bukan di-spawn per tugas lalu dibuang.
Masalah spawn-lalu-buang
Kebanyakan tool coding multi-agent memakai resep yang sama: begitu ada tugas, nyalakan agent pembantu, kasih sepotong pekerjaan, ambil hasilnya, lalu matikan. Abstraksinya rapi, tapi ongkosnya jelek. Setiap agent yang baru di-spawn mulai dari nol — dia harus membaca ulang struktur repository, menemukan lagi build system-nya, mempelajari ulang konvensi yang dipakai codebase-mu. Dalam satu sesi dengan sepuluh tugas, pajak pengumpulan konteks itu dibayar sepuluh kali.
Pajaknya bukan cuma token. Ada latensi — tiap cold start menunda pekerjaan yang sebenarnya — dan ada usaha mengarahkan, karena agent yang lupa apa yang dia pelajari sejam lalu akan menanyakan hal yang sama dua kali padamu.
Jawaban Muse Code: persistensi
Muse Code dibangun sebagai satu loop agent utama yang sederhana plus sekumpulan background agent asinkron — dan background agent itu tetap aktif sepanjang sesi. Mereka tidak dibuat untuk tugas individual. Masing-masing terspesialisasi, terus menumpuk konteks seiring sesi berjalan, dan memutuskan sendiri kapan sesuatu cukup penting untuk dilaporkan balik ke agent utama.
Detail terakhir itu lebih penting dari kedengarannya. Background agent tidak memblokir loop utama sambil menunggu instruksi, dan mereka juga tidak membanjirinya dengan status update. Mereka menjalankan langkah berikutnya secara mandiri dan berkomunikasi hanya saat memang perlu. Alasan resmi dari Meta persis dua ongkos di atas: persistensi memangkas latensi, dan mengurangi kebutuhan manusia untuk terus mengarahkan pada tugas sulit yang bertahap banyak.
Worker jalan paralel, reviewer di belakang layar
Dalam praktiknya, kamu merasakannya seperti punya tim dengan peran tetap, bukan antrian pekerja lepas. Worker mengeksekusi perubahan secara paralel; reviewer terus-menerus mengkritisi hasilnya di background sebelum sampai ke kamu. Framing peluncurannya — “multi-agent by default” — memang presisi: koordinasi bukan mode yang kamu nyalakan, melainkan cara setiap tugas dijalankan. Kamu selesai lebih cepat bukan karena satu agent tertentu lebih cepat, tapi karena quality control berjalan bersamaan, bukan sebagai renungan belakangan.
Dilatih ke dalam model, bukan ditempel dari luar
Ada alasan kenapa desain harness ini bekerja lebih baik dengan Muse Spark 1.2 dibanding wrapper model generik. Modelnya di-co-train bersama harness Muse Code — resep trainingnya secara eksplisit mengoptimalkan perilaku subagent, berdampingan dengan goal dan context compaction. Pembagian kerja antara loop utama dan para spesialis persisten bukan trik prompt engineering yang ditempel di atasnya; modelnya sudah melihat pola itu saat training. Dari situlah klaim “lebih sedikit retry, tool use lebih baik” berasal, dan itu kami bahas mendalam di tulisan tentang bagaimana Muse Spark 1.2 dilatih.
Yang tidak diselesaikan oleh persistensi
Agent berumur panjang yang mengedit repository yang sama secara bersamaan adalah resep bencana merge — kalau mereka berbagi satu working copy. Tapi mereka tidak. Ketika pekerjaan di-fan-out, tiap agent anak yang punya akses tulis mendapat git worktree terisolasi miliknya sendiri, jadi pekerjaan paralel tidak pernah bertabrakan di level file. Mekanisme isolasi itu layak dapat penjelasannya sendiri: agent fan-out dan git worktree. Dan ketika kamu ingin tahu apa yang sebenarnya dilakukan agent-agent ini selagi kamu tidak menonton, event log yang append-only punya jawaban lengkapnya.