Agentic Development Part 6: Multi-Agent Workflow

Lima artikel sebelumnya di series ini membahas bagaimana satu agent bekerja — otonomi (Part 1), anatominya (Part 2), desain task untuk satu agent (Part 3), context yang dibutuhkannya (Part 4), dan guardrail yang menjaganya tetap aman (Part 5). Tapi ada kelas pekerjaan yang tidak cukup diselesaikan satu agent, betapapun baik desain task dan context-nya — pekerjaan yang skalanya besar, melibatkan domain berbeda yang masing-masing butuh spesialisasi, atau mencakup tahapan yang secara alami terpisah mulai dari requirement mentah sampai kode yang siap deploy. Artikel ini membahas bagaimana beberapa agent bekerja sama secara terkoordinasi, dengan pipeline dari PRD sampai deliverable sebagai studi kasus sentral — topik yang sempat dibahas sebagai diskusi terpisah sebelum series ini disusun ulang untuk secara eksplisit mencakupnya di sini.

Kapan Satu Agent Tidak Lagi Cukup

Part 2 sudah membahas pola sub-agent dalam satu task — delegasi sementara untuk eksplorasi paralel yang hasilnya langsung diserap kembali oleh agent utama dalam satu sesi kerja. Multi-agent workflow yang dibahas di artikel ini berbeda dalam tiga hal mendasar dari pola itu:

Independensi peran. Setiap agent dalam workflow punya tanggung jawab yang jelas dan berbeda — bukan sekadar instance yang sama dijalankan paralel untuk mempercepat eksplorasi, melainkan agent dengan peran fungsional yang berbeda: satu menerjemahkan requirement, satu mengeksekusi implementasi, satu memverifikasi hasil.

Durasi yang lebih panjang. Sub-agent dalam satu task biasanya berumur pendek, selesai begitu sub-pekerjaannya rampung. Agent dalam multi-agent workflow sering hidup sepanjang satu tahapan penuh dari pipeline, kadang lintas sesi.

Kebutuhan koordinator eksplisit. Begitu ada lebih dari satu agent dengan peran independen yang harus bekerja secara konsisten satu sama lain, dibutuhkan lapisan yang mengatur urutan, mendistribusikan pekerjaan, dan menggabungkan hasil — peran yang di pola sub-agent sederhana cukup dipegang implisit oleh agent utama.

Riset yang membandingkan performa setem tunggal versus multi-agent pada tugas yang setara menemukan temuan yang penting untuk diperhatikan: pada mayoritas benchmark, satu agent dengan tools dan context yang sama justru menyamai atau mengungguli sistem multi-agent, dengan multi-agent hanya memberi keuntungan akurasi kecil pada biaya yang kira-kira dua kali lipat. Implikasinya jelas — multi-agent bukan default yang otomatis lebih baik, melainkan trade-off yang hanya masuk akal ketika kompleksitas pekerjaan benar-benar membutuhkan spesialisasi atau paralelisme yang tidak bisa dicapai satu agent saja. Bagian akhir artikel ini akan membahas kriteria konkret untuk menilai trade-off ini.

Pertanyaan yang lebih tepat sebelum membangun multi-agent workflow bukan “apakah ini bisa dipecah jadi beberapa agent”, tapi “apakah satu agent dengan task yang didesain baik (seperti dibahas di Part 3) benar-benar tidak cukup untuk pekerjaan ini”. Kompleksitas tambahan dari orkestrasi multi-agent hanya sepadan kalau jawabannya jelas tidak.

Pola Orkestrasi: Orchestrator-Worker

Dari berbagai pola orkestrasi yang berkembang, pola orchestrator-worker (sering disebut juga supervisor pattern) adalah yang paling banyak dipakai di produksi karena sifatnya yang predictable dan mudah di-debug. Satu agent koordinator memegang rencana keseluruhan dan mendelegasikan sub-pekerjaan ke agent pekerja, lalu menggabungkan hasilnya kembali.

flowchart TD
    A[Koordinator: Pegang Rencana Keseluruhan] --> B[Worker 1: Sub-pekerjaan A]
    A --> C[Worker 2: Sub-pekerjaan B]
    A --> D[Worker 3: Sub-pekerjaan C]
    B --> E[Koordinator: Gabungkan Hasil]
    C --> E
    D --> E
    E --> F{Hasil Lengkap & Konsisten?}
    F -- Ya --> G[Selesai]
    F -- Tidak --> A

