Apa Itu Protokol Agent2Agent (A2A)? Cara Agen AI Berkomunikasi Satu Sama Lain

Mengapa A2A Ada: Masalah Silo

Gelombang pertama produk AI generatif adalah asisten, yaitu satu model yang menjawab satu orang. Gelombang kedua adalah agen, sistem yang merencanakan, menggunakan alat, dan melakukan pekerjaan multi-langkah. Seiring semakin banyaknya agen yang digunakan organisasi, muncul masalah yang dapat diprediksi. Setiap agen dibangun dengan framework, konvensi, dan cara pemanggilan yang berbeda. Agen yang dapat berkolaborasi secara produktif akhirnya terisolasi, seperti departemen yang masing-masing menggunakan bahasa yang berbeda.

Tanpa standar, hanya ada pilihan yang tidak menarik. Tim dapat membangun integrasi point-to-point, yang berarti ledakan kode kustom seiring bertambahnya jumlah agen. Mereka dapat mengunci diri ke dalam ekosistem vendor tunggal sehingga setiap agen berbicara dialek yang sama, yang mengorbankan pilihan dan mengabaikan kenyataan bahwa agen yang berguna berasal dari banyak sumber. Atau mereka dapat meratakan semuanya menjadi satu agen monolitik, yang menjadi sulit dikelola dan mengabaikan manfaat spesialisasi.

A2A mengambil pendekatan yang sama yang membuat web sukses. Alih-alih membuat setiap sistem identik, ia menstandarisasi antarmuka di antara sistem-sistem tersebut. Sebuah agen tetap bebas untuk dibangun sesuai keinginan penciptanya, menggunakan model, framework, atau bahasa apa pun, selama ia dapat menampilkan dirinya dan berkomunikasi melalui protokol bersama. Pemisahan implementasi internal dari antarmuka eksternal inilah yang memungkinkan interoperabilitas tanpa keseragaman.

Bagaimana A2A Bermula dan Siapa yang Menjalankannya Sekarang

Dari Pengumuman Google hingga Proyek Linux Foundation

Google mengumumkan protokol Agent2Agent pada 9 April 2025, di konferensi Cloud Next, dengan dukungan dari lebih dari lima puluh mitra teknologi. Dukungan awal tersebut menandakan bahwa masalah ini dirasakan secara luas di seluruh industri. Hanya lebih dari dua bulan kemudian, pada 23 Juni 2025, Google menyumbangkan protokol tersebut ke Linux Foundation, yang meluncurkan proyek Agent2Agent untuk memberikan tata kelola netral vendor. Langkah ini mengatasi kekhawatiran yang jelas, yaitu standar komunikasi yang dimiliki oleh satu perusahaan merupakan fondasi yang lebih lemah untuk ekosistem daripada standar yang tidak dikendalikan oleh perusahaan mana pun.

Spesifikasi 1.0

Spesifikasi ini berkembang melalui beberapa versi awal, termasuk 0.1, 0.2, dan 0.3, sebelum mencapai rilis stabil 1.0 pada tahun 2026. Versi 1.0 menjadikan definisi Protocol Buffers sebagai sumber kebenaran normatif untuk semua cara membawa protokol, mengganti nama operasi inti menjadi kosakata yang lebih jelas seperti SendMessage, GetTask, dan CancelTask, dan menambahkan operasi ListTasks. Kode dan spesifikasi dilisensikan di bawah Apache 2.0, dan Komite Pengarah Teknis dengan perwakilan dari perusahaan termasuk AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, dan ServiceNow memelihara proyek ini.

Bergabung dengan Agentic AI Foundation

Pada Agustus 2026, A2A mengambil langkah lain dalam tata kelolanya. Protokol ini pindah ke Agentic AI Foundation, atau AAIF, sebuah organisasi di dalam Linux Foundation yang menampung infrastruktur agen terbuka. Hal ini menempatkan A2A di bawah payung yang sama dengan Model Context Protocol, bersama dengan proyek-proyek seperti Block's goose dan konvensi AGENTS.md. Signifikansinya bersifat praktis dan simbolis, yaitu dua protokol terbuka paling terkemuka untuk sistem agen, satu berfokus pada menghubungkan agen ke alat dan satu lagi pada menghubungkan agen satu sama lain, kini berbagi wadah yang sama dan struktur tata kelola netral yang sama, yang seharusnya mempermudah koordinasi di antara keduanya.

