Multi-Agent AI: Kapan Enterprise Membutuhkan Lebih dari Satu AI Agent?

Ada kecenderungan menarik dalam perkembangan AI enterprise: ketika satu AI agent mulai dapat melakukan semakin banyak pekerjaan, perusahaan justru mulai bertanya apakah satu agent sebaiknya melakukan semuanya.

Sekilas jawabannya terlihat sederhana. Jika satu agent sudah dapat memahami instruksi, menggunakan tools, mengambil keputusan, dan menjalankan workflow, mengapa harus menambah beberapa agent?

Masalahnya muncul ketika proses bisnis mulai kompleks.

Sebuah proses procurement, misalnya, mungkin membutuhkan agent untuk membaca dokumen, agent lain untuk memeriksa policy, agent lain untuk melakukan analisis vendor, dan sistem lain untuk melakukan approval. Dalam kondisi seperti ini, memaksa satu agent menangani seluruh pekerjaan dapat membuat context, permission, tools, dan tanggung jawabnya menjadi terlalu luas.

Di sinilah konsep multi-agent AI menjadi relevan.

Google Cloud mendeskripsikan multi-agent system sebagai pendekatan di mana beberapa agent AI bekerja sama untuk menyelesaikan tugas yang lebih kompleks, dengan masing-masing agent dapat memiliki kemampuan, tools, atau tanggung jawab tertentu. (cloud.google.com)

Namun, semakin banyak agent bukan berarti sistem otomatis menjadi lebih baik.

Multi-agent AI membawa konsekuensi baru: orchestration, communication, security, observability, latency, cost, dan failure propagation.

Karena itu, pertanyaan enterprise seharusnya bukan:

“Bagaimana kita membuat sebanyak mungkin AI agent?”

Melainkan:

“Pada titik mana sebuah workflow menjadi cukup kompleks sehingga membutuhkan lebih dari satu agent?”

Multi-Agent AI Berbeda dari Sekadar Banyak AI Tool

Sebuah aplikasi dapat menggunakan beberapa model AI tanpa menjadi multi-agent system.

Misalnya aplikasi customer service menggunakan satu LLM untuk menjawab pertanyaan dan sebuah search engine untuk mencari informasi. Itu belum tentu multi-agent.

Dalam multi-agent architecture, beberapa agent memiliki peran atau kemampuan yang relatif berbeda dan dapat berinteraksi untuk menyelesaikan tujuan tertentu.

Contoh sederhananya:

User Request → Orchestrator Agent → Specialist Agents → Validation → Final Result

Specialist agent dapat memiliki fungsi seperti:

• Data retrieval
• Financial analysis
• Document processing
• Policy checking
• Customer communication
• Planning
• Validation

Masing-masing tidak harus menggunakan model yang berbeda. Yang membedakan adalah responsibility dan boundary.

Google Cloud memberikan pola arsitektur multi-agent seperti centralized orchestration, decentralized collaboration, dan hierarchical systems untuk menangani kebutuhan workflow yang berbeda. (cloud.google.com)

Artinya, multi-agent AI sebenarnya lebih dekat dengan persoalan system architecture daripada sekadar persoalan prompt engineering.

Mengapa Satu Agent Tidak Selalu Cukup?

Satu agent memang memiliki keunggulan.

Architecture-nya lebih sederhana. Context lebih mudah dikelola. Debugging lebih mudah. Latency dapat lebih rendah. Permission dan monitoring juga relatif lebih sederhana.

Untuk workflow sederhana, pendekatan single-agent bahkan dapat menjadi pilihan yang lebih masuk akal.

Masalah muncul ketika agent mulai memiliki terlalu banyak tanggung jawab.

Bayangkan sebuah agent yang memiliki akses ke:

ERP + CRM + database finance + email + document repository + procurement system + analytics platform.

Secara teknis mungkin memungkinkan.

Tetapi dari perspektif enterprise security, muncul pertanyaan penting:

Apakah agent tersebut benar-benar membutuhkan semua akses itu?

Jika tidak, mengapa permission-nya dibuat seluas itu?

Jika agent melakukan kesalahan, sistem mana yang terdampak?

Jika output-nya salah, siapa yang bertanggung jawab?

Semakin besar capability sebuah agent, semakin besar pula blast radius ketika terjadi kesalahan.

Multi-agent architecture dapat digunakan untuk membatasi tanggung jawab tersebut dengan memberikan kemampuan tertentu kepada agent tertentu.

Kapan Multi-Agent AI Mulai Masuk Akal?

Tidak semua workflow membutuhkan multi-agent.

Salah satu indikator paling penting adalah task decomposition.