Alasan pola ini menjadi pilihan default dibanding alternatif seperti mesh peer-to-peer (di mana setiap agent bisa berkomunikasi langsung dengan agent lain tanpa perantara) ada di traceability dan kemudahan debugging. Pada pola mesh, melacak kenapa suatu keputusan diambil membutuhkan penelusuran komunikasi antar banyak agen yang saling berinteraksi bebas — jumlah jalur komunikasi yang mungkin tumbuh cepat seiring bertambahnya agent. Pada pola orchestrator-worker, semua keputusan tentang urutan dan distribusi kerja melewati satu titik tunggal, membuat alur keputusan tetap bisa ditelusuri secara linear meski jumlah worker bertambah.

Variasi lain yang juga umum dipakai tergantung bentuk pekerjaan: sequential pipeline untuk pekerjaan yang urutannya tetap dan setiap tahap bergantung penuh pada output tahap sebelumnya (cocok untuk pipeline dari requirement sampai deliverable yang akan dibahas berikutnya), dan fan-out/fan-in untuk pekerjaan yang benar-benar independen dan bisa dikerjakan paralel sebelum digabung kembali. Ketiga pola ini — orchestrator-worker, sequential pipeline, fan-out/fan-in — sering dikombinasikan dalam satu workflow yang sama, bukan dipilih secara eksklusif satu saja.

Mulai dari pola orchestrator-worker atau sequential pipeline sebagai default. Pola yang lebih kompleks seperti komunikasi peer-to-peer bebas antar banyak agent sebaiknya dipertimbangkan hanya setelah ada kebutuhan nyata yang tidak bisa dipenuhi pola yang lebih sederhana — kompleksitas tambahan harus dijustifikasi oleh kebutuhan, bukan dipilih karena terdengar lebih canggih.

Studi Kasus: Dari PRD ke Deliverable

Inilah pipeline yang menjadi tulang punggung artikel ini — bagaimana requirement bisnis mentah, yang sering under-specified secara teknis, diterjemahkan secara bertahap menjadi deliverable yang konsisten, melalui titik kontrol yang eksplisit di tengah jalan.

flowchart TD
    A[PRD / Requirement Bisnis] --> B[Spec Teknis: ERD, API Contract, State Model]
    B --> C[Plan: Pemecahan jadi Task/Ticket]
    C --> D[Eksekusi Agent per Task]
    D --> E[Deliverable: Kode, Test, PR]
    B -.disepakati & direview manusia.-> B

Setiap tahap dalam diagram ini layak dibahas terpisah, karena masing-masing punya karakteristik dan risiko yang berbeda.

PRD ke Spec Teknis. Tahap ini adalah titik di mana ambiguitas bisnis paling tinggi dan butuh diterjemahkan jadi keputusan teknis konkret. Agent (biasanya berperan sebagai koordinator atau agent khusus tahap awal) bisa mengusulkan draft ERD, kontrak API, dan model state dari PRD secara otomatis — tapi draft ini secara eksplisit bukan hasil akhir yang langsung dieksekusi. Inilah jawaban langsung dari pertanyaan yang mendorong penyusunan ulang artikel ini: PRD murni tidak cukup spesifik untuk menjamin implementasi yang konsisten, karena ia menjelaskan apa yang dibutuhkan dari sudut pandang bisnis, bukan bagaimana data dimodelkan atau kontrak antar komponen didefinisikan.

Spec Teknis sebagai Checkpoint Wajib. Ini titik kontrol paling kritis dalam keseluruhan pipeline, dan secara sengaja didesain sebagai titik yang paling membutuhkan keterlibatan manusia, bukan yang paling layak diotomatisasi penuh. Begitu ERD dan kontrak API disepakati dan disimpan sebagai file rujukan — persis seperti skema OpenAPI dan JSON Schema yang dibahas di Part 3 series Spec-Driven Development — file itu menjadi kontrak tetap yang dibaca semua agent berikutnya di pipeline ini, mencegah setiap agent “menciptakan ulang” desain teknisnya sendiri secara berbeda-beda.

Spec Teknis ke Plan. Setelah spec disepakati, koordinator memecahnya jadi task-task individual mengikuti prinsip granularitas dan dependency yang sudah dibahas mendalam di Part 3 — termasuk mengidentifikasi task mana yang independen dan bisa dikerjakan paralel oleh worker berbeda, dan mana yang harus menunggu task lain selesai lebih dulu.

