Artikel peluncuran Muse Wonder dari Meta menjelaskan sebuah perilaku yang mereka sebut Active Focus: model terus bekerja menuju target yang sulit, mencoba berbagai pendekatan alternatif, mengatasi hambatan, serta—mengutip kata-kata Meta—meminta klarifikasi saat diperlukan dan melakukan konfirmasi (check-in) sebelum mengambil tindakan penting. Meta juga menyarankan konfirmasi manusia sebelum tindakan-tindakan yang berdampak besar, dan panduan coding-agents miliknya meluncurkan Muse Code dengan persetujuan (approval) serta sandbox yang sudah aktif sejak eksekusi pertama.
Desain tersebut sudah tepat. Namun, hal ini juga memicu pertanyaan yang sudah sangat dipahami oleh setiap tim yang menjalankan agen secara paralel: ketika model berhenti untuk bertanya, siapa yang siap menjawab, seberapa cepat tanggapannya, dan dengan konteks seperti apa? Check-in yang muncul di terminal yang tidak dipantau siapa pun akan menghentikan eksekusi. Check-in yang masuk ke Inbox bersama, terhubung langsung dengan Task asalnya, menjadi sebuah langkah peninjauan (review). Artikel ini membahas cara membangun alur jenis kedua tersebut.
Dampak yang Dihasilkan Active Focus
Meta melatih tiga perilaku dan mengukurnya menggunakan tolok ukur internal bernama FocusBench, di mana Muse Wonder Full memimpin dengan skor 54,2% dan Wonder versi API berada di angka 44,9%, di belakang GPT-6 Astra dan Claude Opus 5.5. Kesampingkan dulu perolehan skor tersebut; perilakunyalah yang paling penting bagi sebuah board:
- Persistence. Model terus berjalan meski menghadapi kegagalan. Pada SWE-Marathon, tolok ukur pengodean berdurasi panjang, Wonder meraih skor 53,1 dibandingkan 46,3 milik Opus 5.5. Waktu eksekusi yang lebih lama, percobaan yang lebih banyak, serta makin banyak hal yang perlu ditinjau.
- Clarification. Model bertanya ketika Task bersifat ambigu, alih-alih menebak-nebak. Pada sebuah board, ini berupa komentar pada Task; di terminal, ini adalah prompt yang menunggu penekanan tombol keyboard.
- Check-ins. Model berhenti sejenak sebelum mengambil tindakan yang dinilai penting. Panduan Meta sendiri menyarankan agar tindakan apa pun yang berdampak besar mewajibkan konfirmasi manusia.
Masing-masing perilaku tersebut mengubah bentuk antrean peninjauan. Persistence menambah beban volume per Task. Clarification menambah interupsi. Check-in menambahkan keputusan yang menahan jalannya proses sampai seseorang memberikan tanggapan.
Ke Mana Check-in Diarahkan
Di Muse Code, prompt persetujuan muncul di terminal pengguna dan proses eksekusi akan tertahan menunggu. Eksekusi headless (muse exec) tidak memiliki prompt interaktif, sehingga dokumentasi Meta menyarankan untuk memilih kebijakan yang dapat diselesaikan tanpa pengawasan atau bersiap bahwa tindakan yang tertahan tidak akan pernah selesai. Itulah konsekuensi sebenarnya: antara ada orang di depan keyboard, model berjalan tanpa persetujuan, atau tindakan tersebut menunggu selamanya.
Pada board Sharkly, eksekusi merupakan sebuah Task yang ditugaskan ke Agent di sebuah Computer. Saat Agent berhenti untuk bertanya, pertanyaan tersebut dicatat di Task sebagai komentar dan diteruskan ke Inbox. Task menyimpan konteks lengkapnya: apa yang ditanyakan, apa yang telah dikerjakan Agent sejauh ini, log eksekusi panggilan tool, serta event Runtime. Siapa pun yang menanganinya dapat menjawab langsung di Task, sehingga proses eksekusi memiliki titik acuan yang jelas untuk dilanjutkan. Check-in ini tetap merupakan keputusan manusia; namun keputusan manusia yang memiliki rekam jejak, antrean, dan dapat ditangani oleh lebih dari satu orang.
Itulah perbedaan antara pengaman (safeguard) dan hambatan (stall). Perilaku modelnya sama persis. Sistem di sekitarnyalah yang menentukan apakah sebuah check-in hanya memakan waktu satu menit atau tertunda seharian.
Menulis Instruksi Agent agar Check-in Bermanfaat
Kualitas check-in sangat bergantung pada pertanyaannya. Cantumkan standar pertanyaan yang baik langsung dalam instruksi Agent:
Stop and ask before anything destructive, anything that sends data outside the
attached repositories, any payment or external account action, and any change
to CI, deploy or access configuration.
When you ask, state in one comment: what you are about to do, why the Task needs
it, what you considered instead, and what happens if the answer is no.
Do not ask about reversible edits inside the repository. Make them, test them,
and report.
If you have waited for an answer and the Task has a deadline, say so in a second
comment rather than proceeding.
Aturan pertama menetapkan batasan yang jelas. Model buatan Meta memutuskan sendiri apa yang dianggap penting; instruksi ini menegaskan apa yang dianggap penting oleh tim Anda. Aturan kedua memastikan komentar tersebut dapat dijawab dalam tiga puluh detik oleh seseorang yang tidak memantau proses eksekusi sejak awal. Aturan ketiga mencegah model menanyakan segala hal—sebuah kegagalan umum yang mengubah agen yang berhati-hati menjadi sangat menjengkelkan. Artikel guardrail untuk Opus 5.5 membahas batasan serupa dari sudut pandang prompt injection: gerbang peninjauan adalah kendali utamanya, apa pun janji model tersebut.
Memperhitungkan Kapasitas Antrean
Persistence berarti lebih banyak tinjauan per Task, bukan lebih sedikit. Rencanakan hal ini sejak awal.
| Lane | Pola eksekusi umum | Apa yang masuk ke antrean |
|---|---|---|
| Muse Wonder pada Task panjang | Banyak langkah, beberapa pendekatan dibatalkan (revert) | Diff lebih panjang, log lebih panjang, nol hingga tiga check-in |
| Opus 5.5 pada Task yang sama | Lebih sedikit langkah, lebih tegas | Diff lebih pendek, atau Task dikembalikan dalam kondisi setengah selesai |
| Model apa pun, berjalan semalaman tanpa pengawasan | Apa pun yang diizinkan oleh kebijakan | Tindakan yang tertahan, atau tindakan yang tidak dikonfirmasi siapa pun |
Ada tiga praktik untuk menjaga antrean tetap berjalan lancar. Pertama, arahkan check-in ke peninjau (reviewer) tertentu yang ditunjuk per lane alih-alih ke semua orang, agar pertanyaan tidak tertahan menunggu tanggapan grup. Kedua, atur batas waktu (timeout) per-Task pada Agent agar proses yang terblokir oleh check-in gagal secara transparan, bukan menggantung dengan status running selama berjam-jam. Ketiga, baca log eksekusi, bukan hanya diff kodenya, untuk eksekusi Wonder: jejak dari tiga pendekatan yang gagal adalah bagian ekstra dari model yang persisten, dan di situlah kesalahan-kesalahan halus sering tersembunyi. Artikel Coding agents while you’re away mengulas skenario eksekusi semalaman tanpa pengawasan, dan artikel human review is the bottleneck menjelaskan mengapa semua proses ini tidak otomatis menjadi lebih murah hanya dengan model yang lebih baik.
Bentuk Check-in yang Efektif pada Board
Berikut adalah bentuk keluaran yang dihasilkan dari instruksi di atas, berupa komentar Task yang dapat segera ditindaklanjuti oleh peninjau bahkan dari ponsel:
Check-in before action.
About to: drop the legacy `orders_v1` table in the migration.
Why: the Task says remove v1 read paths; the table is the last reference.
Considered: keeping the table and removing only the code. Rejected because
the nightly job still writes to it and would fail silently.
If no: I will leave the table, remove the code paths, and note the job in
the report for a follow-up Task.
Empat baris, satu keputusan, dan kedua skenario sudah terencana. Peninjau cukup mengetik “yes” atau “no, keep it” pada Task, proses eksekusi berlanjut, dan log akan mencatat siapa yang mengambil keputusan. Bandingkan dengan prompt terminal yang hanya menampilkan Allow? [y/N] kepada seseorang yang tidak menyaksikan empat puluh langkah sebelumnya.
Dua penyempurnaan setelah lane berjalan selama seminggu: Jika ada satu peninjau yang menjawab sebagian besar check-in, tetapkan peninjau kedua untuk Agent di lane tersebut agar rapat sore hari tidak menghentikan seluruh eksekusi berdurasi panjang. Dan jika Agent menanyakan kategori tindakan yang sama berulang kali, masukkan kategori tersebut ke dalam instruksi sebagai keputusan otomatis yang selalu disetujui atau selalu ditolak, bukan membiarkannya menumpuk di antrean.
Kasus Penggunaan Computer Use
Meta mencantumkan computer use di antara kemampuan Wonder: mengoperasikan browser, desktop, dan aplikasi seluler. Di sinilah check-in menjadi sangat krusial dan prompt terminal menjadi sangat tidak memadai, karena tindakan yang dilakukan berupa klik pada layar yang tidak dapat dilihat oleh peninjau. Aturan yang sama dari artikel computer-use Astra berlaku: Agent berjalan di Computer yang ditentukan oleh tim, check-in menyebutkan layar serta tindakan yang akan diambil, dan pihak yang mengonfirmasi dapat melihat log Task sebelum menyetujuinya. Model yang meminta izin untuk menekan tombol Submit hanya akan aman jika seseorang tahu persis apa akibat dari penekanan Submit tersebut.
Batasan yang Perlu Dipahami
Active Focus adalah perilaku model, dan perilaku model bukanlah sebuah jaminan. Ringkasan model dari Meta sendiri menyatakan bahwa model masih dapat melakukan kesalahan pada tugas multitahap yang belum dikenal, dan laporan keselamatan lengkapnya masih belum dirilis. Check-in adalah fitur yang menyempurnakan sistem peninjauan yang sudah baik; fitur ini tidak menggantikannya. Tim yang mengartikan “melakukan konfirmasi sebelum tindakan penting” sebagai izin untuk menjalankan agen tanpa pengawasan sama sekali telah salah paham. Tim yang melengkapi setiap check-in dengan Task, peninjau, dan batas waktu telah membangun sistem yang tepat sesuai tujuan rancangan fitur tersebut.
Semua ini tidak membebani tagihan Sharkly. Penggunaan model berjalan melalui API key Meta yang dikonfigurasi pada Computer. Pembaruan model terjadi pada 12 Oktober. Konteks, progres, hambatan, hasil, serta peninjauan manusia tetap transparan dari permintaan awal hingga rilis. Anda dapat membangun alur ini secara manual menggunakan worktree, atau memanfaatkan Sharkly untuk mengelola alur kerjanya.