Jika sebuah pekerjaan dapat dipecah menjadi beberapa aktivitas yang relatif independen dan masing-masing membutuhkan capability berbeda, multi-agent architecture mulai menjadi kandidat.

Misalnya proses berikut:

Sales Request → Customer Verification → Pricing Analysis → Credit Check → Approval → Order Creation

Memaksakan seluruh proses ke satu agent berarti agent tersebut membutuhkan akses dan kemampuan yang sangat luas.

Sebaliknya, architecture dapat memisahkan tanggung jawab:

Sales Agent → Verification Agent → Pricing Agent → Credit Agent → Approval Workflow

Setiap komponen memiliki boundary yang lebih jelas.

Tetapi decomposition saja belum cukup.

Ada beberapa kondisi lain yang perlu diperhatikan.

Ini bukan scoring universal. Enterprise tetap perlu melihat karakteristik workload dan risk profile masing-masing.

Specialist Agent: Membagi Tanggung Jawab, Bukan Sekadar Membagi Pekerjaan

Salah satu alasan paling kuat menggunakan multi-agent AI adalah specialization.

Bayangkan sebuah enterprise memiliki agent bernama Finance Agent.

Agent tersebut hanya bertanggung jawab pada financial analysis. Ia dapat memiliki akses ke financial data, accounting rules, dan calculation tools yang relevan.

Agent lain bernama Procurement Agent menangani vendor information dan procurement policy.

Keduanya dapat bekerja dalam satu workflow tanpa harus memberikan seluruh akses kepada satu agent.

Keuntungannya bukan hanya pembagian pekerjaan.

Specialization juga dapat membantu menciptakan security boundary dan responsibility boundary.

Misalnya:

Finance Agent
→ financial database
→ financial calculation tools
→ finance policy

Procurement Agent
→ vendor database
→ procurement system
→ purchasing policy

Communication Agent
→ email
→ notification
→ customer communication

Jika Communication Agent tidak membutuhkan akses ke financial database, maka tidak ada alasan arsitektural untuk memberikannya akses tersebut.

Dalam enterprise, prinsip seperti ini sangat dekat dengan konsep least privilege: sebuah component hanya mendapatkan akses yang diperlukan untuk menjalankan tugasnya.

OWASP juga menempatkan excessive agency sebagai salah satu risiko penting dalam aplikasi LLM, termasuk ketika AI agent memiliki terlalu banyak functionality, permission, atau autonomy. (owasp.org)

Dengan demikian, multi-agent architecture dapat menjadi salah satu cara untuk membatasi agency berdasarkan fungsi.

Tetapi Multi-Agent Juga Menambah Kompleksitas

Ada sisi lain yang tidak boleh diabaikan.

Ketika satu agent dipecah menjadi lima agent, enterprise tidak hanya mendapatkan lima kali kemampuan.

Enterprise juga mendapatkan lebih banyak interaction points.

Misalnya:

Agent A → Agent B → Agent C → Agent D

Jika Agent B menghasilkan output yang salah, Agent C mungkin tetap menggunakannya.

Kesalahan tersebut kemudian diteruskan ke Agent D.

Inilah yang dapat disebut sebagai failure propagation.

Selain itu, communication antar-agent membutuhkan mekanisme yang jelas.

Apa format input dan output?

Bagaimana agent mengetahui context?

Bagaimana memastikan agent tidak melakukan pekerjaan yang sama?

Bagaimana menangani timeout?

Bagaimana jika salah satu agent gagal?

Bagaimana sistem melakukan retry?

Bagaimana manusia melakukan override?

Pertanyaan tersebut membuat multi-agent AI lebih dekat dengan distributed systems engineering daripada sekadar implementasi chatbot.

Orchestration Menjadi Komponen Penting

Ketika terdapat beberapa agent, enterprise membutuhkan mekanisme untuk menentukan siapa melakukan apa dan kapan.

Inilah fungsi orchestration.

Orchestrator dapat menerima tujuan dari user, memecah pekerjaan, memilih agent yang relevan, mengirim context, menerima hasil, melakukan validation, kemudian menentukan langkah berikutnya.

Arsitektur sederhananya:

User

↓

Orchestrator

↓

Specialist Agent A + Specialist Agent B + Specialist Agent C

↓

Validation / Human Approval

↓

Business System

Dalam beberapa workflow, agent dapat bekerja secara sequential.

Dalam workflow lain, beberapa agent dapat berjalan secara paralel.

Misalnya untuk mengevaluasi calon vendor:

Vendor Agent → Company Profile

Finance Agent → Financial Data

Risk Agent → Risk Indicators