Plan ke Eksekusi Multi-Agent. Task-task yang sudah dipecah didistribusikan ke worker — bisa satu agent generalis yang mengerjakan task secara sekuensial, atau beberapa agent dengan spesialisasi berbeda yang bekerja paralel (dibahas lebih detail di bagian spesialisasi peran). Setiap worker tetap merujuk pada spec teknis yang sama sebagai sumber kebenaran, bukan asumsi masing-masing.

Eksekusi ke Deliverable. Hasil dari setiap worker digabungkan koordinator, melewati lapisan guardrail yang dibahas di Part 5 — test otomatis, contract test terhadap spec, dan jika perlu reviewer agent independen — sebelum dianggap sebagai deliverable yang siap, baik berupa pull request, build yang siap deploy, atau artefak lain tergantung konteks project.

Godaan terbesar dalam membangun pipeline semacam ini adalah mengotomatisasi penuh tahap PRD-ke-spec-teknis demi kecepatan, dengan asumsi draft yang dihasilkan agent “sudah cukup baik”. Tahap inilah justru yang paling berisiko kalau dilewati tanpa review manusia — kesalahan desain ERD atau kontrak API yang tidak terkoreksi di sini akan menjalar ke setiap task berikutnya yang dibangun di atasnya.

Komponen Orkestrasi: Decomposer, Registry, State Manager

Di balik diagram orchestrator-worker yang terlihat sederhana, ada tiga komponen yang membuat koordinasi ini benar-benar berfungsi di praktik, bukan sekadar konsep di atas kertas.

Task decomposer — komponen yang memecah goal besar (dalam studi kasus di atas, spec teknis yang sudah disepakati) menjadi daftar work item konkret. Ini fungsinya mirip dengan disiplin mendesain task yang dibahas mendalam di Part 3, tapi dijalankan sebagai bagian eksplisit dari sistem orkestrasi, bukan dilakukan manual sekali di awal. Decomposer yang baik menghasilkan work item yang well-formed — masing-masing punya scope jelas dan bisa dieksekusi tanpa ambiguitas tambahan, persis prinsip yang sudah dibahas sebelumnya soal task yang dipotong di sepanjang batas yang secara alami independen.

Agent registry — daftar yang memetakan agent mana yang punya kapabilitas apa. Pada pipeline PRD-ke-deliverable, ini berarti koordinator tahu bahwa task tertentu (misalnya migrasi skema database) sebaiknya didelegasikan ke worker yang dikonfigurasi untuk pekerjaan backend, sementara task lain (validasi form di sisi client) didelegasikan ke worker yang dikonfigurasi untuk frontend. Registry ini mencegah koordinator mendelegasikan pekerjaan ke agent yang tidak punya context atau tool yang tepat untuk menyelesaikannya dengan baik.

State manager — komponen yang menyimpan context dan hasil antar tahap, mencegah informasi hilang di setiap handoff antar agent. Ini krusial khususnya untuk pipeline yang berlangsung lama atau lintas sesi: tanpa state manager yang eksplisit, hasil kerja satu agent bisa hilang konteksnya begitu diteruskan ke agent berikutnya, memaksa agent penerima menebak ulang informasi yang sebenarnya sudah ada.

flowchart LR
    A[Goal: Spec Teknis Disepakati] --> B[Task Decomposer]
    B --> C[Daftar Work Item]
    C --> D[Agent Registry]
    D --> E{Worker Mana yang Cocok?}
    E --> F[Worker Backend]
    E --> G[Worker Frontend]
    F --> H[(State Manager)]
    G --> H
    H --> I[Koordinator: Gabungkan dengan Context Lengkap]

Ketiga komponen ini saling melengkapi: decomposer menentukan apa yang harus dikerjakan, registry menentukan siapa yang mengerjakan, state manager memastikan apa yang sudah dikerjakan tidak hilang jejaknya sepanjang perjalanan dari satu agent ke agent berikutnya.

Mencegah Implementasi yang Lain-lain: Kontrak sebagai Penjaga Konsistensi

Ini jawaban langsung untuk kekhawatiran yang mendorong restrukturisasi series ini: tanpa spec teknis eksplisit, implementasi yang dihasilkan dari PRD yang sama bisa berbeda-beda setiap kali dijalankan — bahkan oleh agent yang persis sama di sesi berbeda, apalagi oleh beberapa agent yang bekerja paralel dalam satu pipeline.

