A2A vs MCP: Protokol AI Agent Mana yang Anda Butuhkan?

A2A vs MCP adalah pertanyaan yang sekarang muncul di hampir setiap review desain agent yang saya ikuti, biasanya dalam bentuk pilihan: mana yang harus kita jadikan standar? Pertanyaannya keliru. MCP, Model Context Protocol, adalah cara agent menjangkau tool dan data yang boleh ia pakai. A2A, protokol Agent2Agent, adalah cara satu agent menyerahkan pekerjaan ke agent lain yang isinya tidak bisa ia lihat. Agent procurement yang membaca stok dari ERP Anda adalah urusan MCP. Agent yang sama meminta penawaran harga ke agent milik supplier adalah urusan A2A, dan wajar sekali satu sistem butuh keduanya di sore yang sama.

Yang berubah tahun ini adalah ringkasan lama tidak lagi akurat. Dulu MCP adalah yang stateful, dengan handshake dan session; spesifikasi 2026-07-28 menghapus keduanya. A2A mencapai versi stabil 1.0 dan, pada 17 Agustus 2026, pindah ke Agentic AI Foundation bersama MCP. Tulisan ini membandingkan keduanya dari hal yang benar-benar menentukan arsitektur: siapa yang ada di ujung lain, discovery, state, pekerjaan panjang, auth dan governance. Semua nama method, field dan tanggal di bawah berasal dari kedua spesifikasi, release post MCP dan pengumuman foundation, per 1 Oktober 2026. Tulisan sebelumnya tentang MCP versus function calling membandingkan MCP dengan tool in-process; tulisan ini membahas layer protokol di atasnya.

A2A vs MCP dalam Satu Kalimat: Agent ke Tool dan Agent ke Agent

Spesifikasi A2A menarik garisnya sendiri di lampirannya: MCP menstandarkan cara agent terhubung ke tool, API, sumber data dan resource lain, sedangkan A2A menstandarkan cara agent-agent yang independen dan sering kali opaque berkomunikasi sebagai sesama peer. Kata kuncinya adalah opaque. Dengan MCP Anda melihat nama tool, input schema dan hasilnya. Dengan A2A Anda melihat Agent Card berisi daftar skill, tanpa tahu apa pun soal prompt, tool atau memory di baliknya. Tiga pertanyaan menentukan sebuah kemampuan ada di sisi mana.

• Apakah pemanggil tahu persis operasi yang ia mau, lengkap dengan argumen bertipe? Berarti itu tool, dan MCP cocok. Ambil level stok untuk satu SKU di satu gudang adalah tool call.
• Apakah pihak seberang perlu bernalar, bertanya balik atau bernegosiasi dulu sebelum bisa menjawab? Berarti itu agent, dan A2A cocok. Carikan harga delivered termurah untuk 400 unit adalah tugas untuk agent.
• Apakah pihak seberang dimiliki tim atau perusahaan lain yang tidak akan memberikan daftar tool atau credential-nya? Berarti Anda butuh A2A walaupun pekerjaannya tampak sederhana, karena batasnya organisasional, bukan teknis.

Pertanyaan ketiga inilah yang sering dilewati. Agent pengecekan kredit milik tim finance di perusahaan Anda sendiri tetaplah agent dengan pemilik terpisah, release cycle sendiri dan akses data sendiri. Membungkusnya sebagai tool MCP berarti membekukan perilakunya ke dalam satu schema dan meminjam credential-nya, persis jenis coupling yang ingin dihindari A2A.

Tabel Perbandingan A2A vs MCP

Ini tabel yang saya cari waktu mulai, diisi dari MCP 2026-07-28 dan A2A 1.0. Baris yang paling banyak berubah tahun ini adalah state dan pekerjaan panjang, jadi baca dua baris itu dulu sebelum memercayai perbandingan apa pun yang ditulis tahun 2025.

Kalau dibaca per baris, polanya terlihat. Sepanjang tahun ini MCP membuang semua hal yang mengikat request ke satu koneksi, sehingga tool server berperilaku seperti layanan HTTP stateless biasa. A2A sengaja mengambil arah sebaliknya: task adalah objek durable milik agent seberang, karena mendelegasikan pekerjaan ke agent adalah percakapan, bukan function call. Tidak ada desain yang lebih baik. Keduanya cocok untuk pekerjaan yang berbeda.

Discovery: Agent Card Itu CV, Daftar Tool Itu Kontrak

