Agent Card v1.0: Apa yang Berubah dari Struktur Lama

Kalau sebuah agent mau bekerja sama dengan agent lain, pertanyaan pertama sebenarnya bukan “bisa ngobrol atau tidak?” Pertanyaan pertamanya lebih basic: siapa kamu, endpoint kamu di mana, protocol apa yang kamu dukung, capability apa yang kamu punya, dan bagaimana client seharusnya berinteraksi denganmu?

Di A2A, jawaban atas pertanyaan itu hidup di Agent Card.

Agent Card adalah dokumen JSON untuk mendeskripsikan identitas, capability, skill, interface, security requirement, dan informasi lain yang dibutuhkan client sebelum mulai berinteraksi dengan sebuah A2A server. Secara konsep, idenya tidak berubah di v1.0. Yang berubah cukup signifikan justru cara informasi itu ditata.

Dan ini penting karena perubahan Agent Card bukan cuma soal rename field. A2A v1.0 menggeser model discovery dari satu endpoint utama plus beberapa atribut transport menjadi struktur yang lebih eksplisit, lebih siap untuk multi-binding, version negotiation, extended capability, dan verification.

Bayangkan meeting migrasi sederhana.

“Endpoint agent kita masih agentCard.url, kan?” tanya engineer aplikasi.

Platform engineer menggeleng. “Kalau kita bicara v1.0, jangan asumsi begitu. Sekarang lihat supportedInterfaces.”

“Berarti protocolVersion juga pindah?”

“Iya. Versi protocol sekarang melekat ke interface, bukan satu field global di Agent Card.”

Percakapan seperti itu kelihatan kecil, tetapi di production ia bisa menentukan apakah client benar-benar menemukan cara berkomunikasi yang tepat atau hanya membaca format lama lalu gagal secara diam-diam.

Dari satu URL ke supportedInterfaces

Salah satu perubahan paling kelihatan di Agent Card v1.0 adalah munculnya supportedInterfaces.

Di v0.3, developer terbiasa melihat field seperti url, preferredTransport, protocolVersion, dan additionalInterfaces. Modelnya cukup intuitif untuk era awal protocol: ada endpoint utama, ada transport yang disukai, lalu kalau perlu ada interface tambahan.

Di v1.0, pendekatannya dirapikan. Endpoint, binding, dan protocol version sekarang dikelompokkan dalam objek AgentInterface di dalam supportedInterfaces.

Secara konseptual, sebuah interface bisa menyatakan:

URL tempat agent dapat diakses,
protocol binding yang digunakan,
dan protocol version yang didukung interface tersebut.

Kenapa ini lebih masuk akal?

Karena satu agent tidak harus identik dengan satu jalur komunikasi. Agent bisa saja mengekspos lebih dari satu interface, misalnya JSON-RPC, HTTP+JSON, atau gRPC, dengan dukungan versi yang tidak harus diperlakukan sebagai properti global yang sama untuk semuanya.

Dengan kata lain, Agent Card mulai mendeskripsikan “cara mengakses agent” sebagai kumpulan interface yang eksplisit.

Buat developer client, efek praktisnya jelas. Logic seperti:

ambil card.url,
baca preferredTransport,
lalu connect,

perlu diganti menjadi:

baca supportedInterfaces,
pilih interface yang compatible dengan client,
periksa protocolBinding,
periksa protocolVersion,
baru tentukan jalur komunikasi.

Ini bukan sekadar struktur JSON yang lebih cantik. Ini membuat compatibility menjadi bagian dari discovery.

Protocol version tidak lagi berdiri sendirian

Pada struktur lama, protocolVersion berada di Agent Card. Di v1.0, field itu tidak lagi menjadi properti top-level Agent Card dan versi ditempatkan pada masing-masing AgentInterface.

Implikasinya cukup besar untuk migration strategy.

Sebuah agent dapat mengiklankan lebih dari satu interface dan memungkinkan client memilih yang sesuai dengan dukungannya. Dokumentasi A2A v1.0 memang dirancang agar migration dari v0.3 tidak harus berupa big-bang cutover. Agent Card dapat mendukung strategi transisi di mana interface untuk perilaku lama dan interface untuk v1.0 hidup berdampingan selama periode migrasi.

Buat perusahaan yang punya puluhan client internal, ini jauh lebih realistis daripada memaksa semua tim upgrade pada Jumat malam pukul sepuluh.

Bayangkan perusahaan punya agent procurement yang dipakai tiga unit bisnis. Tim A sudah upgrade SDK. Tim B masih punya integration lama. Tim C bahkan punya service yang baru disentuh tiap kuartal.

Kalau version negotiation ditangani lewat interface discovery, agent owner punya ruang untuk menjalankan kompatibilitas bertahap.

