Agen LLM Itu Ujung-Ujungnya Sistem Terdistribusi

Komunitas AI sedang membangun sistem multi-agen — tim LLM yang membagi pekerjaan, saling berkomunikasi, dan berkolaborasi untuk menyelesaikan masalah yang tidak bisa ditangani satu model saja. Agen 'researcher' mengumpulkan informasi, agen 'coder' menulis implementasi, agen 'reviewer' memeriksa kualitas, dan agen 'coordinator' mengatur alur kerjanya. Janjinya menarik: agen-agen spesialis berkolaborasi seperti tim engineering yang rapi.

Kalau terdengar familiar, memang wajar. Peneliti sistem terdistribusi sudah mempelajari koordinasi proses independen selama 40 tahun. Sistem multi-agen LLM sedang menemukan ulang, dari nol, masalah-masalah yang sudah dipecahkan (atau terbukti tidak bisa dipecahkan) oleh komunitas sistem terdistribusi puluhan tahun lalu. Memahami kemiripan ini bisa menghemat kamu dari menciptakan ulang solusi, dan dari membangun sistem yang gagal dengan cara yang bisa diprediksi dan sudah dipahami dengan baik.

Pajak Koordinasi

Pelajaran pertama dari sistem terdistribusi: koordinasi punya overhead. Dua proses yang bekerja sendiri-sendiri pada tugas terpisah memang dua kali lebih cepat dari satu. Tapi dua proses yang mengerjakan tugas yang sama dan harus berkoordinasi sering kali lebih lambat dibanding satu proses, karena overhead komunikasi dan sinkronisasi lebih besar daripada keuntungan paralelismenya.

Sistem multi-agen LLM langsung mengalaminya. Agen 'researcher' menghasilkan laporan. Agen 'coder' perlu memahami laporan itu untuk menulis kode. Agen 'reviewer' perlu memahami laporan dan kode sekaligus untuk memberi masukan yang berguna. Setiap serah-terima mengharuskan konteks diserialisasi ke dalam prompt, lalu agen penerima harus mengurai dan memahaminya. Ini persis masalah shared state di sistem terdistribusi, dan makin parah seiring bertambahnya agen.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

Dalam sistem terdistribusi, ini adalah Hukum Amdahl yang diterapkan pada komunikasi: percepatan dari paralelisme dibatasi oleh komunikasi sekuensial yang tidak bisa diparalelkan. Menambah agen untuk tugas yang butuh koordinasi ketat justru membuat sistem makin lambat, bukan makin cepat.

Masalah Konsensus

Saat beberapa agen mengerjakan tugas yang sama, mereka harus sepakat soal banyak hal. Apa kebutuhannya? Pendekatan apa yang dipakai? Apakah implementasi ini sudah benar? Di sistem terdistribusi, ini disebut masalah konsensus, dan terbukti sulit. Hasil impossibility FLP menunjukkan bahwa konsensus deterministik tidak mungkin dicapai dalam sistem asinkron meskipun hanya ada satu proses yang rusak.

Agen LLM lebih buruk dari proses terdistribusi tradisional untuk konsensus karena sifatnya non-deterministik. Tanyakan pertanyaan yang sama dua kali ke agen yang sama, dan jawabannya bisa berbeda. Dua agen yang meninjau kode yang sama bisa tidak sepakat apakah kodenya benar. Agen 'coordinator' yang diminta menyelesaikan perbedaan itu bisa saja melempar koin.

Framework multi-agen biasanya menanganinya dengan menunjuk agen coordinator yang memegang otoritas final (model konsensus terpusat — sederhana tapi menciptakan single point of failure), atau dengan voting mayoritas (mahal — kamu butuh minimal tiga agen untuk setiap keputusan). Kedua pendekatan ini memang berfungsi, tapi mereka memecahkan masalah yang hanya ada karena kamu memecah pekerjaan ke banyak agen sejak awal.

Mode Kegagalan yang Seharusnya Sudah Familiar

Sistem multi-agen gagal dengan cara yang langsung dikenali oleh engineer sistem terdistribusi.

• Cascading failures. Agen A menghasilkan output buruk. Agen B, yang bekerja dari output A, menghasilkan output yang lebih buruk. Agen C, yang meninjau pekerjaan B, tidak menangkap kesalahan awal karena ia mewarisi asumsi yang keliru. Ini setara dengan error propagation di sistem terdistribusi: sampah masuk, sampah keluar, makin membesar di setiap tahap.
• Deadlocks. Agen A menunggu output Agen B untuk lanjut. Agen B menunggu feedback dari Agen A untuk lanjut. Keduanya tidak bisa maju. Dalam praktiknya, ini muncul sebagai infinite loop di mana agen terus saling mengoper pekerjaan tanpa pernah konvergen.
• Split brain. Dua agen yang mengerjakan tugas terkait mengembangkan pandangan yang tidak konsisten tentang masalahnya. Yang satu mengira API mengembalikan JSON; yang lain mengira XML. Output mereka masing-masing benar, tapi tidak kompatibel satu sama lain.
• Thundering herd. Agen coordinator mengirim pekerjaan ke banyak agen sekaligus. Semuanya menembak API yang sama, menghabiskan rate limit yang sama, atau mencoba mengubah file yang sama. Resource contention yang tidak akan pernah dihadapi oleh satu agen saja.