Prinsip-Prinsip Desain di Balik A2A

Agen sebagai Kolaborator yang Tidak Transparan
Prinsip terpenting adalah bahwa agen tetap tidak transparan satu sama lain. Ketika satu agen mendelegasikan pekerjaan kepada agen lain melalui A2A, ia tidak melihat bagaimana agen jarak jauh berpikir, alat apa yang dipanggilnya, data apa yang dipegangnya, atau perintah apa yang mengarahkannya. Yang dilihatnya hanyalah apa yang dipilih agen jarak jauh untuk diungkapkan, yaitu deskripsi keterampilannya dan hasil pekerjaannya. Ketidaktransparanan ini melindungi kekayaan intelektual dan keamanan, karena perusahaan dapat menawarkan kemampuan agen tanpa mengungkapkan logika kepemilikan, dan menjaga protokol tetap sederhana, karena kolaborator bertukar hasil daripada detail internal.

Membangun di Atas Standar Web yang Sudah Dikenal

A2A sengaja menghindari menciptakan infrastruktur baru. Ia dibangun di atas teknologi yang sudah dikenal dan diamankan oleh developer dan perusahaan, seperti: HTTP, JSON-RPC, gRPC, dan Server-Sent Events untuk streaming. Otentikasi bergantung pada skema yang sudah mapan daripada hal baru. Karena sesuai dengan jaringan, gateway, dan perangkat keamanan yang ada, A2A lebih mudah diadopsi, lebih mudah dipantau, dan lebih mudah dipertahankan.

Dirancang untuk Pekerjaan Asinkron yang Berlangsung Lama

Tugas agen tidak seperti panggilan API biasa yang kembali dalam hitungan milidetik. Tugas penelitian mungkin memakan waktu beberapa menit, alur kerja pengadaan mungkin menunggu persetujuan manusia selama berhari-hari, dan pekerjaan pemrosesan data mungkin berjalan selama berjam-jam. A2A memperlakukan ini sebagai kasus normal, bukan pengecualian. Model tugasnya memiliki status eksplisit, mendukung pembaruan streaming dan pemberitahuan push, dan memungkinkan tugas untuk berhenti sejenak dan menunggu informasi lebih lanjut dari pemanggil.

Modalitas dan Kesiapan Perusahaan

Agen semakin banyak bekerja dengan lebih dari sekadar teks, sehingga pesan A2A dapat membawa teks, file, dan data terstruktur, dan agen dapat menyatakan format input dan output mana yang mereka dukung. Protokol ini juga mengharapkan realitas perusahaan, seperti: persyaratan otentikasi yang dinyatakan, dukungan untuk skema identitas umum, dan kemampuan untuk berjalan di belakang gateway yang menegakkan kebijakan dan mengumpulkan log.

Konsep Inti A2A

Tiga Aktor

Spesifikasi menjelaskan tiga peran. Pengguna adalah orang atau sistem yang memiliki tujuan. Klien A2A adalah aplikasi atau agen yang bertindak atas nama pengguna, yang memulai komunikasi. Server A2A, juga disebut agen jarak jauh, adalah agen yang menerima permintaan dan melakukan pekerjaan. Peran-peran ini bukanlah identitas tetap: satu agen dapat menjadi server bagi agen yang memanggilnya dan, pada saat yang sama, menjadi klien bagi agen lain yang didelegasikan kepadanya. Fleksibilitas tersebut memungkinkan rantai dan jaringan agen daripada hierarki yang kaku.

Agent Card

Penemuan dalam A2A dimulai dengan Agent Card, dokumen JSON di mana agen menjelaskan dirinya sendiri. Secara konvensional, agen menerbitkan kartu agennya di alamat yang dikenal luas, /.well-known/agent-card.json, di domainnya, sehingga klien yang mengetahui domain tersebut dapat menemukannya, meskipun registri dan mekanisme penemuan lainnya juga dapat digunakan.