Akar masalahnya, seperti sudah disinggung di pembuka artikel ini, adalah agent yang menerima requirement bisnis murni akan mengisi celah desain teknis dengan asumsinya sendiri di momen itu juga. Dalam konteks multi-agent workflow, masalah ini berlipat ganda: kalau worker backend dan worker frontend masing-masing menebak bentuk kontrak API secara independen tanpa rujukan bersama, hasilnya hampir pasti tidak akan cocok satu sama lain begitu digabungkan.

flowchart TD
    subgraph TanpaKontrak["Tanpa Kontrak Eksplisit"]
        A1[Worker Backend] -->|menebak bentuk response sendiri| B1[API v1]
        A2[Worker Frontend] -->|menebak bentuk response berbeda| B2[Asumsi Berbeda]
        B1 -.tidak cocok.-> B2
    end
    subgraph DenganKontrak["Dengan Kontrak Disepakati di Awal"]
        C[Spec Teknis: API Contract] --> C1[Worker Backend]
        C --> C2[Worker Frontend]
        C1 -.sama-sama merujuk kontrak yang sama.-> C2
    end

Inilah kenapa checkpoint spec teknis yang dibahas di studi kasus sebelumnya bukan langkah administratif yang bisa dilewati demi kecepatan, melainkan mekanisme inti yang membuat multi-agent workflow bisa diandalkan sama sekali. Begitu kontrak — ERD, skema API, definisi state — disepakati dan disimpan sebagai file yang dirujuk semua agent, setiap worker punya sumber kebenaran yang sama untuk dipatuhi, terlepas dari kapan dan oleh agent mana task tersebut dieksekusi. Ini secara langsung adalah aplikasi dari prinsip kontrak API yang dibahas di Part 3 series Spec-Driven Development, hanya saja sekarang dilihat dari sudut pandang kenapa ia esensial khusus untuk koordinasi multi-agent, bukan sekadar kerapian dokumentasi.

Pipeline yang melompat langsung dari PRD ke eksekusi multi-agent tanpa lapisan spec teknis eksplisit adalah resep untuk implementasi yang saling bertentangan. Semakin banyak agent yang terlibat secara paralel, semakin mahal pula biaya untuk mendamaikan implementasi yang sudah terlanjur berbeda asumsi — jauh lebih mahal daripada menyepakati kontrak sejak awal sebelum eksekusi dimulai.

Spesialisasi Agent per Peran

Worker dalam multi-agent workflow bisa didesain generalis (satu jenis agent yang sama mengerjakan task apa saja yang didelegasikan) atau spesialis (agent dengan role sempit dan context yang disesuaikan untuk domain tertentu). Keduanya punya trade-off yang jelas.

Pola yang umum dipakai di pipeline produksi mengikuti lima peran fungsional yang relatif konsisten ditemukan di berbagai sistem multi-agent yang reliable, terlepas dari domain spesifiknya: producer (memecah ambiguitas menjadi work item yang well-formed — peran yang dipegang task decomposer di studi kasus PRD di atas), consumer/worker (mengeksekusi work item tersebut), coordinator (mengatur keseluruhan alur), critic (mengajukan temuan tanpa otoritas memutuskan — mirip reviewer agent yang dibahas di Part 5), dan judge (memutuskan secara biner apakah hasil lolos atau tidak).

Pemisahan yang sering diabaikan tapi penting: producer dan consumer tidak boleh dicampur perannya. Producer bertugas menerjemahkan ambiguitas jadi work item yang jelas; consumer bertugas mengeksekusi work item yang sudah jelas tersebut. Mencampur kedua peran ini dalam satu agent adalah salah satu penyebab paling umum dari prompt yang kusut dan konsumsi token yang membengkak tanpa kendali, karena agent yang sama dipaksa bolak-balik antara “memikirkan apa yang harus dikerjakan” dan “benar-benar mengerjakannya” tanpa batas yang jelas kapan harus berpindah mode.

Demikian pula, critic dan judge sebaiknya dipisah perannya: critic mengajukan saran tanpa otoritas gerbang, judge yang memutuskan lolos atau tidak secara tegas. Mencampur keduanya — critic yang juga punya otoritas memutuskan — bisa menciptakan deadlock di mana proses tidak pernah benar-benar selesai karena selalu ada “saran lagi” yang diajukan tanpa batas keputusan yang jelas.

Untuk pipeline yang baru dibangun, mulai dengan jumlah peran spesialis seminimal mungkin yang masuk akal — misalnya hanya producer, consumer, dan judge — baru tambahkan peran lain (seperti critic terpisah) ketika ada bukti nyata bahwa peran tambahan itu menyelesaikan masalah yang benar-benar terjadi, bukan ditambahkan secara spekulatif di awal.

