Multi-Agent dan Tasks di omp: Fan-Out yang Terkendali

Satu Panggilan, Banyak Worker

Pekerjaan besar jarang benar-benar satu pekerjaan. Ia biasanya terdiri dari beberapa bagian yang bisa dikerjakan bersamaan: membaca tiga modul berbeda, menulis test di beberapa area, atau memeriksa perubahan dari beberapa sudut.

omp mengekspos itu lewat tool task. Satu panggilan bisa melahirkan banyak subagent, masing-masing dengan instruksi sendiri, berjalan dengan batas konkurensi yang sama.

Kuncinya bukan “sebanyak mungkin”, melainkan fan-out yang bisa diverifikasi.

Bentuk Dasarnya

Dengan batch aktif (default), satu panggilan berbentuk:

{
  "context": "Repo ini memakai SvelteKit. Jangan mengubah kontrak API. Verifikasi dengan bun run test.",
  "tasks": [
    {
      "name": "ApiSlice",
      "agent": "task",
      "task": "Tambahkan endpoint X beserta test-nya di src/routes/api/x.",
      "solutionSpace": "satu perubahan yang jelas: endpoint + test"
    },
    {
      "name": "UiSlice",
      "agent": "task",
      "task": "Tambahkan tombol dan form di src/routes/x, memakai payload dari konteks.",
      "solutionSpace": "satu perubahan yang jelas: UI + state"
    },
    {
      "name": "DocsSlice",
      "agent": "task",
      "task": "Perbarui dokumentasi endpoint X dan contoh request/response.",
      "solutionSpace": "satu perubahan yang jelas: docs"
    }
  ]
}

Tiga hal yang membuat ini bekerja:

context wajib — konteks bersama yang masuk ke system prompt setiap subagent. Ini yang mencegah mereka memakai asumsi berbeda.
task lengkap — subagent tidak mewarisi percakapanmu. Instruksi yang setengah jadi akan menghasilkan pekerjaan setengah jadi.
solutionSpace — menjelaskan seberapa terbuka masalahnya. Field ini dipakai classifier thinking untuk memilih effort; volume pekerjaan bukan alasan untuk menaikkannya.

Agent yang Sudah Ada

omp membawa beberapa agent bawaan:

Agent	Cocok untuk
`scout`	Membaca dan memetakan kode, read-only
`reviewer`	Memeriksa perubahan untuk correctness
`security-reviewer`	Mencari risiko keamanan
`task`	Pekerjaan umum (default)
`sonic`	Tugas mekanis/cepat

Agent kustom bisa diletakkan di .omp/agents/ (proyek) atau ~/.omp/agent/agents/ (user), lalu dipanggil dengan "agent": "namamu".

Hidup Setelah Spawn

Saat async aktif, spawn berjalan di latar belakang. Kamu tidak perlu menunggu di dalam panggilan:

agent://<id> — output lengkap subagent (.md), termasuk sidecar .json bila ada structured output.
history://<id> — transkrip ringkas: apa yang sudah dikerjakan.
write agent://<id> — kirim pesan lanjutan ke agent yang masih hidup.
wait — tunggu hasil kalau tidak ada pekerjaan lain.
proc://<id>/kill — batalkan job.

Nested spawn memakai id bertitik, misalnya agent://Parent.Child.

agent://<id> dan history:// adalah alasan untuk tidak meminta agent meringkas dirinya di chat: hasil aslinya sudah tersimpan.

Batas yang Berlaku

Konkurensi default 32 spawn paralel per sesi; setting task.maxConcurrency bisa menurunkannya.
Kedalaman rekursi default 2. Subagent tidak bisa terus melahirkan subagent tanpa batas.
Idle TTL default 7 menit; agent yang selesai diparkir, lalu bisa dihidupkan lagi dengan pesan.
Output dipotong di tampilan, tetapi file penuh tetap ditulis ke agent://<id>.
Request budget membatasi percakapan panjang; scout/sonic punya batas lebih rendah.

Batas ini ada supaya fan-out tidak menjadi ledakan biaya.

Isolasi: Saat Dua Agent Tidak Boleh Berbagi Checkout

Kalau task.isolation.enabled aktif dan plan mode mati, item bisa diberi isolated: true. Masing-masing mendapat workspace sendiri (worktree/overlay/clone), lalu perubahannya diambil sebagai patch atau branch.

Ini penting ketika:

dua agent menyentuh berkas yang sama,
kamu ingin membandingkan dua pendekatan tanpa saling menimpa,
kamu ingin review patch sebelum masuk ke checkout utama.

Tanpa isolasi, semua subagent berbagi checkout induk. Itu cepat, tetapi hanya aman kalau slice-nya benar-benar terpisah.

Memantau

Tekan Alt+A untuk membuka Agent Hub: daftar agent yang berjalan, status, aktivitas, model, dan pemakaian. Dari sana kamu bisa membaca transkrip, mengirim pesan, atau menghidupkan agent yang diparkir.

Kalau kamu memakai TUI dengan mouse, kartu task yang sedang berjalan juga bisa diklik.

Pola yang Bekerja

1. Scout dulu, worker kemudian

Jalankan scout untuk memetakan kode, lalu pakai hasilnya sebagai context untuk worker. Ini mencegah worker menemukan struktur yang berbeda-beda.

2. Satu slice, satu pemilik

Setiap item harus punya himpunan berkas yang jelas. Kalau dua item menyentuh berkas yang sama, gabungkan atau pisahkan dengan isolasi.

3. Reviewer terpisah

Jangan meminta worker yang sama menilai pekerjaannya sendiri. Spawn reviewer setelah worker selesai, dengan konteks dan kriteria yang sama.

4. Hasil berupa artefak

Minta output yang bisa diperiksa: patch, berkas, laporan. Bukan “sudah selesai”.

5. Verifikasi di satu tempat

Build dan test dijalankan sekali di akhir oleh integrator (kamu atau satu agent), bukan oleh setiap worker. Ini menghemat waktu dan menghindari hasil yang saling bertentangan.

Anti-Pola

Terlalu banyak agent untuk pekerjaan kecil. Satu agent lebih murah dan lebih cepat.
Konteks kosong. Tanpa context, setiap worker mengarang asumsinya sendiri.
Slice yang saling bergantung tanpa urutan. Fan-out bukan cara memaksa paralelisme pada pekerjaan serial.
Mempercayai ringkasan. Buka agent://<id> dan periksa.
Tanpa gate verifikasi. Spawn yang sukses bukan berarti hasilnya benar.

Mulai dari Dua

Cara termudah memulai: satu scout + satu task worker. Setelah itu terasa, tambahkan reviewer, lalu batch tiga slice untuk pekerjaan yang benar-benar independen.

omp menyediakan mekanismenya; disiplin memecah pekerjaan tetap milikmu. Informasi: omp.sh.