Orkestrasi

Satu agen bagus untuk satu hal. Sebagian permintaan lebih besar dari itu: “riset pasar untuk X dan tulis dokumen positioning”, “kirim fitur ini dari awal sampai akhir”, “audit modul ini dan perbaiki apa yang Anda temukan”. Orkestrasi adalah cara Control Center menangani permintaan semacam itu: seorang orkestrator (biasanya agen CEO Anda) mengusulkan rencana seluruh tim, Anda menyetujuinya sekali, dan materializer deterministik mengubahnya menjadi pipeline yang mengerjakan pekerjaan tersebut.

Ia berada di antara dua cara menyelesaikan pekerjaan yang sudah ada:

Jika Anda ingin…	Gunakan
Menyerahkan satu tugas ke satu agen	Sebuah pesan di sebuah space
Menyusun sendiri proses yang sudah Anda ketahui	Sebuah templat pipeline
Menyebut tujuan dan membiarkan tim menyusun rencananya	Sebuah orkestrasi

Bentuk sebuah proposal

Saat Anda memberi orkestrator sebuah tujuan, ia mengembalikan OrchestrationProposal yang terstruktur: rencana bertipe yang dapat divalidasi dan dijalankan aplikasi, bukan prosa bebas. Sebuah proposal memuat:

Tujuan: permintaan tingkat tinggi Anda, yang dinyatakan ulang.
Peran: siapa yang mengerjakan. Setiap peran adalah agen yang sudah ada yang Anda pilih, atau rekrut baru yang dibuat orkestrasi saat disetujui.
Sub-tiket: pekerjaannya, dipecah menjadi DAG berisi tiket.
Riset (opsional): fase riset yang berjalan lebih dulu dan memasok sisanya.
Diskusi (opsional): satu putaran terbatas tempat setiap peran memposting posisi terstruktur sebelum pekerjaan dimulai.
Sintesis: langkah terakhir yang menghasilkan hasil kerja.
Anggaran: batas biaya yang dinyatakan.

Tempat Anda meninjaunya

Dua permukaan menampilkan orkestrasi yang sama.

Kartu proposal berada di percakapan yang menghasilkan rencana tersebut. Ia adalah satu pesan yang dirender ulang sepanjang siklus hidupnya — diusulkan, dijalankan, selesai — dengan tindakan setujui dan batalkan di dalamnya.

Plan Studio adalah editornya: kanvas DAG, inspector node, laci revisi dan diff, serta bilah persetujuan yang membawa estimasi. Ia terbuka sebagai tab editor langsung dari kartu tersebut. Di sidebar memang sengaja tidak ada item “Rencana”; /plans dan /plans/:kind/:id tersedia sebagai deep link untuk berbagi.

Persetujuan hanya dapat dilakukan operator. Tidak ada alat MCP untuk itu: agen dapat mengusulkan (propose_orchestration), mengirim rencana (submit_plan), atau membuat instance playbook (run_playbook), tetapi hanya manusia yang menyetujui. Revisi yang dimulai agen juga dibatasi lajunya dengan jeda dua menit, sehingga loop perencanaan ulang akan menggabung alih-alih membanjiri umpan Anda.

Apa yang dapat Anda ubah sebelum menyetujui adalah apa yang ditampilkan inspector node: mengganti judul atau menulis ulang sub-tiket, mengubah peran yang memilikinya, menyambungkan ulang dependensinya, mengedit skema output-nya, atau menghapus node tersebut sepenuhnya. Node struktural (riset, diskusi, sintesis) dan node yang sudah dijalankan bersifat hanya baca. Anda tidak dapat menyematkan peran ke agen bernama tertentu, dan Anda tidak dapat mengedit anggaran dari editor.

Dua editor pada satu rencana diselesaikan dengan konkurensi optimistis, bukan penggabungan. Setiap edit membawa base_revision yang menjadi dasarnya; edit yang didasarkan pada revisi basi ditolak dengan “the plan moved on”, bukan diam-diam menimpa milik orang lain. Memundurkan juga bukan penghapusan — ia menambahkan proposal lama sebagai revisi baru, sehingga garis waktu revisi hanya bertambah.