Dua mekanisme discovery ini banyak bercerita tentang hubungan yang dimaksud. Client MCP bertanya ke server apa saja yang bisa dipanggil dan mendapat definisi tool bertipe yang bisa langsung diberikan ke model. Client A2A mengambil dokumen JSON publik yang menjelaskan identitas agent, endpoint, kebutuhan auth dan skill-nya, lalu memutuskan apakah agent itu layak dipercaya.

# MCP 2026-07-28 — no initialize, no Mcp-Session-Id.
# Every request carries its own version, client info and capabilities,
# so it can land on any instance behind a plain round-robin balancer.
POST /mcp HTTP/1.1
Host: erp-tools.internal.example
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call        # gateways route and meter on these two
Mcp-Name: get_stock_level     # headers without parsing the JSON body

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"get_stock_level","arguments":{"sku":"BRG-0042","warehouse":"SBY"},
  "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"procurement-agent","version":"3.1"}}}}

# A2A 1.0 — you are not calling a function, you are reading a résumé.
GET /.well-known/agent-card.json HTTP/1.1
Host: agents.supplier.example

{
  "name": "Supplier Quote Agent",
  "description": "Quotes price and lead time for bulk orders",
  "version": "2.0.0",
  "supportedInterfaces": [
    {"url": "https://agents.supplier.example/a2a/v1",
     "protocolBinding": "JSONRPC", "protocolVersion": "1.0"}
  ],
  "capabilities": {"streaming": true, "pushNotifications": true,
                   "extendedAgentCard": true},
  "securitySchemes": {"partnerOAuth": {"oauth2SecurityScheme": {"...": "flows"}}},
  "securityRequirements": [{"schemes": {"partnerOAuth": {"list": ["quotes"]}}}],
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [{"id": "bulk-quote", "name": "Bulk order quote",
              "description": "Negotiates a quote for 100+ units",
              "tags": ["quote", "procurement"]}]
}
# Note what is missing: no tool list, no input schema per call.
# The partner's tools stay private — that opacity is the point of A2A.

Dua detail dari spesifikasi penting dalam praktik. Di sisi MCP, respons tools/list, prompts/list, resources/list dan resources/read kini membawa ttlMs dan cacheScope, dan urutan list deterministik, sehingga client bisa melakukan cache katalog tool dan menjaga prompt cache di upstream tetap stabil walaupun reconnect. Di sisi A2A, Agent Card bisa ditandatangani dengan JSON Web Signature, dan card publik bisa mengiklankan extended card yang hanya diterima client yang sudah terautentikasi. Dengan cara itu sebuah partner bisa menampilkan daftar skill umum ke publik dan daftar yang lebih lengkap khusus untuk Anda.

Konsekuensinya untuk desain: daftar tool MCP adalah kontrak yang Anda program, jadi mengubah schema sebuah tool adalah breaking change bagi semua client. Agent Card lebih mirip CV. Skill membawa deskripsi, tag dan contoh, bukan schema ketat, dan agent seberang diharapkan sanggup menangani request yang bervariasi serta bertanya bila butuh informasi tambahan.

State Setelah MCP Menjadi Stateless

Rilis 2026-07-28 menghapus pertukaran initialize dan initialized serta header Mcp-Session-Id. Setiap request kini membawa versi protokol, identitas client dan capabilities di _meta, dan release post-nya terang-terangan soal alasannya: request apa pun bisa mendarat di instance server mana pun di belakang load balancer round-robin biasa, tanpa shared storage. Request yang diinisiasi server seperti elicitation dan sampling digantikan Multi Round-Trip Requests, di mana server mengembalikan input_required dan client mengulang panggilan aslinya dengan jawaban terlampir. Roots, Sampling dan Logging dinyatakan deprecated dengan dukungan minimal dua belas bulan, begitu pula transport HTTP+SSE lama.

Protokol stateless bukan berarti aplikasi stateless. Release post-nya menyarankan server yang butuh kesinambungan untuk membuat handle eksplisit dari sebuah tool dan membiarkan model mengirimnya kembali sebagai argumen. A2A tidak pernah punya masalah itu, karena state memang pokok bahasannya. Task punya id, status dan artifact, dan contextId memungkinkan agent seberang menjaga satu thread multi-turn tetap utuh di beberapa task. Kalau Anda mendapati diri membangun memory percakapan di atas handle MCP supaya dua agent bisa saling bicara, itulah saatnya berganti protokol.

Pekerjaan Panjang: MCP Tasks Versus Task A2A

