Lewati ke konten utama
Versi: Next

Multi-Agent Orchestration

Satu agent dengan konteks penuh sudah menyelesaikan mayoritas pekerjaan. Multi-agent baru masuk akal ketika pekerjaan punya salah satu sifat ini:

  • Paralel secara alami — 10 file yang perlu dimigrasi dengan pola sama, review dari 4 sudut pandang berbeda.
  • Butuh pemisahan peran — penulis kode tidak boleh menilai kodenya sendiri (bias yang sama berlaku untuk agent).
  • Melebihi satu context window — codebase besar yang harus disurvei sebelum diputuskan.

Tiga pola inti​

1. Fan-out / fan-in​

Orchestrator memecah pekerjaan menjadi task independen, menyebar ke N worker paralel, lalu menggabungkan hasil. Contoh: migrasi API di 40 file — orchestrator membagi per direktori, tiap worker mengerjakan bagiannya di worktree terpisah, orchestrator menggabungkan dan menjalankan test penuh.

Kunci suksesnya: task harus benar-benar independen. Kalau worker A dan B menyentuh file yang sama, kamu baru saja menciptakan merge conflict otomatis.

2. Pipeline reviewer → verifier​

Output satu agent menjadi input agent berikutnya, dengan peran berbeda:

[Author]  →  [Reviewer]  →  [Verifier]
 tulis kode    cari bug &      buktikan tiap temuan
 + test        pelanggaran     dengan reproduksi nyata,
               konvensi        buang false positive

Tahap verifier sering dilewatkan padahal paling berharga: reviewer AI menghasilkan temuan dengan confidence beragam, dan verifier yang diminta "reproduksi atau tolak" memangkas false positive sebelum sampai ke kamu. Ini pola yang sama dengan review loop playbook, dinaikkan menjadi pipeline otomatis.

3. Orchestrator-worker​

Satu agent berumur panjang memegang gambaran besar (rencana, state, keputusan), mendelegasikan eksekusi ke worker berumur pendek, dan hanya menerima ringkasan — bukan seluruh log kerja worker. Ini cara menjaga konteks orchestrator tetap bersih untuk pekerjaan berhari-hari.

Praktik di tool modern​

Subagent bawaan (Task/Agent tool) untuk fan-out dalam satu sesi; custom agents via .claude/agents/*.md untuk peran khusus (reviewer, verifier); fitur Workflow untuk pipeline deterministik yang memanggil banyak subagent. Prinsipnya: sesi utamamu = orchestrator, subagent = worker sekali pakai.

Kapan multi-agent justru merugikan​

Ini bagian yang jarang ditulis vendor:

  1. Biaya mengalikan diri. N worker = N× token, dan orchestrator ikut membayar untuk membaca semua ringkasan. Fan-out 10 agent untuk masalah yang bisa diselesaikan 1 agent adalah cara membakar uang paling elegan. Mulai dari 1, tambah hanya saat terbukti bottleneck.
  2. Koherensi bocor di antara agent. Dua worker yang tidak saling melihat akan mengambil keputusan desain berbeda untuk masalah sama (dua util function duplikat, dua gaya error handling). Semakin banyak agent, semakin banyak "lem" yang harus kamu review.
  3. Debugging jadi arkeologi. Satu agent salah → baca satu transcript. Delapan agent salah → delapan transcript dan satu orchestrator yang merangkum dengan optimis.
  4. Konteks yang dibagi adalah konteks yang hilang. Worker hanya tahu apa yang dituliskan orchestrator di prompt-nya. Kalau pekerjaanmu butuh pemahaman utuh atas sistem, satu agent berkonteks penuh mengalahkan lima agent berkonteks sepotong.

:::warning Heuristik sederhana Kalau kamu tidak bisa menuliskan pembagian tugasnya sebagai daftar poin yang saling bebas dalam 2 menit, pekerjaan itu belum siap untuk multi-agent. :::

Lanjut ke​

  • Pipeline butuh trigger eksternal (form, webhook, chat) → Integrasi n8n.
  • Orchestration berjalan lama butuh mesin yang selalu hidup → Self-Hosted Runner.
Diperbaharui pada