Kartu tersebut berfungsi seperti kartu nama yang dikombinasikan dengan katalog layanan. Kartu tersebut berisi nama, deskripsi, dan versi agen; informasi tentang penyedianya; titik akhir yang dapat diakses, beserta pengikatan protokol dan versi yang didukung oleh setiap titik akhir; kemampuannya, seperti apakah mendukung streaming atau notifikasi push; format input dan output yang diterima dan dihasilkannya; keahliannya, yang menjelaskan hal-hal spesifik yang dapat dilakukannya; dan skema keamanan yang harus digunakan oleh pemanggil. Kartu tersebut juga dapat ditandatangani secara digital sehingga klien dapat memverifikasi keasliannya, dan agen dapat menawarkan kartu yang diperluas dengan keahlian tambahan kepada pemanggil yang telah diautentikasi.

Kartu ilustrasi sederhana untuk agen pemesanan penerbangan mungkin terlihat seperti ini:

{
   "name": "Agen Pemesanan Penerbangan Korporat",
   "description": "Menangani reservasi penerbangan domestik dan internasional.",
   "version": "1.0.0",
   "provider": { "organization": "Corp Internal", "url": "https://internal.corp" },
   "supportedInterfaces": [
      { "url": "https://flights.internal.corp/a2a", "protocolBinding": "JSONRPC" }
   ],
   "capabilities": { "streaming": true, "pushNotifications": true },
   "defaultInputModes": ["text/plain", "application/json"],
   "defaultOutputModes": ["text/plain", "application/json"],
   "skills": [
      {
        "id": "book-flight",
       "name": "Pesan penerbangan",
        "deskripsi": "Mencari dan memesan penerbangan dalam polis perjalanan."
      }
   ]
}

Nama dan struktur field di sini disederhanakan untuk ilustrasi, jadi lihat spesifikasi untuk skema resminya.

Pesan dan Bagian-bagiannya

Sebuah pesan adalah satu putaran komunikasi antara klien dan agen. Pesan memiliki peran, yang menunjukkan apakah pesan tersebut berasal dari sisi pengguna atau sisi agen, dan terdiri dari satu atau lebih bagian. Sebuah bagian dapat berupa teks, file, atau data terstruktur. Komposisi ini memungkinkan satu pesan untuk membawa, misalnya, instruksi tertulis bersama dengan spreadsheet terlampir dan blok parameter terstruktur.

Tugas dan Siklus Hidupnya

Ketika sebuah permintaan melibatkan pekerjaan nyata, interaksi tersebut menjadi sebuah tugas, unit tindakan utama dalam A2A. Sebuah tugas memiliki pengidentifikasi dan bergerak melalui serangkaian status yang ditentukan. Tugas dimulai sebagai "dikirim" ketika agen menerimanya, menjadi "sedang dikerjakan" saat agen memprosesnya, dan dapat berhenti pada "diperlukan input" ketika agen membutuhkan informasi lebih lanjut dari pemanggil, atau pada "diperlukan otentikasi" ketika pemanggil harus mengotentikasi sebelum pekerjaan dapat dilanjutkan. Sebuah tugas berakhir dalam salah satu dari empat status terminal: selesai, gagal, dibatalkan, atau ditolak, yang terakhir berarti agen menolak pekerjaan tersebut. Setelah sebuah tugas mencapai status terminal, tugas tersebut tidak lagi menerima pesan.

Status "input-required" adalah salah satu fitur protokol yang paling berguna. Agen jarak jauh yang tidak dapat melanjutkan dapat mengajukan pertanyaan klarifikasi, dan klien menjawab menggunakan pengidentifikasi tugas yang sama, sehingga percakapan berlanjut dalam konteks daripada dimulai dari awal. Konsep terkait, pengidentifikasi konteks, mengelompokkan beberapa tugas dan pesan terkait ke dalam satu interaksi yang sedang berlangsung.

