Multi-Agent AI: Arsitektur Bisnis dan Teknologi per Layer

Satu agent itu kayak satu karyawan generalis. Bisa ngerjain banyak hal, tapi ada plafonnya.

Gue pernah lihat pola yang sama berulang: satu agent awalnya pinter, terus kerjaannya meluas, konteks yang harus dibaca makin banyak, dan hasilnya perlahan mulai ngaco. Reaksi pertama hampir selalu sama: tambah agent. Satu buat riset, satu buat verifikasi, satu buat nulis. Kelihatannya logis, persis kayak nambah orang di tim.

Masalahnya, di sistem AI nambah agent itu nggak otomatis nambah kualitas. Anthropic pernah ngukur sistem multi-agent mereka, dan hasilnya 90,2% lebih baik dari single agent di evaluasi riset internal mereka. Tapi catatan yang sama pentingnya ada di paragraf sebelahnya: sistem itu pakai token sekitar 15x lebih banyak dibanding chat biasa. Di sisi lain, ada studi yang nyamain anggaran token antara single agent dan multi-agent, dan di kondisi itu single agent setara atau justru lebih baik di tugas penalaran bertahap.

Jadi bahasan ini bukan soal mana yang lebih canggih. Ini soal arsitektur: kapan lo butuh satu orang, kapan lo butuh tim, dan kapan biaya timnya nggak sebanding sama hasilnya. Artikel ini gue bagi dua pov, karena multi-agent itu keputusan organisasi sekaligus keputusan teknis. Yang pertama arsitektur bisnis, yang kedua arsitektur teknologi. Dua-duanya gue bedah per layer.

Kalo lo belum baca fondasinya, dua artikel ini nyambung langsung: Agentic AI: Bongkar Mesin di Balik AI yang Kerja Sendiri dan Peta Arsitektur AI untuk Bisnis.

Mulai dari yang Paling Murah: Satu Agent Plus Tools

Sebelum ngomongin tim, gue mau nahan dulu. Di panduan Building Effective Agents (Desember 2024), Anthropic nulis prinsip yang sering dilewatin: cari solusi paling sederhana dulu, dan buat banyak kasus, optimasi satu panggilan model plus retrieval itu udah cukup. Mereka juga ngingetin bahwa sistem agentik umumnya menukar latency dan biaya demi performa, dan nambah kompleksitas cuma layak kalo hasilnya kebukti lebih baik.

Terjemahan praktisnya: agent tunggal yang punya tools lengkap dan konteks yang rapi itu titik awal yang benar. Multi-agent bukan level berikutnya yang wajib dinaikin, tapi salah satu pilihan arsitektur yang punya syarat.

Tiga Sinyal Lo Beneran Butuh Lebih dari Satu Agent

Dari pola yang terdokumentasi, ada tiga situasi di mana multi-agent masuk akal.

Pertama, kerjaannya bercabang dan bisa paralel. Di sistem riset Anthropic, lead agent nyalain 3 sampai 5 subagent sekaligus, dan tiap subagent pakai 3 tools atau lebih secara paralel. Efeknya: waktu penyelesaian untuk query kompleks turun sampai 90%. Kuncinya ada di kata “bisa paralel”. Kalo kerjaannya berurutan, paralelisasi nggak nambah apa-apa.

Kedua, konteksnya udah numbuk. Satu agent yang harus megang seluruh riwayat percakapan, hasil semua tool, plus instruksi, cepat atau lambat kehabisan ruang dan mutu jawabannya turun. Memecah kerjaan jadi beberapa agent artinya tiap agent cuma nanggung konteks yang relevan buat tugasnya.

Ketiga, eksekusi dan verifikasi perlu dipisah. Ini alasan yang lebih sering datang dari sisi tata kelola daripada dari sisi teknis. Ada kalanya lo nggak mau orang yang ngerjain sekaligus yang ngecek hasil kerjanya.

Tapi ada rambu besarnya. Dari 1.642 jejak eksekusi multi-agent yang dianalisis di paper Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657), angka kegagalannya berkisar 41% sampai 86,7% di tujuh framework yang diuji. Yang menarik, kegagalannya bukan didominasi model yang kurang pinter: 41,8% masalahnya ada di desain sistem, 36,9% di ketidaksinkronan antar agent, dan 21,3% di verifikasi tugas. Artinya, kalo sistem multi-agent lo gagal, kemungkinan besar yang salah adalah arsitekturnya, bukan modelnya.