Kegagalan Khas Multi-Agent Workflow

Memahami kegagalan yang khas terjadi pada sistem multi-agent membantu mendiagnosis masalah dengan tepat, alih-alih menambah lapisan kompleksitas yang justru memperburuk keadaan.

Drift antar agent karena context terpisah. Worker yang bekerja dengan context window masing-masing yang terpisah bisa mengembangkan pemahaman yang sedikit berbeda tentang task yang sama, terutama kalau spec teknis yang jadi rujukan bersama tidak benar-benar dibaca ulang oleh setiap worker di awal task-nya. Mitigasinya sudah dibahas di bagian kontrak sebagai penjaga konsistensi — pastikan setiap worker benar-benar merujuk file kontrak yang sama, bukan mengandalkan ringkasan yang mungkin sudah kehilangan detail penting.

Deadlock atau menunggu handoff yang tidak jelas. Terjadi ketika dependency antar task (dibahas di Part 3) tidak didefinisikan eksplisit dalam sistem orkestrasi, sehingga worker menunggu input dari worker lain tanpa mekanisme yang jelas kapan dan bagaimana handoff itu terjadi. State manager yang baik, seperti dibahas di bagian komponen orkestrasi, seharusnya membuat dependency ini eksplisit dan terlacak, bukan diasumsikan akan “terjadi dengan sendirinya”.

Duplikasi kerja. Dua worker mengerjakan task yang tumpang tindih karena task decomposer tidak memecah pekerjaan dengan batas yang cukup jelas, atau karena registry salah memetakan task yang sama ke dua worker berbeda. Ini menghasilkan pemborosan kerja sekaligus risiko hasil yang saling bertentangan ketika digabungkan.

Satu agent gagal merusak keseluruhan pipeline tanpa isolasi. Kalau kegagalan satu worker (misalnya menghasilkan kode yang error) tidak terisolasi dengan baik, kegagalan itu bisa menjalar ke proses penggabungan hasil dan menggagalkan keseluruhan pipeline, padahal worker lain sudah menyelesaikan pekerjaannya dengan benar. Guardrail per task yang dibahas di Part 5 — termasuk automated gate sebelum hasil diteruskan ke tahap berikutnya — berfungsi sebagai pemutus yang mengisolasi kegagalan ini supaya tidak menjalar lebih jauh dari yang seharusnya.

flowchart TD
    A[Worker A Gagal] --> B{Terisolasi dengan Gate?}
    B -- Ya --> C[Hanya Task Worker A yang Tertunda]
    C --> D[Worker B, C Tetap Lanjut Independen]
    B -- Tidak --> E[Kegagalan Menjalar ke Proses Penggabungan]
    E --> F[Seluruh Pipeline Gagal Meski Worker Lain Benar]

Selain empat kegagalan fungsional di atas, ada juga pertimbangan biaya operasional yang nyata: koordinasi antar agent menambah overhead — baik dari sisi latensi (waktu tambahan untuk komunikasi antar agent) maupun konsumsi token (context tambahan yang perlu dibagikan dan diproses ulang oleh setiap agent dalam pipeline). Overhead ini bukan sekadar biaya finansial, tapi juga faktor yang perlu dipertimbangkan saat menilai apakah multi-agent benar-benar sepadan untuk suatu pekerjaan — dibahas lebih lanjut di bagian berikutnya.

Kapan Multi-Agent Bermanfaat vs Overkill

Mengingat kembali temuan di awal artikel bahwa satu agent dengan tools dan context yang sama sering menyamai performa sistem multi-agent pada biaya yang jauh lebih rendah, keputusan membangun pipeline multi-agent perlu didasarkan pada sinyal yang jelas, bukan asumsi bahwa lebih banyak agent selalu lebih baik.

Sinyal yang menunjukkan multi-agent workflow worth dibangun:

• Sub-pekerjaan yang benar-benar independen dan bisa paralel — seperti backend dan frontend yang dikerjakan bersamaan setelah kontrak API disepakati, di mana paralelisme benar-benar memotong waktu penyelesaian secara signifikan
• Kebutuhan spesialisasi domain yang nyata — task yang membutuhkan konteks dan konvensi sangat berbeda (misalnya audit keamanan versus implementasi fitur) di mana memaksakan satu agent generalis menghasilkan kualitas yang lebih rendah di kedua domain
• Pipeline yang akan dipakai berulang kali — investasi membangun decomposer, registry, dan state manager lebih masuk akal kalau pipeline ini akan dipakai untuk banyak fitur ke depan, bukan sekali pakai
• Volume pekerjaan yang besar — ketika jumlah task yang harus dieksekusi cukup banyak sehingga paralelisme memberi penghematan waktu yang berarti, bukan sekadar dua atau tiga task kecil

