Kerja Cepat dengan AI Multi-Agent: Paralel, Tapi Tidak Kacau
Multi-agent bukan soal menjalankan model sebanyak mungkin. Ia soal memecah pekerjaan yang benar-benar independen, memberi satu pemilik per slice, dan menyisakan satu integrator yang memverifikasi hasil sebelum masuk.
Multi-Agent: Cepat Kalau Batasnya Jelas
Satu agent yang mengerjakan semuanya berurutan punya satu kelebihan besar: tidak ada koordinasi. Ia juga punya satu kelemahan besar: waktu tunggu.
Multi-agent menjanjikan sebaliknya — banyak pekerjaan berjalan bersamaan. Tapi paralelisme tanpa batas hanya menghasilkan konflik: dua agent menyunting berkas yang sama, kontrak yang berbeda versi, dan integrator yang menghabiskan lebih banyak waktu untuk mendamaikan daripada mengerjakan.
Kunci multi-agent bukan jumlah model. Kuncinya adalah desain pekerjaan.
Kapan Multi-Agent Benar-Benar Membantu
Paralelisme berguna ketika pekerjaan memenuhi tiga syarat:
- Bisa dipisah — tidak ada dua slice yang menyunting artefak yang sama.
- Punya kontrak — input, output, dan antarmuka sudah ditetapkan sebelum mulai.
- Bisa diverifikasi sendiri — setiap slice punya cara membuktikan dirinya benar (test, build, smoke run).
Contoh yang cocok:
- Fan-out riset — beberapa agent membaca bagian kode atau dokumen yang berbeda, lalu satu integrator merangkum.
- Slice fitur paralel — satu agent per halaman/endpoint yang tidak berbagi berkas.
- Build vs review — satu agent menulis, agent lain mengkritik dengan konteks yang sama.
- Migrasi mekanis — banyak berkas, aturan yang sama, satu pemilik per kelompok berkas.
- Uji dan reproduksi — satu agent menyiapkan skenario, satu lagi menjalankan dan menganalisis kegagalan.
Contoh yang tidak cocok:
- Dua agent menyunting satu komponen yang sama.
- Pekerjaan yang saling menunggu (bukan paralel, hanya dipaksa paralel).
- Tugas yang belum jelas definisi selesainya.
- Refactor besar yang mengubah kontrak di banyak tempat sekaligus.
Pola yang Terbukti
1. Orchestrator + Worker
Satu agent menyusun rencana, memecah pekerjaan, dan menetapkan batas. Worker mengerjakan slice. Orchestrator tidak ikut menulis kode; ia menjaga kontrak dan urutan.
2. Fan-out, lalu fan-in
Banyak worker membaca atau mengerjakan bagian berbeda, lalu hasilnya dikumpulkan oleh satu integrator. Aturannya: worker hanya menulis ke artefak miliknya; integrator yang menggabungkan.
3. Build vs Review
Agent penulis dan agent reviewer mendapat konteks dan kriteria yang sama. Reviewer tidak memperbaiki; ia melaporkan temuan. Penulis yang memutuskan, integrator yang memverifikasi.
4. Pipeline
Rencana → implementasi → test → review → merge. Setiap tahap punya keluaran yang bisa diperiksa. Ini lebih lambat daripada fan-out murni, tetapi jauh lebih aman untuk perubahan yang saling bergantung.
Sumber Kekacauan yang Paling Sering
| Gejala | Penyebab | Perbaikan |
|---|---|---|
| Konflik edit | Dua agent menulis berkas yang sama | Satu pemilik per berkas; pecah berdasarkan path |
| Kontrak berbeda | Interface ditentukan di tengah jalan | Tetapkan kontrak sebelum fan-out |
| Integrasi lambat | Hasil hanya ada di chat | Simpan hasil sebagai artefak (berkas, patch, laporan) |
| Test merah berulang | Tidak ada gate verifikasi | Satu perintah verifikasi yang sama untuk semua |
| Biaya membengkak | Terlalu banyak agent untuk pekerjaan kecil | Satu agent untuk tugas yang kurang dari satu slice |
| Kehilangan konteks | Handoff berupa ringkasan bebas | Handoff berupa kontrak + artefak + kriteria terima |
Aturan Main yang Saya Pakai
- Petakan slice sebelum spawn. Tulis daftar berkas dan antarmuka. Kalau dua slice menyentuh berkas yang sama, gabungkan.
- Kontrak dulu, kode kemudian. Tipe, endpoint, nama fungsi, dan format data ditetapkan di awal.
- Satu integrator. Hanya satu agent yang menggabungkan hasil dan menjalankan verifikasi akhir.
- Verifikasi deterministik. Build, test, dan smoke run dijalankan sekali di akhir, bukan diulang oleh setiap agent.
- Batas biaya dan waktu. Setiap worker punya anggaran; kalau habis, ia melapor, bukan berpikir lebih lama.
- Read-only untuk scout. Agent yang hanya mencari informasi tidak boleh menyunting.
- Hasil berupa artefak. Jangan mengandalkan percakapan sebagai media handoff.
Contoh Alur Kerja Nyata
Misalnya kamu menambah satu fitur yang menyentuh tiga area: API, halaman frontend, dan dokumentasi.
- Orchestrator menetapkan kontrak: payload, nama endpoint, dan bentuk respons.
- Worker A mengerjakan API dan test-nya.
- Worker B mengerjakan halaman frontend memakai kontrak yang sama.
- Worker C memperbarui dokumentasi dan contoh.
- Reviewer memeriksa ketiganya terhadap kontrak.
- Integrator menjalankan build dan test di branch gabungan, lalu merge.
Yang membuat ini cepat bukan jumlah agent-nya, melainkan tidak ada worker yang menunggu worker lain.
Infrastruktur untuk Menjalankan Banyak Agent
Agent yang berjalan paralel butuh tempat menjalankan pekerjaan yang terisolasi — terutama kalau mereka harus menyalakan service, menjalankan test berat, atau mereproduksi bug.
Di Dalang, itu bisa berupa beberapa VPS sekali pakai, atau satu baremetal kalau pekerjaannya menuntut resource besar. Dalang CLI menyediakan perintah yang bisa dibaca mesin, output JSON, dan mode non-interaktif untuk workflow yang sudah disetujui, sehingga orchestrator bisa membuat dan membersihkan environment tanpa menekan UI.
Yang tetap tidak boleh didelegasikan: keputusan untuk merge ke produksi. Itu tetap satu pintu, dengan verifikasi dan persetujuan.
Kesimpulan
Multi-agent adalah masalah desain organisasi, bukan masalah model. Kalau pembagian kerja, kontrak, dan gate verifikasinya jelas, paralelisme mempercepat. Kalau tidak, kamu hanya memindahkan waktu tunggu ke konflik.
Mulai dari satu agent. Pecah hanya ketika pekerjaannya benar-benar independen. Dan pertahankan satu integrator yang bertanggung jawab atas hasil akhir.