Satu poin halus yang menjebak banyak developer. Permintaan dapat berhasil di tingkat transport sementara tugas itu sendiri gagal. Pesan mencapai agen dan respons kembali, tetapi respons melaporkan bahwa pekerjaan tidak berhasil. Oleh karena itu, klien perlu memeriksa hasil transport dan status tugas.

Artefak

Output dari suatu tugas dikirimkan sebagai artefak. Artefak adalah hasil nyata, seperti dokumen yang dihasilkan, kumpulan data, blok data terstruktur, atau gambar, yang terdiri dari bagian-bagian seperti halnya pesan. Memisahkan artefak dari pesan percakapan menjaga agar hasil akhir tetap jelas berbeda dari proses bolak-balik yang menghasilkannya.

Cara Kerja Pertukaran A2A, Langkah demi Langkah

Dengan menggabungkan konsep-konsep tersebut, interaksi tipikal berlangsung dalam empat tahap.

Pertama, klien menemukan agen. Klien mengambil Agent Card, biasanya dari alamat yang dikenal, dan membaca keterampilan apa yang ditawarkan agen, titik akhir dan pengikatan apa yang didukungnya, dan skema autentikasi apa yang akan digunakan. Klien yang dirancang dengan baik menggunakan informasi ini untuk memutuskan apakah agen ini sesuai untuk pekerjaan tersebut dan bagaimana cara terhubung.

Kedua, klien melakukan autentikasi dan mengirim pesan. Klien memanggil operasi SendMessage, mengirimkan pesan dengan satu atau lebih bagian, bersama dengan kredensial sesuai dengan skema keamanan yang dideklarasikan agen. Untuk permintaan sederhana, agen dapat langsung merespons dengan pesan langsung. Untuk pekerjaan yang substansial, agen merespons dengan membuat tugas dan mengembalikan pengidentifikasi dan statusnya.

Ketiga, klien mengikuti tugas tersebut. Tergantung pada apa yang didukung agen dan preferensi klien, agen dapat melakukan polling untuk mengetahui status terkini dengan memanggil GetTask, berlangganan aliran pembaruan yang dikirimkan melalui Server-Sent Events (SET) seiring berjalannya tugas, atau mendaftarkan alamat webhook sehingga agen dapat mengirimkan notifikasi ketika sesuatu yang penting terjadi. Jika tugas mencapai tahap "input-required", klien mengirimkan pesan lanjutan pada tugas yang sama.

Keempat, klien mengumpulkan hasilnya. Ketika tugas mencapai tahap "completed", klien membaca artefak. Jika berakhir dengan status "failed", "cancelled", atau "rejected", klien menangani hasilnya sesuai dengan itu, mungkin dengan mencoba agen lain atau meningkatkan masalah ke manusia.

Karena peran bersifat fleksibel, setiap langkah ini dapat melibatkan delegasi lebih lanjut. Agen pemesanan penerbangan, misalnya, dapat bertindak sebagai klien untuk agen pembayaran saat agen tersebut mengerjakan permintaan awal.

Pola Transportasi dan Pembaruan

A2A memisahkan apa yang dikomunikasikan dari bagaimana informasi tersebut disampaikan. Protokol ini mendefinisikan satu set objek data dan operasi, dan kemudian menentukan pengikatan standar yang membawanya. Pada versi 1, terdapat tiga: JSON-RPC 2.0 melalui HTTP, pengikatan HTTP-plus-JSON yang mengikuti pola gaya sumber daya, mirip REST, dan gRPC melalui HTTP/2. Ketiganya mengekspos operasi dan model data yang sama, dan agen mengiklankan pengikatan yang didukungnya di Kartu Agennya. Spesifikasi diatur dalam tiga lapisan, dengan model data di bagian bawah, operasi abstrak di atasnya, dan pengikatan protokol di bagian atas, yang memungkinkan implementor untuk menambahkan atau menukar pengikatan tanpa menulis ulang logika inti agen.

Terdapat tiga pola untuk menerima pembaruan. Polling adalah yang paling sederhana, karena klien berulang kali meminta status tugas. Streaming, yang dibawa melalui Server-Sent Events atau streaming server gRPC, memberikan pembaruan secara real-time saat agen bekerja. Notifikasi push memungkinkan agen untuk memanggil webhook yang disediakan klien, yang cocok untuk tugas-tugas yang sangat panjang di mana mempertahankan koneksi tetap terbuka akan boros. Memilih di antara pola-pola ini sebagian besar bergantung pada berapa lama tugas berjalan dan infrastruktur apa yang dimiliki klien.