Sinyal yang menunjukkan multi-agent justru overkill:

• Task yang sebenarnya sekuensial ketat — kalau setiap langkah benar-benar bergantung penuh pada hasil langkah sebelumnya, paralelisme tidak memberi manfaat, dan overhead koordinasi (latensi dan token tambahan, seperti dibahas di bagian kegagalan) murni jadi biaya tanpa kompensasi kecepatan
• Volume pekerjaan kecil — untuk pekerjaan yang dengan mudah diselesaikan satu agent dalam satu sesi yang wajar, kompleksitas membangun dan memelihara sistem orkestrasi tidak sepadan dengan manfaatnya
• Tim atau project yang belum punya spec teknis matang — mengingat kembali bahaya yang dibahas di bagian kontrak sebagai penjaga konsistensi, membangun multi-agent workflow tanpa fondasi spec yang solid hanya memperbesar skala masalah drift implementasi, bukan menyelesaikannya
• Kebutuhan debugging yang sederhana — sistem multi-agent secara inheren lebih sulit di-debug dibanding satu agent, karena masalah bisa berasal dari logika satu agent, kesalahan komunikasi antar agent, atau kesalahan di lapisan orkestrasi itu sendiri

Bangun multi-agent workflow setelah mencoba satu agent dengan task yang didesain baik dan ternyata terbukti tidak cukup — bukan sebagai langkah pertama karena terdengar lebih canggih atau lebih “agentic”. Kompleksitas tambahan dari orkestrasi multi-agent adalah biaya nyata yang harus dijustifikasi oleh kebutuhan konkret, persis seperti peringatan yang sama berlaku untuk menaikkan level otonomi di Part 1 — keduanya sama-sama godaan yang terasa maju tapi belum tentu sepadan dengan biayanya.

Ringkasan

• Multi-agent workflow berbeda dari sub-agent dalam satu task (Part 2) dalam tiga hal: independensi peran, durasi yang lebih panjang, dan kebutuhan koordinator eksplisit
• Riset menunjukkan satu agent sering menyamai atau mengungguli sistem multi-agent pada biaya jauh lebih rendah — multi-agent hanya sepadan ketika kompleksitas pekerjaan benar-benar membutuhkannya, bukan default otomatis
• Pola orchestrator-worker (atau sequential pipeline, fan-out/fan-in) lebih disukai dibanding mesh peer-to-peer karena traceability dan kemudahan debugging yang jauh lebih baik
• Pipeline PRD ke deliverable melewati titik kontrol kritis di tengah: spec teknis (ERD, kontrak API) yang disepakati dan direview manusia sebelum eksekusi — ini titik yang paling butuh keterlibatan manusia, bukan yang paling layak diotomatisasi penuh
• Tiga komponen orkestrasi yang membuat koordinasi berfungsi nyata: task decomposer (memecah goal jadi work item), agent registry (memetakan kapabilitas ke task), dan state manager (mencegah context hilang di tiap handoff)
• Kontrak spec teknis yang disepakati di awal adalah penjaga konsistensi utama yang mencegah implementasi lintas agent menjadi berbeda-beda — tanpa ini, setiap worker akan mengisi celah desain teknis dengan asumsinya sendiri secara independen
• Lima peran fungsional yang konsisten ditemukan pada sistem multi-agent yang reliable: producer, consumer, coordinator, critic, judge — producer/consumer dan critic/judge sebaiknya tidak dicampur perannya untuk mencegah prompt yang kusut dan deadlock keputusan
• Kegagalan khas: drift antar agent karena context terpisah, deadlock dari dependency yang tidak eksplisit, duplikasi kerja, dan kegagalan satu agent yang menjalar tanpa isolasi guardrail yang memadai
• Bangun multi-agent hanya setelah satu agent dengan task yang didesain baik terbukti tidak cukup — pertimbangkan sub-pekerjaan independen, kebutuhan spesialisasi nyata, dan volume pekerjaan yang sepadan dengan overhead koordinasi yang pasti muncul