Belajar A2A - Fitur Modern & Roadmap

#Pendahuluan

Episode 20 membawa kalian ke disiplin operasional: CI/CD, contract testing, dan governance SLA. Semua praktik itu mengandaikan protokol yang stabil — dan itulah yang akhirnya terjadi. Setelah satu tahun perjalanan dari protokol eksperimental, A2A kini punya rilis v1.0 yang stabil di bawah naungan Linux Foundation.

Episode 21 adalah snapshot terkini: apa saja yang dibawa v1.0 (signed agent cards, multi-tenancy, version negotiation), dukungan SDK lintas bahasa, siapa yang menaungi dan memakai protokol ini, dan ke mana roadmap berikutnya. Ini adalah episode "state of the ecosystem" — bahan pertimbangan kalian sebelum memutuskan membangun di atas A2A.

#Perjalanan Menuju v1.0

Rekap singkat sejarah dari episode 1: A2A diumumkan Google pada April 2025, didonasikan ke Linux Foundation pada Juni 2025, lalu beriterasi cepat dari v0.1, v0.2, hingga v0.3 yang menambahkan gRPC dan signable security cards. Hingga akhirnya v1.0 dirilis Maret 2026 — versi stable pertama, diikuti v1.0.1 (Mei 2026) sebagai patch.

Yang membuat v1.0 berarti bukan sekadar angka, melainkan janji stabilitas: API dan semantik yang sudah dipakai produksi tidak akan berubah secara breaking tanpa version negotiation. Inilah yang ditunggu vendor sebelum berinvestasi besar — dan pemerintahannya di tangan Linux Foundation dengan TSC yang diisi nama besar: AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, dan ServiceNow. Pengelolaan lintas vendor ini yang membedakan A2A dari protokol yang dimiliki satu perusahaan.

#Signed Agent Cards: Identitas yang Bisa Diverifikasi

Fitur paling substansial di v1.0 adalah signed agent cards. Sebelumnya (v0.3) sudah ada signable security cards; kini signing diperluas ke seluruh agent card — sehingga client bisa memverifikasi dua hal: siapa yang menerbitkan kartu itu, dan apakah isi kartunya masih utuh.

# Ambil agent card + signature dari endpoint /well-known
curl -s https://agent.example.com/agent-card \
  -H "Accept: application/json" > card.json
curl -s https://agent.example.com/agent-card/signature > card.sig
 
# Verifikasi dengan public key issuer
openssl dgst -sha256 -verify issuer-pub.pem \
  -signature card.sig card.json

Verifikasi ini mengubah cara client menilai remote agent: tidak lagi "kartunya bilang begitu", melainkan "kartunya dijamin oleh pihak yang kita percaya". Di ekosistem dengan 150+ organisasi, kemampuan memverifikasi penerbit menjadi fondasi trust model agent-ke-agent — kita bahas lengkap di episode 9, dan sekarang menjadi standar default.

Praktik yang disarankan: simpan public key issuer di keystore terpusat, lalu jalankan verifikasi setiap kali card di-fetch (atau di-cache bersama hasilnya, seperti strategi caching di episode 18). Dengan begitu, curl untuk mengambil kartu di atas hanyalah langkah awal — yang sesungguhnya bernilai adalah kebijakan penerbit yang kalian putuskan di sisi client.

#Multi-Tenancy dan Version Negotiation

Dua fitur v1.0 lainnya menyelesaikan masalah operasional yang nyata:

Multi-tenancy memungkinkan satu agent service melayani banyak tenant dengan konteks terisolasi — tenant A tidak bisa membaca task atau history tenant B. Di level implementasi, ini berarti header konteks per-request, penyimpanan state yang dipartisi oleh tenant id, dan kebijakan rate limit yang dihitung per tenant, bukan agregat.

header-tenant.py

async def send_task_tenant(agent_url: str, tenant_id: str, task: dict):
    headers = {"A2A-Tenant-Id": tenant_id, "Authorization": bearer(tenant_id)}
    async with httpx.AsyncClient(headers=headers) as client:
        return await client.post(agent_url, json=task)

Header tenant diinjeksi di setiap request, sementara state task disimpan dengan partisi tenant id sebagai kunci utama. Dengan pola ini, satu deployment bisa melayani seratus client tanpa saling melihat — asalkan isolasi diverifikasi lewat test lintas tenant seperti yang kita bahas di episode 20.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "client/versions",
  "params": {
    "supportedVersions": ["1.0", "0.3"]
  }
}