Kedua protokol kini sama-sama punya sesuatu bernama task, dan di situlah kebingungan biasanya dimulai. Di MCP, task adalah extension, io.modelcontextprotocol/tasks, yang diaktifkan client per request dan diterapkan server per request: ketika server menilai sebuah panggilan akan lama, ia mengembalikan task handle yang durable alih-alih hasilnya. Di A2A, task adalah objek inti yang dihasilkan setiap interaksi yang tidak sepele. Berikut bentuk pekerjaan yang sama di masing-masing protokol.

# ── MCP: tools/call with the io.modelcontextprotocol/tasks extension ──
# Client opted in via _meta clientCapabilities.extensions. The SERVER decides
# per request whether to return a task instead of the result.
-> tools/call  {"name": "rebuild_stock_valuation", "arguments": {"period": "2026-09"}}
<- {"resultType": "task", "taskId": "t-81f2", "status": "working",
    "ttlMs": 86400000, "pollIntervalMs": 5000}        # abbreviated

-> tasks/get   {"taskId": "t-81f2"}                     # store taskId durably:
<- {"status": "input_required", "inputRequests": {...}} # a restart resumes polling
-> tasks/update {"taskId": "t-81f2", "inputResponses": {...}}
-> tasks/get   {"taskId": "t-81f2"}
<- {"status": "completed", "result": {...}}             # what tools/call would
                                                        # have returned inline

# ── A2A: the task IS the protocol, not an extension ──
-> SendMessage {"message": {"role": "ROLE_USER", "messageId": "m-1",
                "parts": [{"text": "Quote 400 units of BRG-0042, delivery Surabaya"}]}}
<- {"task": {"id": "q-77", "contextId": "ctx-9",
             "status": {"state": "TASK_STATE_INPUT_REQUIRED",
               "message": {"role": "ROLE_AGENT",
                 "parts": [{"text": "Incoterm? FOB or delivered?"}]}}}}

-> SendMessage {"message": {"taskId": "q-77", "role": "ROLE_USER",
                "messageId": "m-2", "parts": [{"text": "Delivered"}]}}
# Then poll GetTask, hold a SubscribeToTask stream, or register a webhook
# with CreateTaskPushNotificationConfig and stop holding connections at all.

Nama state-nya lebih mirip daripada desainnya, dan celahnya justru memberi pelajaran.

Aturan yang saya pakai: MCP Tasks untuk tool yang lambat, misalnya revaluasi stok, ekspor laporan atau CI run. Pemanggil tetap tahu persis apa yang ia minta dan hanya perlu menunggu. Task A2A untuk pekerjaan yang didelegasikan, di mana agent seberang bisa bertanya, butuh approval dan menghasilkan beberapa artifact di sepanjang jalan. MCP memakai polling secara default dan bisa mengirim update lewat stream subscriptions/listen yang opt-in; A2A menyediakan polling, streaming lewat Server-Sent Events dan webhook, cocok untuk partner yang mungkin butuh berjam-jam untuk menjawab.

Auth dan Governance: Siapa yang Dipercaya, Siapa Pemilik Spec

Authorization di MCP bersifat opsional, dan untuk server stdio spec-nya menyuruh mengambil credential dari environment. Lewat HTTP aturannya presisi: MCP server adalah OAuth 2.1 resource server, wajib memublikasikan Protected Resource Metadata, client wajib mengirim resource indicator yang menyebut server tujuan, dan server wajib menolak token apa pun yang tidak diterbitkan dengan server itu sebagai audience. Revisi 2026-07-28 menambahkan validasi issuer RFC 9207, mengikat client credential ke issuer yang menerbitkannya, dan secara resmi men-deprecate Dynamic Client Registration demi Client ID Metadata Documents.

A2A memperlakukan agent sebagai aplikasi enterprise biasa. Agent Card mendeklarasikan securitySchemes dan securityRequirements, credential didapat secara out of band, dan server wajib mengautentikasi setiap request. Bagian yang menarik adalah in-task authorization. Ketika agent seberang butuh izin baru di tengah pekerjaan, ia memindahkan task ke TASK_STATE_AUTH_REQUIRED dan client yang menyelesaikannya, bila perlu dengan mendelegasikan lagi ke atas rantainya sendiri. Spec-nya tegas bahwa state ini sendiri tidak memberi otorisasi apa pun; cakupan credential yang dihasilkan ditentukan oleh implementasinya.

