Bayangin satu perusahaan punya “manager AI”.
Tugasnya menerima objective: “Siapkan proposal untuk calon klien baru.”
Manager AI lalu membagi pekerjaan.
Agent riset mencari informasi perusahaan. Agent finance menghitung estimasi. Agent legal mengecek klausul. Agent writing membuat proposal. Agent QA meninjau. Agent lain mengirim draft ke manusia.
Ini sudah bukan satu chatbot.
Ini organisasi mini yang sebagian anggotanya software.
Pada 2026, pola multi-agent seperti ini bukan lagi sekadar konsep akademik. Framework enterprise sudah mendokumentasikan banyak bentuk orchestration: sequential, concurrent, handoff, group collaboration, sampai orchestrator yang secara dinamis mendelegasikan pekerjaan ke agent spesialis.
Secara engineering, menarik.
Secara governance, bikin kepala agak pusing.
Kalau hasil akhirnya salah, siapa yang bertanggung jawab?
Orchestrator? Agent spesialis? Model provider? Developer? Pemilik workflow? Manusia yang memberi objective?
Jawaban sehatnya: tanggung jawab tidak boleh hilang hanya karena pekerjaan dibagi ke banyak AI.
Delegasi bukan penghapusan accountability
Di dunia manusia, CEO tidak bisa bilang: “yang salah staf saya, jadi bukan tanggung jawab saya.”
Ada struktur.
Orang tahu siapa pemilik proses. Siapa approver. Siapa executor. Siapa reviewer.
Multi-agent juga butuh itu.
Kalau satu orchestrator memanggil lima agent, sistem harus tetap punya owner manusia atau organisasi yang jelas.
Misalnya finance automation.
Agent A membaca invoice. Agent B mencocokkan purchase order. Agent C menilai anomaly. Agent D merekomendasikan pembayaran.
Kalau pembayaran salah, investigasi harus bisa mundur: data apa masuk, agent mana memberi keputusan, tool apa dipakai, policy apa berlaku, dan siapa menyetujui.
Tanpa trace, multi-agent hanya membuat kesalahan lebih susah dicari.
Orchestrator tidak otomatis paling pintar
Nama “manager agent” bisa bikin kita menganggap ia memahami semuanya.
Padahal orchestrator biasanya punya fungsi spesifik: memecah task, memilih agent, mengirim konteks, menggabungkan hasil.
Ia juga bisa salah.
Salah routing. Salah memberi konteks. Salah memilih specialist. Salah menentukan kapan task selesai.
Bayangin agent legal seharusnya dipanggil untuk kontrak tertentu, tapi orchestrator menganggapnya tidak perlu.
Hasil akhir bisa terlihat bagus karena agent lain bekerja benar.
Namun satu langkah kritis hilang.
Failure seperti ini sulit terlihat.
Jadi eval multi-agent harus menguji orchestration, bukan cuma kualitas agent individu.
Apakah route benar? Apakah urutan benar? Apakah dependency terpenuhi? Apakah approval dipanggil?
Manager yang buruk bisa membuat tim bagus menghasilkan output buruk.
AI juga begitu.
Kesalahan bisa diwariskan antar-agent
Ini problem serius.
Agent riset menemukan fakta salah.
Agent analisis menerima fakta itu sebagai input.
Agent writing menulisnya dengan rapi.
Agent QA hanya memeriksa grammar.
Kesalahan awal berubah jadi output final yang polished.
Setiap tahap menambah confidence.
Ini seperti permainan bisik-bisik, tapi semua peserta terdengar profesional.
Karena itu, multi-agent architecture perlu memisahkan: generation, verification, dan approval.
Jangan buat lima agent yang semuanya hanya percaya pada output sebelumnya.
Beberapa agent perlu akses sumber primer. Beberapa perlu memverifikasi ulang. Beberapa perlu punya mandat untuk menolak.
Redundancy berguna kalau independence nyata.
Kalau semua agent memakai data dan prompt yang sama, mereka bisa salah bersama-sama.
Voting bukan selalu solusi
Salah satu pola multi-agent adalah menjalankan beberapa agent paralel lalu memilih hasil mayoritas.
Ini bisa berguna.
Tiga agent menilai satu kasus. Dua sepakat. Satu berbeda.
Tapi majority vote bukan guarantee.
Kalau semua model punya bias sama, mayoritas bisa salah.
Kalau sumber datanya sama, semua bisa mewarisi kesalahan sama.
Kalau pertanyaannya ambigu, voting hanya memilih interpretasi paling populer.
Untuk tugas factual, evidence lebih penting daripada jumlah suara.
Tiga AI bilang aturan berlaku belum tentu benar.
Satu dokumen resmi bisa lebih kuat.
Jadi quorum harus dipakai di tempat yang tepat: brainstorming, ensemble prediction, atau task dengan variasi solusi.
Untuk compliance atau legal, sumber authoritative tetap penting.
Handoff menciptakan blind spot
Dalam pola handoff, satu agent menyerahkan percakapan ke agent lain.
Misalnya support agent menerima customer. Masalah billing dialihkan ke billing agent. Kasus fraud ke risk agent.
Ini efisien.
Tapi handoff punya problem klasik yang juga terjadi di organisasi manusia.
Context hilang.
Customer harus mengulang. Detail penting tidak ikut. Agent kedua salah memahami prioritas. Ownership kabur.
Kalau AI melakukan handoff, sistem perlu memastikan konteks yang relevan ikut, tapi tidak berlebihan.
Ini balance.
Terlalu sedikit context bikin agent kedua buta. Terlalu banyak context bisa melanggar privacy atau membebani model.
Prinsip least privilege tetap berlaku antar-agent.
Agent billing nggak perlu seluruh histori HR user. Agent marketing nggak perlu data payroll. Agent research nggak perlu akses transaksi.
Multi-agent bukan alasan permission jadi luas.
Satu agent compromise bisa menyebar
Security juga berubah.
Kalau satu agent terkena prompt injection lalu bisa mengirim instruksi ke agent lain, serangan bisa menyebar.
Bayangkan research agent membaca website berbahaya.
Di halaman ada instruksi yang mencoba membuat agent mengirim data internal.
Research agent mungkin tidak punya permission mengirim email.
Tapi ia bisa memberikan output ke orchestrator.
Kalau orchestrator lalu meneruskan ke agent komunikasi yang punya email access, risiko meningkat.
Ini contoh kenapa trust boundary antar-agent harus jelas.
Output agent seharusnya tidak otomatis dianggap trusted instruction.
Ada perbedaan antara: “ini data dari agent lain” dan “ini command yang harus dijalankan.”
Sistem perlu policy enforcement di level tool.
Bukan hanya berharap model memahami perbedaannya.
Accountability harus mengikuti action
Cara sederhana memikirkan ini: semakin besar konsekuensi action, semakin jelas owner-nya harus terlihat.
Agent membuat draft internal: risiko rendah.
Agent mengubah database customer: lebih tinggi.
Agent mengirim kontrak: tinggi.
Agent memindahkan uang: sangat tinggi.
Untuk action penting, log seharusnya mencatat: agent yang meminta, agent yang menjalankan, model yang dipakai, user yang memulai, approval manusia, timestamp, dan hasil.
Audit trail seperti ini bukan overkill.
Kalau sistem membuat keputusan yang berdampak nyata, organisasi harus bisa menjelaskan prosesnya.
Kalau jawabannya: “pokoknya agent chain melakukan itu,” governance gagal.
Human approval perlu ditempatkan di node yang tepat
Kalau manusia harus approve setiap output agent, multi-agent kehilangan manfaat.
Kalau tidak ada approval sama sekali, risiko naik.
Solusinya bukan human in every loop.
Lebih tepat: human at material decision points.
Misalnya workflow proposal.
Riset otomatis. Analisis otomatis. Draft otomatis. Compliance check otomatis. Final pricing perlu manusia. Send ke klien perlu manusia.
Atau procurement.
Cari vendor otomatis. Bandingkan otomatis. Risk scoring otomatis. Purchase decision tetap manusia.
Ini membuat autonomy punya boundary.
AI bisa mengerjakan banyak langkah, tapi keputusan yang membawa liability tetap punya accountable human.
Tidak semua agent perlu model berbeda
Ada hype bahwa multi-agent harus berarti banyak AI berbeda.
Padahal kadang satu model dengan beberapa role sudah cukup.
Agent research dan agent reviewer bisa memakai model sama tetapi prompt, tool, dan context berbeda.
Di kasus lain, memang berguna memakai model berbeda.
Model cepat untuk extraction. Model frontier untuk reasoning. Model lokal untuk privacy.
Yang penting bukan jumlah agent.
Yang penting decomposition.
Kalau pekerjaan sebenarnya sederhana, membuat delapan agent hanya menambah failure point.
Microsoft sendiri dalam panduan 2026 menekankan bahwa sistem sebaiknya memakai pola paling sederhana yang memenuhi kebutuhan, lalu menambah kompleksitas hanya ketika skenario memang memerlukannya.
Ini prinsip engineering yang waras.
Jangan bikin organisasi AI hanya karena diagramnya keren.
Multi-agent harus punya kontrak kerja
Setiap agent perlu definisi yang jelas.
Input apa yang diterima. Output apa yang wajib dihasilkan. Tool apa yang boleh dipakai. Kapan harus berhenti. Kapan harus eskalasi. Data apa yang tidak boleh disentuh. Bagaimana error ditangani.
Ini mirip API contract.
Tanpa contract, agent saling berasumsi.
Misalnya agent riset mengirim teks bebas. Agent berikutnya mengharapkan JSON. Sistem gagal.
Atau agent legal memberi warning. Orchestrator menganggap warning hanya komentar dan tetap lanjut.
Contract membuat hubungan lebih deterministic.
Semakin banyak agent, semakin penting struktur.
Kalau perusahaan punya puluhan agent tanpa katalog dan ownership, mereka akan mengalami versi baru “shadow IT”.
Shadow agent.
Ada automation yang jalan tapi nggak ada yang benar-benar tahu siapa pemiliknya.
Observability harus lintas agent
Dalam satu chatbot, tracing relatif sederhana.
User request. Model response.
Dalam multi-agent: user request, orchestrator, agent A, tool, agent B, database, agent C, approval, agent D.
Kalau error terjadi di langkah ketujuh, kita perlu melihat graph.
Observability harus menunjukkan: urutan, latency, cost, token, failure, retry, handoff, tool use.
Kalau tidak, debugging jadi nightmare.
Buat tim operasi, ini juga penting untuk cost.
Satu task mungkin terlihat seperti satu request user.
Di belakang layar ada 40 model calls.
Kalau nggak terlihat, biaya susah dikendalikan.
Multi-agent membuat leverage naik, tapi juga membuat hidden complexity naik.
Siapa yang bertanggung jawab?
Secara praktis, bukan AI.
AI tidak duduk di rapat audit. Tidak menandatangani kontrak. Tidak membayar ganti rugi. Tidak menjelaskan ke regulator dengan tanggung jawab legalnya sendiri.
Organisasi yang deploy sistem tetap punya tanggung jawab.
Di dalam organisasi, harus ada process owner.
Vendor model punya tanggung jawab terhadap layanan dan produknya sesuai kontrak dan hukum.
Developer bertanggung jawab pada implementasi sesuai perannya.
Approver bertanggung jawab pada keputusan yang memang berada di kewenangannya.
Tanggung jawab bisa terbagi.
Tapi tidak boleh menguap.
Jangan bikin struktur AI lebih rumit daripada struktur manusia
Ada godaan membuat agent untuk semua fungsi.
Researcher. Planner. Critic. Writer. Reviewer. Manager. Supervisor. Meta-reviewer.
Sebagian use case memang membutuhkan itu.
Tapi banyak tidak.
Setiap agent baru adalah: prompt baru, permission baru, context baru, cost baru, failure mode baru.
Kalau satu agent plus tool dan validation sudah cukup, pakai itu.
Multi-agent masuk akal ketika: task benar-benar punya domain terpisah, parallelism membantu, ownership berbeda, atau kualitas meningkat karena specialization.
Kalau tidak, simplicity menang.
Pada akhirnya, pertanyaan governance multi-agent bukan: “AI mana yang salah?”
Pertanyaan yang lebih berguna: “Proses mana yang gagal, siapa owner proses itu, dan kontrol apa yang harus diperbaiki?”
Karena dalam sistem yang matang, agent hanyalah bagian dari workflow.
Accountability tetap harus punya alamat manusia.
Bacaan terkait
Artikel ini berada dalam AI dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Explainer teknologi dan kebijakan digital.