Version negotiation menjawab pertanyaan "client bilang 1.0, server jalan 0.3, gimana?" Melalui handshake versi di awal koneksi, kedua pihak sepakat memakai versi yang paling tinggi yang didukung bersama. Ini yang membuat migrasi v0.3 ke v1.0 berjalan bertahap: client lama dan client baru bisa menunggangi server yang sama selama transisi, tanpa jendela downtime bersama.

#Binding dan SDK Lintas Bahasa

Stabilitas v1.0 juga berarti konsistensi binding dan SDK. Tiga binding resmi tetap dipertahankan — JSON-RPC over HTTP, gRPC, dan HTTP + SSE untuk streaming — dan SDK resmi kini menjangkau lima bahasa besar. Semua dipasang lewat package manager masing-masing, misalnya pip install a2a-sdk untuk Python dan npm install @a2a-protocol/a2a untuk TypeScript:

# Python
pip install a2a-sdk
 
# JavaScript / TypeScript (Node)
npm install @a2a-protocol/a2a
 
# Go, Java, .NET
go get github.com/a2aproject/a2a-sdk-go
dotnet add package A2A.SDK

Konsistensi lintas bahasa membuat keputusan teknis lebih mudah: tim backend bisa menulis client di Python, tim platform di Go, dan tim frontend agent di TypeScript — semuanya berbicara protokol yang sama dengan semantik yang identik. Kalian tidak lagi terjebak pada satu bahasa hanya karena itu satu-satunya SDK yang matang.

#Ekosistem Enterprise dan Roadmap

Di balik spesifikasi, ada ekosistem yang sedang tumbuh. ADK (Agent Development Kit) dari Google kini mendukung A2A secara native — agent ADK bisa di-expose sebagai remote agent A2A dan sebaliknya (kita sudah praktikkan di episode 12). Lebih dari 150 organisasi ikut ekosistem, dengan adopsi produksi di perusahaan enterprise — bukan sekadar proof-of-concept.

Nilai dari keanggotaan TSC yang heterogen (AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, ServiceNow) tidak boleh diremehkan: setiap keputusan standar melewati pertimbangan lintas vendor, sehingga tidak ada satu perusahaan yang bisa mengubah arah protokol demi keuntungannya sendiri. Bagi kalian yang bekerja di perusahaan yang harus memilih standar, argumen governance seperti ini sering jadi pembeda utama antara protokol yang bertahan dan yang meredup.

Ke mana arahnya? Roadmap resmi menyebut tiga sumbu:

• Discovery improvement — mencarikan agent yang tepat dari katalog besar secara lebih efisien, menguatkan kerja sama dengan registry yang dibahas di episode 16.
• Keamanan lanjutan — memperdalam model trust, penanganan prompt injection, dan kebijakan zero-trust antar agent.
• Perluasan ekosistem interop — memperluas interoperasi dengan protokol sekitar (MCP, AG-UI, dan lapisan commerce yang kita bahas di episode 19).

#Penutup

Episode 21 merangkum kondisi A2A hari ini: v1.0 stabil dengan signed agent cards, multi-tenancy, dan version negotiation sebagai tiga pilar barunya; tiga binding dan lima SDK resmi menjamin portabilitas; dan ekosistem Linux Foundation yang dihuni vendor besar memberi legitimasi lintas perusahaan. Roadmap ke depan menjanjikan discovery yang lebih pintar, keamanan yang lebih dalam, dan interop yang lebih luas.

Inti yang harus dibawa pulang:

• v1.0 (Maret 2026) adalah rilis stable pertama; v1.0.1 adalah patch pemeliharaan.
• Signed agent cards memindahkan kepercayaan dari klaim ke verifikasi kriptografis.
• Multi-tenancy dan version negotiation menyelesaikan dua masalah operasional besar.
• SDK resmi ada untuk Python, Go, JavaScript/TypeScript, Java, dan .NET.
• Roadmap berfokus pada discovery, keamanan, dan perluasan interop ekosistem.

Episode 22 adalah penutup series: kita akan membandingkan A2A dengan alternatif seperti MCP dan AG-UI, memutuskan kapan A2A adalah pilihan tepat, dan menutup seluruh perjalanan 0-22 dengan checklist produksi lengkap. Sampai jumpa!