Ketiganya dapat menghasilkan analisis masing-masing sebelum orchestrator menggabungkannya menjadi satu output.

Google Cloud menjelaskan pola orchestration sebagai salah satu pendekatan penting dalam desain multi-agent system dan menekankan bahwa pola tersebut perlu disesuaikan dengan workflow serta tingkat kompleksitas yang dihadapi. (cloud.google.com)

Jangan Memberikan Autonomy Lebih Besar dari yang Dibutuhkan

Dalam sistem enterprise, kemampuan agent bukan satu-satunya parameter.

Permission dan autonomy sama pentingnya.

Ada perbedaan besar antara agent yang:

“Memberikan rekomendasi purchase order.”

dan agent yang:

“Membuat serta mengirim purchase order.”

Yang pertama menghasilkan informasi.

Yang kedua melakukan tindakan terhadap sistem bisnis.

Semakin dekat agent terhadap tindakan yang memiliki konsekuensi nyata, semakin penting approval, validation, auditability, dan access control.

OWASP memasukkan excessive agency sebagai risiko ketika LLM-based system diberikan functionality, permission, atau autonomy yang tidak diperlukan. Risiko dapat muncul ketika model melakukan tindakan di luar intended scope atau ketika output yang salah menghasilkan tindakan yang tidak diinginkan. (owasp.org)

Karena itu, multi-agent architecture sebaiknya tidak dipahami sebagai cara untuk membuat AI semakin autonomous.

Dalam banyak kasus, justru tujuannya adalah membuat autonomy lebih terkontrol.

Bagaimana dengan Cost dan Latency?

Ada trade-off lain yang sangat praktis.

Jika sebuah workflow menggunakan lima agent, mungkin terdapat lima atau lebih model invocation.

Setiap invocation dapat menambah:

Token usage → Latency → Infrastructure cost → Monitoring complexity

Jika seluruh workflow sebenarnya dapat diselesaikan oleh satu agent dengan kualitas yang sama, multi-agent architecture justru dapat menjadi overengineering.

Karena itu, perusahaan perlu membandingkan setidaknya tiga pendekatan:

Tidak ada architecture yang selalu paling tepat.

Kompleksitas architecture harus sebanding dengan kompleksitas masalah yang ingin diselesaikan.

Multi-Agent AI Membutuhkan Observability

Pada aplikasi tradisional, ketika transaksi gagal, engineer dapat melihat log service, database, API request, dan error trace.

Multi-agent system menambahkan lapisan baru.

Sekarang perusahaan perlu mengetahui:

Agent mana yang dipanggil?

Tool apa yang digunakan?

Context apa yang diberikan?

Keputusan apa yang dibuat?

Output apa yang dihasilkan?

Berapa lama proses berlangsung?

Berapa biaya inference?

Di titik mana workflow gagal?

Tanpa observability, debugging dapat menjadi sangat sulit.

Enterprise karena itu perlu memperlakukan agent interaction sebagai bagian dari system telemetry.

Log, trace, metrics, tool invocation, approval events, dan outcome perlu dapat ditelusuri.

Ini juga penting untuk audit.

Jika AI melakukan tindakan terhadap sistem bisnis, perusahaan seharusnya dapat menjawab pertanyaan sederhana:

“Mengapa tindakan ini terjadi?”

Kapan Sebaiknya Tidak Menggunakan Multi-Agent?

Justru ini bagian yang sering hilang dalam pembahasan AI.

Multi-agent bukan tujuan.

Jika workflow hanya membutuhkan:

User → AI → Database → Response

maka menambahkan tiga agent mungkin tidak memberikan manfaat yang sepadan.

Single agent dengan tools, structured output, permission yang tepat, dan validation layer mungkin sudah cukup.

Multi-agent mulai lebih masuk akal ketika terdapat kombinasi:

Complex workflow + multiple domains + specialist capabilities + differentiated permissions + meaningful business impact.

Jika kompleksitas tersebut belum ada, architecture sederhana biasanya lebih mudah dioperasikan.

Prinsip ini penting karena enterprise tidak hanya membangun prototype.

Enterprise harus memikirkan operational lifecycle.

AI agent yang terlihat impresif dalam demo belum tentu menjadi architecture yang baik ketika harus berjalan 24/7, terintegrasi dengan ERP, CRM, finance system, document repository, dan berbagai application lainnya.

Dari AI Agent ke Enterprise System

Inilah alasan mengapa multi-agent AI sebaiknya tidak dibangun sebagai fitur AI yang berdiri sendiri.

Agent pada akhirnya perlu berinteraksi dengan business system.