Kit pengembangan software resmi tersedia untuk beberapa bahasa, termasuk Python, JavaScript, Java, dan .NET, yang menangani sebagian besar pengaturan protokol sehingga pengembang dapat fokus pada perilaku agen. Contoh dan alat bantu di repositori proyek membantu tim untuk memulai.

Keamanan dan Kepercayaan dalam A2A

Menghubungkan agen otonom di seluruh batas organisasi menimbulkan pertanyaan keamanan yang jelas, dan A2A menjawab sebagian dari pertanyaan tersebut sambil menyerahkan tanggung jawab penting kepada para implementor.

Apa yang Disediakan Protokol

Setiap Agent Card menyatakan skema autentikasi yang dibutuhkannya, dan spesifikasi mendukung skema umum termasuk kunci API, autentikasi HTTP, OAuth 2.0, OpenID Connect, dan TLS bersama. Karena A2A berjalan di atas transportasi standar, ia mendapat manfaat dari TLS dan dari kontrol perusahaan yang ada seperti gateway API, firewall aplikasi web, dan penyedia identitas. Agent Card dapat ditandatangani secara digital, sehingga klien dapat memverifikasi bahwa kartu tersebut benar-benar berasal dari penyedia yang diklaim, dan kartu yang diperluas yang diautentikasi memungkinkan agen untuk mengungkapkan kemampuan yang lebih sensitif hanya kepada penelepon yang terverifikasi. Prinsip opasitas juga membantu: karena agen tidak berbagi memori internal atau alat, ada lebih sedikit materi sensitif yang terekspos sejak awal.

Apa yang Tetap Menjadi Tugas Implementor

Sebuah protokol tidak dapat memutuskan siapa yang harus dipercaya. Agen klien masih harus memilih agen jarak jauh mana yang bersedia didelegasikan, dan keputusan itu perlu dipertimbangkan dengan cermat, karena agen yang tidak tepercaya mungkin memberikan output yang menyesatkan atau mencoba memanipulasi klien. Konten yang datang dari agen lain harus diperlakukan seperti input tidak tepercaya lainnya. Konten tersebut dapat membawa upaya injeksi cepat, instruksi yang tersembunyi dalam teks atau file yang mencoba mengarahkan agen penerima ke tindakan yang tidak diinginkan. Pertahanan meliputi pembatasan apa yang diizinkan agen untuk dilakukan berdasarkan output agen lain, validasi data terstruktur, persyaratan persetujuan manusia untuk tindakan yang penting, dan penerapan prinsip hak akses minimal pada kredensial.

Pertimbangan praktis lainnya meliputi identitas dan otorisasi di seluruh organisasi, audit agen mana yang melakukan apa, pembatasan laju dan pencegahan penyalahgunaan, dan verifikasi bahwa kemampuan yang diklaim agen adalah kemampuan yang sebenarnya diberikannya. Gateway yang berada di depan lalu lintas A2A dapat membantu dengan memusatkan otentikasi, penegakan kebijakan, pencatatan, dan pemantauan. Seperti halnya standar baru lainnya, praktik keamanan seputar A2A masih dalam tahap pematangan, sehingga tim harus menggabungkan fitur bawaan protokol dengan pemodelan ancaman mereka sendiri.

A2A vs MCP: Saling Melengkapi, Bukan Bersaing

Pertanyaan yang paling sering diajukan oleh pendatang baru adalah bagaimana A2A berhubungan dengan Model Context Protocol (MCP), yang telah menjadi cara standar untuk menghubungkan aplikasi AI dengan alat dan data. Jawaban singkatnya adalah bahwa keduanya memecahkan masalah yang berbeda, dan dirancang untuk bekerja sama.