Bagian 1: Arsitektur Bisnis, Layer per Layer

Ini bagian yang paling sering dilompati, padahal di sinilah keputusan mahal diambil. Ada lima layer yang gue urutkan dari yang paling dekat ke proses kerja sampai yang paling dekat ke angka.

Layer 1: Proses, potong value stream jadi unit kerja

Sebelum mikir model atau framework, potong dulu kerjaannya. Anthropic ngasih patokan kasar yang berguna buat dijadikan titik awal: pencarian fakta sederhana cukup 1 agent dengan 3 sampai 10 panggilan tool, perbandingan langsung butuh 2 sampai 4 subagent dengan 10 sampai 15 panggilan masing-masing, dan riset kompleks bisa pakai lebih dari 10 subagent.

Yang perlu lo putusin di layer ini: unit kerja mana yang hasilnya bisa berdiri sendiri, dan unit mana yang wajib digabung karena saling bergantung. Salah potong di sini bikin layer di atasnya kacau semua.

Layer 2: Peran dan tanggung jawab

Di multi-agent, peran bukan cuma pembagian kerja, tapi pembagian konteks. Ada dua pola besar yang muncul di lapangan. Pertama, agent utama sebagai koordinator yang manggil worker sebagai tool, dan worker-nya nggak punya memori lintas tugas. Kedua, handoff, di mana satu agent menyerahkan kendali ke agent lain yang jadi pemilik tugas berikutnya.

Yang sering kelewat: peran harus jelas soal apa yang bukan jadi tanggung jawabnya. Agent verifikator yang boleh ikut nulis hasil akhir, misalnya, bukan lagi verifikator. Ini mirip pemisahan tugas di organisasi, cuma bedanya di sini pemisahannya ditulis di kode.

Layer 3: Wewenang dan keputusan

Pertanyaan bisnis yang tidak bisa dijawab teknologi: siapa yang berwenang memutuskan, dan tindakan mana yang boleh jalan tanpa persetujuan manusia.

Ada pembeda yang gue pakai terus: tindakan yang bisa dibalik dan tindakan yang tidak. Mengirim ringkasan rapat ke atasan itu bisa dibalik, mentransfer dana tidak. Pola yang paling banyak dipakai di industri adalah agent mengusulkan, manusia memutuskan, dengan pembagian beban yang tidak seimbang: agent ngerjain volume tinggi dan pekerjaan yang bisa dibalik, manusia pegang keputusan bernilai besar dan permanen.

Rambu ini juga ada di regulasi. EU AI Act (Regulation (EU) 2024/1689) mewajibkan sistem AI berisiko tinggi dirancang supaya bisa diawasi manusia secara efektif (Article 14), dan di sisi perlindungan data, GDPR Article 22 ngasih hak buat minta intervensi manusia terhadap keputusan yang murni otomatis dan berdampak signifikan. Untuk yang kerja di sistem yang diawasi, kerangka manajemen risiko model yang lebih tua pun tetap relevan: SR 11-7 dari Federal Reserve (2011) masih jadi rujukan soal dokumentasi, validasi, dan tinjauan independen.

Layer 4: Governance dan jejak audit

Kalo agent ngambil keputusan, pertanyaan auditornya sederhana: mana buktinya, dan bisa dijelaskan nggak langkahnya.

Di sistem multi-agent, ini jadi lebih rumit karena keputusannya tersebar di beberapa agent. Karena itu, dua hal yang harus didesain dari awal, bukan ditempel belakangan: jejak langkah per agent dan alasan di balik tiap handoff. EU AI Act Article 12 nyebut kewajiban pencatatan log otomatis untuk sistem berisiko tinggi, dan secara praktis itu artinya lo butuh jejak yang bisa direkonstruksi: siapa narik data apa, tool mana yang dipanggil, hasil apa yang balik, dan keputusan apa yang diambil.

Sebagai kerangka kerja, NIST AI Risk Management Framework yang dirilis Januari 2023 (dan profil khusus AI generatif, NIST AI 600-1, Juli 2024) menyediakan empat fungsi yang enak dipakai buat nata governance: govern, map, measure, manage. Sifatnya sukarela, tapi strukturnya membantu pas lo harus nunjukin ke pihak ketiga bahwa risikonya dikelola, bukan diabaikan.