Agent membutuhkan data.

Agent membutuhkan permission.

Agent menggunakan API.

Agent menghasilkan action.

Agent membutuhkan audit trail.

Dengan kata lain, semakin kompleks penggunaan AI, semakin penting architecture sistem di bawahnya.

Jika data enterprise masih tersebar, API belum terstruktur, business rules hanya tersimpan di aplikasi lama, atau permission model tidak jelas, menambahkan banyak AI agent tidak otomatis menyelesaikan masalah tersebut.

Justru agent dapat memperbesar dampaknya.

Karena itu, perusahaan yang ingin membangun agentic workflow sering kali perlu melihat kembali integration dan architecture existing. Pendekatan seperti Enterprise System Upgrade dari Crocodic dapat relevan ketika sistem existing perlu diperkuat agar mampu mendukung integration, automation, dan kemampuan baru tanpa harus selalu membangun ulang seluruh platform.

Untuk sistem yang memang membutuhkan perubahan lebih fundamental, Custom Enterprise Software memungkinkan architecture, workflow, integration, dan AI capability dirancang berdasarkan kebutuhan bisnis sejak awal.

Bagaimana Enterprise Menentukan Architecture yang Tepat?

Sebelum membuat multi-agent system, gunakan urutan berpikir yang sederhana:

1. Definisikan business outcome.

Apa yang sebenarnya ingin diperbaiki?

2. Pecah workflow.

Aktivitas apa saja yang diperlukan untuk menghasilkan outcome tersebut?

3. Identifikasi capability.

Apakah setiap aktivitas membutuhkan kemampuan, data, atau tools yang berbeda?

4. Tentukan permission boundary.

Apakah setiap capability membutuhkan akses terhadap data dan sistem yang berbeda?

5. Evaluasi single-agent architecture.

Apakah satu agent sebenarnya masih dapat menyelesaikan workflow secara aman dan efektif?

6. Baru pertimbangkan multi-agent.

Jika specialization, isolation, parallelization, atau domain separation memberikan manfaat nyata, multi-agent dapat menjadi pilihan.

Urutan ini mencegah perusahaan terjebak dalam pola pikir:

“Kita punya AI agent, sekarang semua proses harus dibuat multi-agent.”

Sebaliknya, architecture mengikuti kebutuhan bisnis.

Multi-Agent AI Bukan Tentang Memiliki Lebih Banyak Agent

Perkembangan AI membuat perusahaan semakin mampu mengotomasi pekerjaan yang sebelumnya membutuhkan banyak interaksi manusia.

Tetapi ketika workflow menjadi semakin kompleks, pertanyaan architecture menjadi semakin penting.

Satu agent mungkin cukup untuk workflow sederhana.

Beberapa agent mungkin lebih tepat ketika pekerjaan membutuhkan specialization, domain separation, parallel processing, atau permission boundary.

Namun setiap agent tambahan juga membawa cost: lebih banyak communication, lebih banyak failure point, lebih banyak monitoring, lebih banyak security boundary, dan lebih banyak hal yang harus dioperasikan.

Karena itu, ukuran keberhasilan multi-agent AI bukanlah jumlah agent yang berhasil dibuat.

Ukuran yang lebih relevan adalah apakah architecture tersebut membuat proses bisnis:

lebih terkontrol, lebih dapat diaudit, lebih aman, dan benar-benar menghasilkan outcome yang lebih baik.

Pada akhirnya, multi-agent AI adalah persoalan system design.

AI agent hanyalah salah satu komponen.

Yang menentukan apakah teknologi tersebut benar-benar siap digunakan di enterprise adalah bagaimana agent tersebut ditempatkan di dalam architecture yang mencakup data, API, business rules, permission, security, human approval, observability, dan existing business systems.

Perusahaan tidak membutuhkan AI yang paling kompleks.

Perusahaan membutuhkan architecture yang cukup kompleks untuk menyelesaikan masalah yang memang kompleks—dan cukup sederhana untuk tetap dapat dikendalikan.

Untuk enterprise yang sedang mengevaluasi penggunaan AI agent dalam proses bisnis, langkah awal yang lebih penting daripada menentukan jumlah agent adalah memetakan workflow, data, integration, permission, dan business outcome. Dari sana, architecture dapat menentukan apakah solusi yang tepat adalah single agent, agent dengan tools, atau multi-agent system.

AI dapat bekerja sebagai satu agent. Tetapi ketika bisnis menjadi kompleks, yang lebih penting bukan berapa banyak agent yang digunakan—melainkan bagaimana seluruh agent tersebut tetap bekerja sebagai satu sistem bisnis yang terkendali.