Estimasi jujur, atau tidak sama sekali

Estimasi di bilah persetujuan dibangun dari riwayat proses yang benar-benar selesai untuk tiap peran, sebagai rentang interkuartil (p25–p75). Total biaya adalah jumlah node yang dapat diestimasi; durasi adalah jalur kritis melalui DAG, bukan penjumlahannya (cabang paralel saling tumpang tindih).

Node yang perannya tidak punya riwayat proses selesai melaporkan sampleSize: 0 dan rentang null. Itu dirender persis seperti itu — tidak diketahui — tidak pernah sebagai nilai titik yang dibuat-buat, karena estimasi yang tidak dapat Anda percayai lebih buruk daripada tanpa estimasi. Jika sebagian node punya riwayat dan sebagian tidak, totalnya ditandai sebagian. Radius dampak muncul hanya jika node mendeklarasikan ref asal-usul symbol atau file; node tanpa itu tetap “tidak diketahui” alih-alih menyimpulkannya dari prosa.

Satu persetujuan, lalu eksekusi deterministik

Inilah ide intinya: agen merencanakan; fungsi deterministik yang mengeksekusi. Saat Anda menyetujui, OrchestrationMaterializer, fungsi murni tanpa LLM dan tanpa I/O, mengubah proposal menjadi pipeline sungguhan. Dengan proposal yang sama dan peran yang sudah diresolusi sama, ia selalu menghasilkan DAG yang sama. Itu penting karena pipeline yang dihasilkan mewarisi semua yang sudah dilakukan mesin secara cuma-cuma: penangguhan dan pelanjutan lintas restart, pemulihan dari crash, akumulasi biaya dan token per proses, serta UI detail proses.

Persetujuan juga membuat perancah yang dibutuhkan pekerjaan:

merekrut setiap peran yang ditandai baru (dan mencatat id agen yang direkrut agar crash di tengah persetujuan dapat dilanjutkan tanpa rekrutan ganda)
sebuah tim yang mengelompokkan peran-peran tersebut
sebuah proyek yang mencatat tiket induk
templat pipeline + proses yang menggerakkan semuanya

Siklus hidup

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Status	Arti
`proposed`	Rencana sudah siap dan menunggu satu persetujuan di muka dari Anda
`approved`	Anda menyetujuinya; materialisasi sedang berjalan (rekrutan, tim, proyek, pipeline)
`executing`	Pipeline yang dihasilkan sedang berjalan: sub-tiket, diskusi, pekerjaan
`synthesizing`	Sub-tiket sudah selesai; langkah sintesis sedang menghasilkan hasil kerja
`completed`	Selesai: tiket induk ditandai selesai dan hasil kerjanya diposting di space bersama
`failed`	Materialisasi gagal, atau proses pipeline yang dihasilkan gagal
`cancelled`	Anda membatalkannya

Nomor revisi yang monoton melacak proposal saat orkestrator merevisinya selagi statusnya masih proposed; aplikasi mencatat revisi mana yang Anda setujui. propose_orchestration menolak revisi begitu statusnya bukan lagi proposed.

Orkestrasi selalu dibuka terhadap sebuah tiket induk dan berbagi satu space diskusi, sehingga seluruh upaya dapat dilacak ke satu item pekerjaan dan timnya berbicara di satu ruangan.

Apa yang terjadi saat selesai

Pendengar yang dijaga tetap hidup memantau pipeline yang dihasilkan dan memetakan status akhirnya kembali ke orkestrasi dan tiket induk, sehingga penyelesaian dan kegagalan muncul di tempat yang sudah Anda pantau. Fitur orkestrasi tidak memerlukan mesin eksekusinya sendiri.

Anda dapat membatalkan orkestrasi kapan saja; pembatalan itu membongkar pekerjaan yang sedang berjalan.

Lihat juga

Pipeline dan otomatisasi: mesin tempat orkestrasi yang dimaterialisasi berjalan
Tiket dan delegasi: tiket induk tempat orkestrasi dijangkar
Model agen: peran yang diisi atau direkrut oleh orkestrasi
Jalankan orkestrasi
Bekerja di Plan Studio