Tetap ada cost maintenance, tentu. Dual support berarti testing lebih banyak. Tetapi setidaknya model protocol memberi tempat resmi untuk menyatakan perbedaan itu.

preferredTransport dan additionalInterfaces dikonsolidasikan

A2A v1.0 menghapus pola terpisah preferredTransport dan additionalInterfaces dari struktur lama Agent Card. Keduanya pada dasarnya digantikan oleh supportedInterfaces.

Ini mengurangi dua masalah.

Pertama, client tidak perlu menggabungkan satu endpoint utama dengan daftar tambahan yang punya semantics berbeda.

Kedua, agent owner tidak perlu menyatakan preferensi transport dalam field terpisah dari detail interface itu sendiri.

Sekarang pertanyaannya lebih konkret: interface apa saja yang tersedia dan mana yang bisa dipakai client ini?

Buat platform team, model seperti ini lebih gampang dimasukkan ke capability matching, policy engine, dan observability. Log juga bisa menyimpan interface mana yang dipilih, binding apa yang dipakai, dan protocol version berapa yang benar-benar digunakan.

Extended Agent Card pindah ke tempat yang lebih logis

Di format lama ada flag top-level untuk dukungan authenticated extended Agent Card. Di v1.0, capability itu dipindahkan ke capabilities.extendedAgentCard.

Secara arsitektur, ini lebih konsisten.

Extended Agent Card memang capability, jadi masuk akal jika ia hidup bersama capability agent lain, bukan nongkrong sebagai flag khusus di top level.

Fungsinya menarik untuk enterprise.

Public Agent Card bisa sengaja minimal: cukup informasi agar client tahu siapa agent tersebut, bagaimana cara mengaksesnya, dan security scheme apa yang dibutuhkan. Setelah client terautentikasi, Get Extended Agent Card dapat memberikan detail tambahan, termasuk skill atau konfigurasi yang tidak ingin dipublikasikan secara terbuka.

Ambil contoh agent internal perusahaan yang punya skill “buat draft purchase order”, “cek kontrak vendor”, dan “akses pricing khusus”. Tidak semua capability itu harus diumumkan ke internet hanya karena discovery endpoint publik tersedia.

Dengan extended card, public discovery dan authenticated capability disclosure bisa dipisahkan.

Tetapi jangan salah tafsir: extended card bukan security magic. Server tetap harus melakukan authentication dan authorization dengan benar. Menyembunyikan nama skill tidak sama dengan mengamankan action di backend.

Agent Card sekarang lebih serius soal signature

A2A v1.0 juga membawa dukungan signature verification untuk Agent Card. Spesifikasi menggunakan pola berbasis JWS dan JSON Canonicalization Scheme agar client dapat memverifikasi integritas card secara deterministik.

Secara sederhana, client dapat memeriksa apakah Agent Card yang diterimanya benar-benar sesuai dengan payload yang ditandatangani pihak yang kuncinya dipercaya.

Ini berguna karena discovery pada agentic ecosystem punya masalah klasik yang mirip dengan web dan software supply chain: bagaimana kita tahu metadata capability yang kita baca bukan hasil modifikasi di tengah jalan atau impersonation?

Namun signature tidak otomatis menjawab semua pertanyaan trust.

Signature bisa membantu menjawab:

apakah payload berubah sejak ditandatangani,
dan apakah signature cocok dengan key tertentu.

Signature tidak otomatis membuktikan bahwa semua klaim di dalam Agent Card benar secara bisnis. Agent bisa menulis skill “best market analysis in Asia” dan menandatanganinya secara cryptographically valid. Signature membuktikan origin dan integrity, bukan kualitas klaim.

Ini distinction yang penting buat tim governance.

Agent Card jangan diperlakukan seperti halaman About Us yang dipercaya mentah-mentah. Ia adalah machine-readable declaration yang tetap perlu policy dan trust evaluation.

Security declaration juga makin enterprise-friendly

A2A v1.0 memperkuat beberapa area security. Agent Card dapat mendeklarasikan security schemes dengan lebih formal, termasuk dukungan skenario seperti mutual TLS. OAuth juga dimodernisasi, dengan arah yang lebih dekat ke praktik security modern seperti Authorization Code dengan PKCE, sementara flow lama yang dianggap lemah tidak lagi menjadi pilihan utama dalam v1.0.

Buat consumer client, informasi ini menentukan bukan hanya “apakah agent punya skill yang saya cari”, tetapi “apakah saya mampu dan diizinkan mengaksesnya”.

Discovery tanpa security matching bisa menghasilkan pengalaman buruk.

Client menemukan agent yang kelihatannya perfect, lalu baru mengetahui di tahap eksekusi bahwa agent membutuhkan authentication scheme yang tidak didukung host.