Layer 5: Ekonomi per task

Multi-agent itu keputusan ekonomi, bukan keputusan gengsi. Datanya cukup keras.

Sistem multi-agent Anthropic pakai sekitar 15x token dibanding chat, sementara agent tunggal sekitar 4x. Di temuan mereka, pemakaian token sendirian bisa menjelaskan 80% variansi performa. Artinya, sebagian keunggulan multi-agent itu sebenarnya datang dari tambahan komputasi, bukan dari keajaiban arsitektur. Ada juga studi yang lebih baru: ketika anggaran token disamakan, single agent setara atau lebih baik di tugas penalaran bertahap (arXiv:2604.02460).

Satu temuan lagi yang gue suka karena jujur: dalam eksperimen terkontrol soal struktur tim agent, nambah satu lapis supervisor (atasan yang cuma mengawasi) menaikkan biaya token 51,5% tanpa kenaikan mutu. Kalimat penulisnya yang gue kutip karena dalam banget: supervisor baru layak bayar dirinya sendiri ketika dia bisa memverifikasi, dan jadi beban ketika dia cuma bisa berpendapat.

Jadi pertanyaan di layer ini bukan “berapa harga tokennya”, tapi: kerjaan ini nilainya cukup tinggi nggak buat nanggung biaya 4x sampai 15x, dan ada nggak bagian yang cukup harus dipisah sampai biaya itu wajar.

Bagian 2: Arsitektur Teknologi, Layer per Layer

Kalo sisi bisnis ngatur apa yang boleh dan seberapa jauh, sisi teknologi ngatur gimana jalannya. Tujuh layer dari bawah ke atas.

Layer 1: Model

Layer ini soal siapa yang mikir, dan seberapa mahal otaknya. Pola yang terbukti di sistem riset Anthropic: model besar sebagai lead, model lebih murah dan cepat sebagai subagent pelaksana. Bukan karena model murah lebih pinter, tapi karena pekerjaan tiap agent beda bobotnya.

Praktiknya, layer model butuh routing: klasifikasi tugas dulu, baru pilih model. Tugas yang butuh penalaran panjang dikasih model besar, tugas ekstraksi dan format dikasih model kecil. Tanpa routing, biaya multi-agent bakal nembus plafon lebih cepat dari yang lo kira.

Layer 2: Orkestrasi

Ini jantungnya. Orkestrasi nentuin siapa manggil siapa, kapan selesai, dan apa yang dikirim antar agent.

Banyak framework udah sadar masalah ini dari awal, jadi mereka include solusinya dengan bentuk yang beda-beda. Beberapa pola yang sekarang jadi istilah standar: subagents (agent utama manggil worker sebagai tool), handoffs (satu agent nyerahin tugas ke agent lain), router (satu pintu yang nentuin agent mana yang ngerjain), dan workflow eksplisit (alurnya ditulis, bukan dinamis). Semua punya trade-off masing-masing, dan nggak ada satu yang menang di semua kasus.

Sisi ekosistemnya bergerak cepat, jadi gue catat statusnya per September 2026 biar lo nggak ngejar dokumen basi:

Dua catatan biar adil: tabel ini bukan peringkat, dan framework bukan penentu sukses. Yang lebih nentuin adalah kejelasan peran, pembagian konteks, dan disiplin evaluasi. Ganti framework nggak akan benerin desain yang salah.

Layer 3: Protokol

Kalo orkestrasi itu soal koordinasi, protokol itu soal bahasa. Ada dua protokol yang sekarang jadi rujukan dan perannya beda.

MCP (Model Context Protocol) menyambungkan agent ke tools dan data. Arsitekturnya host, client, dan server: host adalah aplikasi AI-nya, host bikin satu client untuk tiap server, dan server yang mengekspos tools, resources, serta prompts. Spesifikasi terbaru saat artikel ini ditulis adalah versi 2026-07-28, dan protokolnya sekarang stateless: tiap request bawa versi protokol serta capability yang dibutuhkan. Catatan penting buat yang ngikutin dokumentasi lama: primitif sampling dan logging di sisi client sudah ditandai usang.

A2A (Agent2Agent) menyambungkan agent ke agent. Diperkenalkan Google pada April 2025, lalu diserahkan ke Linux Foundation pada Juni 2025, dengan spesifikasi versi terbaru 1.0.0. Cara paling gampang ngebedain keduanya datang dari dokumentasi A2A sendiri: MCP itu lapisan integrasi vertikal yang nyambungin agent ke tools dan database, sementara A2A itu protokol horizontal yang bikin agent bisa berkolaborasi sebagai peer, walau dibangun dengan framework yang beda.