MCP menangani koneksi vertikal antara agen atau model dan alat, sumber data, dan perintah yang digunakannya. Server MCP mengekspos fungsi dan konteks, seperti mencari database, membaca file, atau memanggil API, dan model memanggilnya. Ujung lain dari koneksi MCP pada dasarnya adalah penyedia kemampuan. Ia tidak bernalar secara otonom atau bernegosiasi; ia mengeksekusi operasi yang telah ditentukan.

A2A menangani koneksi horizontal antara agen independen. Ujung lain dari koneksi A2A bukanlah fungsi tetapi entitas otonom dengan penalaran sendiri, yang mungkin membutuhkan waktu, mengajukan pertanyaan, dan mengembalikan hasil yang kaya. Oleh karena itu, A2A mencakup konsep-konsep yang tidak dibutuhkan oleh alat: penemuan kemampuan melalui Agent Card, siklus hidup tugas, permintaan masukan di tengah tugas, dan negosiasi format.

Cara yang membantu untuk membayangkannya: MCP adalah cara agen mengambil alatnya, dan A2A adalah cara agen berkomunikasi dengan rekan kerja. Pertimbangkan contoh perekrutan. Seorang agen SDM menerima permintaan untuk menjadwalkan wawancara teknis. Ia mendelegasikan tugas penjadwalan melalui A2A kepada agen kalender khusus. Agen kalender tersebut, pada gilirannya, menggunakan MCP secara lokal untuk memanggil alat kalender dan menanyakan slot waktu yang tersedia. Setelah mendapatkan slot, ia menyelesaikan pemesanan dan mengembalikan hasilnya kepada agen SDM melalui saluran A2A. Kedua protokol tersebut muncul dalam alur kerja yang sama, masing-masing melakukan pekerjaan yang dirancang untuknya.

Keberadaan bersama mereka di Agentic AI Foundation memperkuat hubungan komplementer ini. Platform agen yang matang kemungkinan akan mendukung keduanya, menggunakan MCP untuk akses alat dan A2A untuk kolaborasi antar agen.

A2A dan Pendekatan Lain untuk Sistem Multi-Agen

A2A terkadang disalahartikan dengan framework orkestrasi agen seperti LangGraph, CrewAI, atau AutoGen. Framework ini membantu developer membangun sistem multi-agen dalam satu basis kode atau organisasi, mendefinisikan bagaimana agen bekerja sama, berbagi status, dan meneruskan pekerjaan. A2A beroperasi pada tingkat yang berbeda. Ini menstandarisasi komunikasi antar agen yang mungkin dibangun dengan framework yang berbeda, dimiliki oleh tim yang berbeda, atau dihosting oleh perusahaan yang berbeda. Suatu sistem mungkin menggunakan framework secara internal untuk mengoordinasikan agennya sendiri sambil mengekspos satu atau lebih dari mereka secara eksternal melalui A2A, dan mengonsumsi agen organisasi lain melalui protokol yang sama.

Demikian pula, A2A berbeda dari memanggil API REST biasa. API konvensional mengekspos operasi tetap yang kembali dengan cepat dengan output yang dapat diprediksi. A2A dibangun untuk interaksi di mana pihak lain berpikir, meluangkan waktu, mengajukan pertanyaan, dan menghasilkan hasil yang terbuka. Di mana fungsi deterministik sederhana sudah cukup, API biasa atau alat MCP lebih cocok. A2A (Augmented to Answer) menjadi relevan ketika pihak jarak jauh itu sendiri adalah seorang agen.

Apa yang Dimungkinkan oleh A2A: Kasus Penggunaan

Dalam alur kerja perusahaan, agen khusus di berbagai departemen dapat berkolaborasi dalam proses yang melintasi batas, seperti perekrutan karyawan baru, yang melibatkan SDM, penyediaan TI, fasilitas, dan penggajian. Setiap departemen memiliki agennya sendiri dengan aturannya sendiri, dan agen koordinator mendelegasikan bagian-bagian tugas kepada masing-masing departemen melalui A2A, melacak tugas dan mengumpulkan hasilnya.