Kapan Multi-Agen Benar-Benar Membantu

Kemiripan dengan sistem terdistribusi itu berlaku dua arah. Sistem terdistribusi punya manfaat nyata untuk masalah tertentu. Sistem multi-agen juga begitu, asalkan dipakai untuk masalah yang memang diuntungkan oleh dekomposisi.

Tugas yang sangat paralel. Jika kamu perlu menganalisis 50 codebase untuk pola yang sama, 50 agen yang bekerja secara independen memang 50 kali lebih cepat. Tidak perlu koordinasi, karena setiap agen mengerjakan input terpisah dan menghasilkan output independen. Ini pola MapReduce, dan ia bekerja sama baiknya untuk agen LLM seperti untuk pemrosesan data terdistribusi.

Perspektif yang beragam. Meminta tiga agen dengan system prompt berbeda untuk meninjau kode yang sama bisa memunculkan masalah yang terlewat oleh satu review saja. Ini pola redundansi, seperti punya beberapa reviewer di sebuah PR. Harganya 3x lipat compute, tapi cakupannya lebih luas.

Spesialisasi dengan antarmuka yang bersih. Agen terjemahan yang menerima teks dan mengembalikan teks terjemahan punya antarmuka yang bersih. Agen ringkasan yang menerima dokumen dan mengembalikan ringkasan juga begitu. Menggabungkan keduanya — terjemahkan, lalu ringkas — berjalan baik karena antarmuka di antara keduanya sederhana. Padanannya di sistem terdistribusi: microservice dengan API yang terdefinisi jelas lebih baik daripada microservice dengan antarmuka yang cerewet dan rumit.

Pelajaran dari Sistem Terdistribusi

Kalau kamu sedang membangun sistem multi-agen LLM, puluhan tahun kebijaksanaan sistem terdistribusi berlaku langsung.

1. Utamakan sedikit agen yang lebih mumpuni daripada banyak agen spesialis. Sama seperti monolit yang dirancang dengan baik mengungguli arsitektur microservice yang dirancang buruk, satu agen yang mumpuni dengan prompting yang baik mengungguli tim agen sempit untuk sebagian besar tugas. Tambahkan agen hanya setelah kamu membuktikan bahwa satu agen tidak sanggup menangani beban kerjanya.
2. Definisikan antarmuka yang jelas antar agen. Input dan output setiap agen harus terdefinisi dengan baik. Serah-terima yang samar ('cari tahu apa yang ditemukan researcher lalu implementasikan') menyebabkan kehilangan konteks dan salah tafsir. Kontrak data terstruktur antar agen lebih baik daripada teks bebas.
3. Buat agen idempoten. Jika sebuah agen gagal di tengah jalan, kamu seharusnya bisa menjalankannya ulang dengan input yang sama dan mendapatkan hasil yang benar. Ini butuh agen yang tidak punya hidden state dan tidak menimbulkan efek samping sebelum output-nya terbukti benar.
4. Tambahkan observability. Catat setiap pesan antar agen, setiap keputusan, setiap kegagalan. Ketika sistem multi-agen menghasilkan output yang salah, kamu perlu menelusuri kesalahan itu kembali ke agen mana yang membuat keputusan keliru dan kenapa. Tanpa observability, debugging cuma menebak-nebak.
5. Rancang untuk kegagalan parsial. Agen mana pun bisa gagal, menghasilkan sampah, atau timeout. Sistem harus menangani ini dengan baik: retry, kembali ke pendekatan yang lebih sederhana, atau meminta bantuan manusia. Jangan pernah berasumsi bahwa semua agen akan berhasil.

Kebenaran yang Tidak Nyaman

Kebanyakan sistem multi-agen LLM akan bekerja lebih baik jika dibuat sebagai satu agen dengan prompt yang bagus. Overhead koordinasi, kehilangan konteks, dan mode kegagalan dari arsitektur multi-agen hampir selalu lebih berat daripada manfaatnya untuk tugas yang bisa ditangani satu model. Seiring evolusi tooling AI, godaan untuk membangun sistem multi-agen yang rumit makin besar, tapi pelajaran sistem terdistribusi sudah jelas: jangan distribusikan apa yang tidak perlu didistribusikan.

Pengecualiannya memang nyata: tugas yang sangat paralel, spesialisasi sungguhan dengan antarmuka yang bersih, dan masalah yang melampaui context window satu model. Untuk selebihnya, satu agen dengan prompt yang terstruktur baik, tool yang tepat, dan strategi retry yang matang akan mengungguli tim agen. Secara arsitektur memang kurang menarik, tapi hasilnya lebih baik. Sistem terdistribusi terbaik adalah yang tidak perlu kamu bangun.