Soal tata kelolanya, MCP diserahkan ke Agentic AI Foundation di bawah Linux Foundation pada Desember 2025, bareng goose dan AGENTS.md sebagai proyek awal. A2A menyusul masuk yayasan yang sama pada Agustus 2026. Buat yang kerja di enterprise, ini kabar bagus: protokol yang dipakai sehari-hari punya rumah netral, bukan dikendalikan satu vendor.

Layer 4: Memory dan state

Di sini banyak sistem multi-agent jatuh. Memory jangka pendek itu context window: instruksi, hasil tool, dan alasan di balik keputusan. Karena tiap agent punya context window sendiri, yang harus lo rancang adalah apa yang dikirim antar agent.

Prinsipnya sederhana tapi sering dilanggar: bagikan konteks, bukan cuma pesan terakhir. Tulisan Cognition soal kenapa mereka menghindari arsitektur multi-agent menjelaskannya dengan tajam: kalo tiap agent cuma nerima potongan percakapan, keputusan yang diambil di satu tempat bisa bentrok sama keputusan di tempat lain, dan hasil akhirnya jadi rapuh. Mereka bahkan menganjurkan default-nya adalah agent linier single-threaded, kecuali kerjaannya jelas-jelas bisa diparalelkan.

Karena itu, pola shared scratchpad atau state graph yang eksplisit lebih aman daripada sekadar oper pesan. Untuk yang butuh memori lintas sesi, simpan di luar context window, dan perlakukan sebagai data yang perlu versi, bukan tempelan.

Layer 5: Tool dan eksekusi

Ini layer paling berbahaya, karena di sini agent bisa ngerubah sesuatu di dunia nyata. Tiga hal yang wajib ada.

Pertama, batas kemampuan yang sempit. Setiap agent cuma dikasih tools yang dia butuh, bukan seluruh katalog perusahaan. Kedua, idempotency atau pengaman serupa, supaya retry nggak bikin aksi dobel. Ketiga, guardrail eksplisit di input dan output, karena validasi yang cuma ada di prompt itu mudah sekali terlewati.

Desain MCP sendiri ngasih pelajaran soal ini: server hanya mengekspos tools, resources, dan prompts, dan server nggak bisa baca seluruh percakapan. Pemisahan itu bukan kerumitan, tapi pengaman.

Layer 6: Observability dan evaluasi

Kalo layer tool itu tentang mencegah hal buruk, layer ini tentang tahu bahwa hal buruk sudah terjadi. Di sistem satu agent, lo bisa baca satu log. Di sistem multi-agent, lo butuh jejak per agent, urutan handoff, plus biaya token per langkah.

Sebagian sudah disediakan framework: OpenAI Agents SDK punya tracing bawaan, dan ekosistem LangChain punya tool observability. Tapi yang paling penting, evaluasi jangan cuma di output akhir. Kategori kegagalan dari paper arXiv:2503.13657 bisa dipakai sebagai checklist: desain sistem, ketidaksinkronan antar agent, dan verifikasi tugas. Kalo sistem lo gagal di salah satu kategori itu, memperbaiki prompt output akhir nggak akan nolong.

Layer 7: Runtime dan infrastruktur

Layer terakhir yang sering dianggap remeh: di mana prosesnya jalan, seberapa banyak yang jalan bersamaan, dan siapa yang bayar kalau terjadi lonjakan.

Minimal tiga hal: batas konkurensi (berapa agent boleh hidup bareng), batas pengeluaran per tugas, dan isolasi kegagalan (satu agent yang mati nggak boleh bikin seluruh alur mandek). Beberapa SDK sudah nyediain pengaman ini di level konfigurasi, misalnya batas kedalaman subagent dan batas pengeluaran tiap query di Claude Agent SDK. Prinsipnya sama kayak sistem lain: batas harus dikonfigurasi, bukan diwariskan ke niat baik.

Kapan Multi-Agent Menang dan Kapan Kalah

Ini ringkasan bukti yang gue kumpulin, biar lo bisa nentuin posisi sendok sendiri tanpa harus hafal nama framework.