Dalam layanan pelanggan, asisten lini depan dapat menyerahkan permintaan khusus kepada agen ahli, seperti penagihan, diagnostik teknis, atau logistik, dan permintaan ini mungkin berasal dari vendor yang berbeda. Pelanggan mendapatkan pengalaman yang koheren sementara pekerjaan didistribusikan ke agen mana pun yang paling sesuai.

Dalam rantai pasokan dan pengadaan, agen yang mewakili berbagai organisasi dapat bernegosiasi dan berkoordinasi: satu memeriksa inventaris, yang lain memberikan penawaran harga, yang lain mengatur pengiriman. Karena A2A bekerja melintasi batas organisasi, bisnis dapat mengizinkan agen mereka untuk berinteraksi tanpa menggabungkan sistem atau mengekspos data internal.

Dalam bidang perjalanan dan perdagangan, seorang asisten dapat menggabungkan layanan dari penyedia independen, mencari penerbangan, hotel, dan aktivitas melalui agen masing-masing penyedia, bukan melalui pengumpulan data yang rumit atau integrasi khusus.

Dalam pekerjaan software dan data, seorang agen pengembangan dapat mendelegasikan pengujian, peninjauan keamanan, atau analisis data kepada agen spesialis, yang masing-masing dikelola secara terpisah dan ditingkatkan secara independen.

Di semua bidang ini, muncul tema umum: spesialisasi yang dikombinasikan dengan interoperabilitas. Alih-alih satu agen raksasa yang mencoba melakukan segalanya, organisasi dapat menyusun jaringan agen yang terfokus, mengganti atau meningkatkan salah satu dari mereka tanpa mengganggu yang lain.

Manfaat Mengadopsi A2A

Beberapa keuntungan diperoleh dari penggunaan standar bersama. Interoperabilitas mengurangi upaya integrasi, karena setiap agen hanya perlu mengimplementasikan protokol sekali saja, bukan membangun koneksi khusus ke setiap mitra. Independensi vendor dan framework mempertahankan pilihan, sehingga tim dapat memilih agen terbaik untuk setiap pekerjaan tanpa khawatir apakah itu sesuai dengan ekosistem. Modularitas membuat sistem lebih mudah untuk dikembangkan, karena agen dapat dikembangkan, diuji, dan diganti secara independen. Ketergantungan pada standar web yang ada menurunkan proses pembelajaran dan memungkinkan penggunaan kembali infrastruktur keamanan dan pengamatan yang ada. Opasitas membantu organisasi melindungi logika kepemilikan sambil tetap menawarkan kemampuan. Dan tata kelola yang netral dan terbuka mengurangi risiko standar dibengkokkan untuk kepentingan satu perusahaan.

Keterbatasan dan Tantangan Terbuka

Penemuan dan kepercayaan dalam skala besar masih sulit. Agent Card memberi tahu klien apa yang diklaim agen untuk dilakukan, tetapi memutuskan agen mana yang dapat dipercaya, bagaimana menemukan agen yang bereputasi baik, dan bagaimana memverifikasi klaim sebagian besar berada di luar protokol, dan registri serta sistem reputasi masih dalam pengembangan. Kualitas adalah celah lain: A2A menentukan bagaimana agen berkomunikasi, bukan seberapa baik kinerja mereka, sehingga mengevaluasi apakah agen jarak jauh memberikan layanan secara andal adalah masalah klien.

Latensi dan biaya dapat bertambah dalam rantai delegasi. Setiap lompatan menambah waktu dan, jika agen menggunakan model besar, biaya, dan kesalahan dapat menyebar dari satu agen ke agen berikutnya. Debugging interaksi otonom terdistribusi juga lebih sulit daripada debugging program tunggal, yang membuat pelacakan, pencatatan, dan pengamatan menjadi penting.

Ekosistem masih dalam tahap pematangan. Standar di bidang ini telah berkembang pesat, spesifikasi terkait muncul untuk bidang-bidang seperti pembayaran dan perdagangan, dan praktik terbaik sedang dikembangkan dalam implementasi nyata. Tim harus mengantisipasi perubahan yang berkelanjutan dan menghindari terlalu terpaku pada detail yang mungkin berkembang. Keberadaan dua protokol utama, A2A dan MCP, juga mengharuskan developer untuk memahami di mana masing-masing berlaku, meskipun tata kelola bersama mereka menunjukkan keselarasan yang semakin meningkat.