Agent Card yang lebih ekspresif membantu memindahkan sebagian failure itu ke tahap discovery dan negotiation.

Apa yang tidak berubah

Di tengah daftar perubahan, ada baiknya tidak membuat narasi seolah v1.0 membuang konsep lama sepenuhnya.

Tujuan Agent Card tetap sama: agent self-description untuk discovery dan interoperability.

Agent tetap perlu mengatakan siapa dirinya, apa yang bisa dilakukan, dan bagaimana client bisa berkomunikasi dengannya.

Yang berubah adalah kualitas kontraknya.

A2A bergerak dari model yang cukup untuk membuktikan konsep menuju model yang lebih cocok untuk ekosistem heterogen, multi-interface, versioned, dan security-conscious.

Karena itu migration sebaiknya tidak dimulai dari search-and-replace field.

Mulai dari consumer behavior.

Audit client sebelum mengubah server

Kesalahan yang sering terjadi saat schema berubah adalah tim server fokus mengeluarkan format baru, tetapi lupa mengecek bagaimana downstream client membaca format lama.

Untuk Agent Card v1.0, audit minimal seharusnya mencari beberapa hal.

Apakah client masih membaca agentCard.url secara langsung?

Apakah ada assumption bahwa hanya ada satu transport?

Apakah protocolVersion diperlakukan sebagai satu nilai global?

Apakah capability extended card masih dicek dari field lama?

Apakah parser mengabaikan supportedInterfaces?

Apakah cache Agent Card punya invalidation strategy ketika versi atau interface berubah?

Apakah signature verification diaktifkan jika trust model memang membutuhkannya?

Apakah analytics dan monitoring menyimpan interface yang benar-benar dipakai?

Ini bukan checklist compliance demi checklist. Setiap poin punya failure mode yang nyata.

Misalnya, client memilih supportedInterfaces[0] tanpa memeriksa binding yang didukung. Itu bisa jalan di staging karena urutan array kebetulan sesuai, lalu gagal setelah server menambah interface baru.

Atau client meng-cache public Agent Card, mengambil extended card setelah login, tetapi tetap memakai data public lama karena cache replacement tidak jelas.

Masalah seperti ini bukan headline protocol, tetapi justru sering menjadi sumber bug yang susah dilacak.

Buat tim GEO, kenapa Agent Card relevan?

GEO biasanya dibicarakan dalam konteks apakah brand mudah ditemukan, dipahami, dan dikutip oleh AI. Agentic web memperluas pertanyaannya.

Kalau ecosystem bergerak dari sekadar answer retrieval ke delegation dan agent collaboration, organisasi mulai punya surface baru untuk machine discovery. Agent Card adalah salah satu contohnya.

Bukan berarti setiap bisnis harus membuat A2A agent besok pagi. Itu terlalu jauh.

Tetapi konsepnya penting: visibility untuk agent tidak berhenti pada halaman web yang readable. Dalam sistem agent-to-agent, capability harus dapat dinyatakan dalam format yang bisa dipahami, dinegosiasikan, dan dipercaya oleh mesin lain.

Di sini struktur Agent Card v1.0 memberi pelajaran yang lebih besar.

Machine-readable presence yang matang butuh tiga hal sekaligus:

identity yang jelas,
capability yang eksplisit,
dan interface yang dapat dinegosiasikan.

Kalau salah satunya kabur, discovery mungkin terjadi tetapi action tetap gagal.

Jangan upgrade karena angka versi

Tim produk kadang punya reflex: v1.0 berarti harus segera dipakai.

Tidak selalu.

Kalau agent masih eksperimen internal, belum ada client eksternal, dan tidak ada kebutuhan interoperability, urgency bisa rendah. Tetapi kalau service sudah dipakai lintas tim atau lintas vendor, memahami struktur v1.0 menjadi penting karena ini adalah kontrak komunikasi, bukan sekadar library version.

Sebelum migrasi, tentukan siapa consumer Agent Card, binding apa yang benar-benar dipakai, bagaimana backward compatibility ditangani, dan kapan support format lama dihentikan.

Setelah itu baru bicara SDK upgrade.

Agent Card v1.0 pada akhirnya menunjukkan arah A2A secara keseluruhan: lebih eksplisit, lebih typed, lebih siap untuk version negotiation, dan lebih serius tentang trust.

Yang lama bertanya, “Di mana endpoint agent ini?”

Yang baru bertanya lebih lengkap: “Interface apa yang tersedia, protocol apa yang bicara di sana, versi mana yang compatible, capability apa yang diiklankan, dan apakah metadata itu bisa dipercaya?”

Itu bukan perubahan kosmetik.

Itu perubahan cara ecosystem agent memperkenalkan dirinya kepada mesin lain.