Kalo lo cuma bawa satu kalimat dari artikel ini, bawa ini: multi-agent menang di kerjaan yang bisa dipecah, berjalan paralel, dan cukup bernilai buat nanggung biaya tambahannya. Di luar itu, satu agent dengan konteks yang bersih lebih sering jadi pilihan yang lebih murah dan lebih gampang dijaga.

Pola Bertahap: Naik Level Kalo Sinyalnya Udah Muncul

Biar nggak bingung mulai dari mana, ini urutan yang gue pakai.

Tahap 1, satu agent plus tools. Agent tunggal dengan tools yang cukup dan konteks yang dijaga rapi. Ini tahap yang paling sering udah cukup: satu pemilik, satu log, satu titik yang bisa di-debug. Sinyal buat naik: konteks mulai sering penuh, dan mutu jawaban turun di akhir sesi panjang.

Tahap 2, workflow eksplisit. Alur dipecah jadi beberapa langkah yang ditulis jelas di kode, tiap langkah bisa pakai panggilan model yang beda. Belum multi-agent dalam arti tim, tapi udah memisahkan tanggung jawab. Sinyal buat naik: ada bagian alur yang bisa jalan paralel dan independen satu sama lain.

Tahap 3, tim agent dengan lead dan worker. Lead agent memecah tugas, subagent ngerjain bagian spesifik secara paralel, dan satu lapisan verifikasi memeriksa hasilnya. Wajib ada di tahap ini: jejak audit per agent, batas pengeluaran, batas konkurensi, dan gate keputusan manusia buat tindakan yang nggak bisa dibalik. Sinyal buat turun lagi ke tahap sebelumnya: biaya naik sementara mutunya nggak bergerak, atau kegagalan yang muncul hampir semuanya di kategori desain sistem.

Kesimpulan

Multi-agent bukan versi upgrade dari agent tunggal, tapi satu bentuk organisasi: ada pembagian kerja, ada wewenang, ada biaya overhead, dan ada titik gagal yang baru. Yang bikin dia jalan bukan jumlah agentnya, tapi kejelasan peran, disiplin membagi konteks, dan kemauan ngecek biaya serta mutunya pakai angka. Sebaliknya, kebanyakan kegagalan datang dari desain sistem, bukan dari model yang kurang pintar.

Terima kasih sudah baca sampai sini. Kalo lo sedang nimbang mau naik dari satu agent ke banyak agent, mulai dari yang paling murah dulu: benerin dulu konteks dan perannya, karena dua itu yang paling sering jadi akar masalahnya.

Sumber

• Anthropic, Building Effective Agents (Desember 2024) - https://www.anthropic.com/engineering/building-effective-agents
• Anthropic, How we built our multi-agent research system (2025) - https://www.anthropic.com/engineering/multi-agent-research-system
• Cognition, Don’t Build Multi-Agents (2025) - https://cognition.ai/blog/dont-build-multi-agents
• Why Do Multi-Agent LLM Systems Fail? - https://arxiv.org/abs/2503.13657
• Towards a Science of Scaling Agent Systems - https://arxiv.org/abs/2512.08296
• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets - https://arxiv.org/abs/2604.02460
• Loop-Back Authority in LLM Agent Teams - https://arxiv.org/abs/2609.14767
• Model Context Protocol, spesifikasi versi 2026-07-28 - https://modelcontextprotocol.io/specification/2026-07-28
• A2A Protocol, spesifikasi versi 1.0.0 - https://a2a-protocol.org/latest/specification/
• Linux Foundation, pembentukan Agentic AI Foundation (Desember 2025) - https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• OpenAI Agents SDK - https://openai.github.io/openai-agents-python/
• Microsoft Agent Framework - https://learn.microsoft.com/en-us/agent-framework/
• Claude Agent SDK - https://docs.claude.com/en/api/agent-sdk/overview
• LangChain, pola multi-agent - https://docs.langchain.com/oss/python/langchain/multi-agent
• CrewAI, konsep proses - https://docs.crewai.com/concepts/processes
• Google ADK, workflow - https://google.github.io/adk-docs/workflows/
• EU AI Act, Regulation (EU) 2024/1689 - https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401689
• NIST AI Risk Management Framework - https://www.nist.gov/itl/ai-risk-management-framework
• Federal Reserve, SR 11-7 - https://www.federalreserve.gov/boarddocs/srletters/2011/sr1107.htm