Terakhir, seperti halnya kemampuan apa pun yang memungkinkan software bertindak secara otonom di seluruh lini organisasi, pertanyaan tata kelola muncul: siapa yang bertanggung jawab ketika serangkaian agen menyebabkan kerugian, bagaimana mengaudit keputusan, dan bagaimana menjaga agar manusia tetap memegang kendali secara bermakna. Protokol ini menyediakan infrastruktur, bukan kebijakan.

Memulai dengan A2A

Bagi developer dan arsitek yang ingin mencoba A2A, pendekatan bertahap adalah yang terbaik. Mulailah dengan membaca spesifikasi dan dokumentasi proyek, perhatikan Agent Card, siklus hidup tugas, dan operasinya. Instal salah satu SDK resmi dalam bahasa yang sudah kita gunakan, dan jalankan implementasi sampel untuk melihat klien dan server bertukar pesan.

Kemudian buat sesuatu yang kecil. Buat agen sederhana dengan satu keterampilan, publikasikan Agent Card-nya di jalur yang sudah dikenal, dan implementasikan penanganan pesan yang mengembalikan hasil. Tulis agen kedua atau klien sederhana yang menemukan yang pertama, mengirim pesan, dan mengikuti tugas hingga selesai. Bereksperimenlah dengan kasus yang lebih sulit: tugas yang berhenti untuk input, respons streaming, dan notifikasi push.

Selanjutnya, tambahkan masalah produksi. Pilih skema otentikasi dan terapkan, validasi dan bersihkan apa pun yang datang dari agen lain, catat interaksi dengan pengidentifikasi yang memungkinkan kita melacak tugas dari ujung ke ujung, dan pertimbangkan untuk menempatkan gateway di depan agen kita untuk memusatkan kebijakan. Tentukan tindakan apa yang dapat dilakukan agen berdasarkan permintaan agen lain, dan perlukan persetujuan untuk hal-hal yang tidak dapat dibatalkan. Terakhir, putuskan bagaimana sistem kita akan menemukan dan memverifikasi agen jarak jauh yang bergantung padanya, karena pilihan tersebut menentukan seberapa banyak yang dapat kita otomatiskan dengan aman.

Ke Mana Arah A2A

Arah perjalanannya adalah menuju internet agen yang saling bekerja sama, di mana bisnis menerbitkan agen seperti halnya mereka menerbitkan website dan API, dan agen lain menemukan dan menggunakannya secara alami seperti halnya browser menggunakan halaman. Beberapa tren mendukung gambaran ini: perpindahan ke Agentic AI Foundation bersama MCP, partisipasi luas dari perusahaan software cloud dan perusahaan besar, dukungan bawaan dalam platform agen terkemuka, dan meningkatnya minat pada standar berlapis untuk area seperti identitas, pembayaran, dan perdagangan yang dapat dibangun di atas primitif komunikasi A2A.

Seberapa cepat visi itu terwujud akan lebih bergantung pada kepercayaan, tata kelola, dan kualitas agen itu sendiri daripada protokolnya. Tetapi logika dasarnya masuk akal. Seiring dengan proliferasi agen, nilai dari cara umum bagi mereka untuk berkomunikasi hanya akan meningkat, seperti halnya nilai standar web umum yang meningkat dengan setiap situs web baru.


Jadi, protokol Agent2Agent (A2A) menjawab kebutuhan sederhana namun mendasar, yaitu agen AI independen, yang dibangun oleh orang yang berbeda di platform yang berbeda, membutuhkan cara standar untuk saling menemukan, bekerja sama, dan melaporkan hasil tanpa mengekspos cara kerja internal mereka. A2A menyediakan hal itu melalui serangkaian ide kecil, yaitu Agent Card untuk penemuan, pesan dan bagian untuk komunikasi, tugas dengan siklus hidup yang jelas untuk pekerjaan, dan artefak untuk hasil, semuanya dibawa melalui transportasi web yang familiar dan diamankan dengan skema otentikasi yang mapan.