Governance adalah satu-satunya dimensi di mana keduanya sudah menyatu. MCP adalah proyek pendiri Agentic AI Foundation, diumumkan Linux Foundation pada Desember 2025 dengan Anthropic menyumbang MCP, Block menyumbang goose dan OpenAI menyumbang AGENTS.md. A2A lahir di Google pada April 2025, pindah ke Linux Foundation pada Juni 2025, mencapai versi stabil 1.0 pada Maret 2026 dan menjadi hosted project AAIF pada 17 Agustus 2026. Masing-masing tetap punya maintainer dan proses spesifikasi sendiri, tetapi memilih salah satunya bukan lagi taruhan pada satu vendor.

Arsitektur Referensi Berlapis: Di Mana Tiap Protokol Berada

Beginilah cara saya menyusun satu sistem yang butuh keduanya, dengan asisten procurement ERP sebagai contoh. Setiap panah diberi label protokol yang dipakainya, dan inti gambarnya adalah kedua protokol tidak pernah berebut panah yang sama.

Layer 4  Surfaces           web chat · WhatsApp · ERP side panel
            │                (your own app API — neither A2A nor MCP)
            ▼
Layer 3  Orchestrator        procurement agent: owns the conversation and the plan
            │                                 │                        │
            │ MCP                             │ A2A                    │ A2A
            │ tools/call, stateless           │ SendMessage, task      │ (internal, but
            ▼                                 ▼                        ▼  separately owned)
Layer 2  MCP gateway          partner endpoint            finance team's agent
         routes on            supplier quote agent        credit-limit check
         Mcp-Method/Mcp-Name  (its tools are invisible    (it keeps its own MCP
            │                 to you; it may use MCP)      servers behind it)
            ▼
         MCP tool servers
         erp-read:  stock, price, PO status        ← safe, cacheable lists
         erp-draft: create draft PO, draft GRN     ← writes, idempotency key
         erp-post:  NOT exposed to any agent       ← humans post documents
            │
            ▼
Layer 1  Systems of record    ERP database · document store · approval queue

Baca dari tengah. Orchestrator memegang percakapan user dan rencananya. Semua yang bisa dipanggil dengan argumen yang jelas turun lewat MCP ke tool server yang Anda jalankan sendiri: read tool untuk stok, harga dan status purchase order, serta draft tool yang membuat dokumen untuk kemudian direview manusia. Posting tool sama sekali tidak diekspos ke agent mana pun. Semua yang butuh penilaian pihak lain bergerak ke samping lewat A2A: agent penawaran milik supplier di luar perusahaan, dan agent limit kredit milik tim finance di dalam perusahaan, yang menyimpan MCP server-nya sendiri di belakangnya.

Ada dua keuntungan operasional dari layer yang rapi. Karena request MCP kini membawa header Mcp-Method dan Mcp-Name, gateway di layer 2 bisa melakukan rate limit, logging dan otorisasi per tool tanpa mem-parse body, serta scale secara horizontal tanpa sticky session. Karena A2A hanya ada di batas kepemilikan, setiap endpoint A2A mewakili kontrak nyata dengan tim atau perusahaan lain, granularitas yang tepat untuk audit dan untuk menentukan credential siapa dipakai di mana.

Memilih di Antara Keduanya, dan Dua Cara Salah Memakainya

Dalam praktik, keputusannya muncul dari empat pertanyaan, diajukan berurutan untuk setiap integrasi dalam desain.

1. Apakah Anda mengendalikan kedua sisi dan tahu operasi persisnya? Pakai tool MCP, dan buat sempit serta bertipe.
2. Apakah operasinya lambat tapi tetap terdefinisi jelas? Tetap pakai MCP dan biarkan server mengembalikan task lewat extension Tasks, bila client Anda mendukungnya.
3. Apakah pihak seberang bernalar, bertanya balik atau butuh approval sendiri? Pakai A2A dan perlakukan hasilnya sebagai task dengan lifecycle, bukan return value.
4. Apakah pihak seberang dimiliki orang lain? Pakai A2A di batas itu bahkan untuk request sederhana, dan biarkan pemiliknya menentukan tool apa yang ada di baliknya.

Aturan yang berguna adalah soal batas, bukan merek: MCP di bawah agent, A2A di antara agent. Peralihan MCP ke core yang stateless menjadikannya layer tool yang makin bersih, dan task milik server di A2A adalah yang dibutuhkan delegasi. Sejak Agustus 2026 keduanya berada di foundation yang sama, jadi satu-satunya keputusan nyata yang tersisa adalah panah mana di desain Anda yang memakai protokol mana.