A2A Protocol: Cara AI Agent Menemukan dan Delegasi ke Peer

Setiap MCP server yang pernah saya kirim berhenti di batas yang sama. Server itu mengekspos function milik saya, berjalan di infrastruktur yang saya kendalikan, dengan schema yang saya tulis sendiri. Itu cukup selama kedua ujung koneksinya milik saya. Begitu pekerjaannya milik sistem orang lain, cara itu gugur, karena Anda tidak bisa menerbitkan tool schema untuk proses yang isinya memang tidak boleh Anda lihat.

Jadi saya membaca spesifikasi A2A seperti seorang ERP developer membaca standar integrasi mana pun: mencari apa yang dikatakannya tentang bagian yang gagal. Tulisan ini adalah hasil bacaan itu. Semua hal teknis di sini berasal dari spesifikasi A2A v1.0.0 dan rilis satu tahun dari Linux Foundation, sedangkan kesimpulan di akhir adalah milik saya.

MCP memberi Anda tool, A2A memberi Anda peer

Dua protocol ini terlihat bersebelahan, padahal tidak. MCP server adalah permukaan yang boleh Anda baca: setiap tool punya nama, JSON schema dan tipe hasil, dan tugas client hanya memilih lalu memanggilnya. A2A berangkat dari premis sebaliknya. Guiding principles-nya memuat Opaque Execution, yang menurut spesifikasi berarti agent berkolaborasi lewat capability yang dideklarasikan dan informasi yang dipertukarkan, tanpa perlu membuka isi pikiran, rencana, atau implementasi tool masing-masing.

Satu prinsip itu mengubah seluruh keputusan desain sesudahnya. Anda tidak bisa memvalidasi argumen milik peer, mengulang langkah-langkahnya satu per satu, atau memperkirakan berapa lama seharusnya, karena semuanya memang tidak diekspos. Yang Anda dapat adalah skill yang dideklarasikan, sebuah task id, dan sebuah state. Tugas protocol ini hanya satu: membuat antarmuka setipis itu tetap bertahan menghadapi outage, antrean approval, dan identity provider milik partner.

Agent Card adalah seluruh permukaan discovery

Sebuah A2A server wajib mempublikasikan Agent Card, dan mekanisme discovery pertama dalam spesifikasi adalah path tetap di domain server itu sendiri: /.well-known/agent-card.json. Card tersebut memuat identitas, provider, version, skill yang ditawarkan, transport yang didukung dalam urutan preferensi, serta security scheme yang harus dipenuhi pemanggil. Discovery dan authentication tinggal di dokumen yang sama, dan bagian ini yang tidak saya duga.

# The entire discovery surface: one cacheable document at a fixed path.
GET /.well-known/agent-card.json HTTP/1.1
Host: erp.contoh.co.id

{
  "name": "Delivery Scheduling Agent",
  "description": "Reserves dock time against warehouse capacity for a confirmed purchase order.",
  "provider": { "organization": "Contoh Logistik", "url": "https://erp.contoh.co.id" },
  "version": "1.4.0",

  // Ordered and normative: a client MUST take the first binding it speaks,
  // not the one it would rather use.
  "supportedInterfaces": [
    { "url": "https://erp.contoh.co.id/a2a/v1",   "protocolBinding": "JSONRPC",   "protocolVersion": "1.0" },
    { "url": "https://erp.contoh.co.id/a2a/json", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
  ],

  "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": false },

  // Discovery and auth are the same document. A caller learns what you can do
  // and which token you want in one GET.
  "securitySchemes": {
    "partner-oidc": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://sso.contoh.co.id/.well-known/openid-configuration"
      }
    }
  },
  "securityRequirements": [
    { "schemes": { "partner-oidc": { "list": ["openid", "delivery.write"] } } }
  ],

  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],

  "skills": [
    {
      "id": "book-delivery-slot",
      "name": "Book a delivery slot",
      "description": "Reserves a dock and a time window for a confirmed purchase order.",
      "tags": ["logistics", "scheduling", "erp"],
      "examples": ["Book the earliest slot for PO-2026-0184 at the Semarang DC."],
      "inputModes": ["application/json"],
      "outputModes": ["application/json"]
    }
  ]
}

Comment di dalam card itu tambahan saya; file aslinya JSON polos, dan nama field-nya diambil langsung dari contoh di spesifikasi. Dua detail layak dicontek meski Anda tidak pernah memakai A2A. Array supportedInterfaces bersifat berurutan dan normatif, sehingga client harus memilih binding pertama yang ia dukung, bukan yang paling ia sukai. Selain itu card memang dirancang cacheable: server sebaiknya mengirim Cache-Control dan ETag yang diturunkan dari field version, dan client sebaiknya melakukan revalidasi dengan If-None-Match alih-alih mengunduh ulang dokumen yang setahun hanya berubah beberapa kali.

Card juga boleh ditandatangani dengan JSON Web Signature, dan spesifikasinya tegas soal langkah yang paling sering keliru. Sebelum ditandatangani, isinya harus dikanonikalisasi memakai JSON Canonicalization Scheme, supaya card yang sama diserialisasi oleh dua library berbeda menghasilkan byte yang sama, dan karenanya signature yang sama. Card bertanda tangan adalah cara partner membuktikan daftar skill itu datang dari mereka, bukan dari siapa pun yang terakhir mengedit config Anda.

Seperti apa satu delegasi terlihat di jalur wire

A2A v1.0.0 mendefinisikan tiga protocol binding di atas satu data model, dan mengizinkan binding kustom: JSON-RPC 2.0, gRPC, serta HTTP+JSON/REST. Nama method-nya sama di ketiganya, dan itulah gunanya memisahkan binding dari model: SendMessage dan SendStreamingMessage, GetTask dan ListTasks, CancelTask, SubscribeToTask, method untuk push notification config, serta GetExtendedAgentCard. Memilih binding adalah urusan pipa. Memilih pola interaksi bukan.

# 1. Delegate. SendMessage is BLOCKING by default, and "blocking" means it
#    returns when the task reaches a terminal state OR an interrupted one --
#    not when the work is finished.
POST /a2a/v1 HTTP/1.1
Host: erp.contoh.co.id
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "messageId": "8f31c0d2-4c1e-4f9a-9a3e-1b70b0c2e5aa",
      "parts": [{ "text": "Book the earliest slot for PO-2026-0184 at the Semarang DC." }]
    },
    "configuration": {
      "returnImmediately": false,
      "acceptedOutputModes": ["application/json"]
    }
  }
}

# 2. It did not complete. It stalled -- and said so, with a question attached.
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "task": {
      "id": "9f2c1e40-6d55-4d29-9d2f-3b6c9a7f1e04",
      "contextId": "3a77b512-1f0c-49a4-bd6e-2f2a0e5d77c1",
      "status": {
        "state": "TASK_STATE_INPUT_REQUIRED",
        "message": {
          "role": "ROLE_AGENT",
          "parts": [{ "text": "Two docks are free on 11 Sep. Which one, and is a tail lift needed?" }]
        }
      }
    }
  }
}

# 3. Resume the SAME task by echoing its id. Sending a fresh message with no
#    taskId opens a DIFFERENT task -- and an opaque peer will not tell you it
#    just booked a second slot.
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "SendMessage",
  "params": {
    "message": {
      "taskId": "9f2c1e40-6d55-4d29-9d2f-3b6c9a7f1e04",
      "contextId": "3a77b512-1f0c-49a4-bd6e-2f2a0e5d77c1",
      "role": "ROLE_USER",
      "messageId": "b41d7f66-90a2-4c7d-8f1b-5c2d9e3a4f09",
      "parts": [{ "text": "Dock 2, tail lift required." }]
    }
  }
}

Baris yang paling gampang terlewat justru yang paling penting. SendMessage bersifat blocking secara default, dan blocking di sini berarti ia kembali saat task mencapai terminal state atau interrupted state. Task yang mandek adalah response yang sukses, bukan error. Setel returnImmediately ke true dan Anda langsung menerima task id, dengan konsekuensi harus melakukan polling GetTask, menahan stream SubscribeToTask, atau mendaftarkan webhook sendiri.

Dua state yang mengakui delegasi bisa mandek

Ada delapan task state, dan dua yang paling berguna justru dua yang bukan akhir. TASK_STATE_INPUT_REQUIRED berarti agent masih butuh sesuatu dari manusia sebelum bisa lanjut. TASK_STATE_AUTH_REQUIRED berarti ia butuh credential. Spesifikasi menyebut keduanya interrupted state dan memisahkannya dari empat terminal state, yaitu completed, failed, canceled dan rejected. Pembedaan itu bagian paling jujur dari dokumen ini.

Siapa pun yang pernah membangun approval chain di ERP langsung mengenali polanya. Sebuah purchase requisition tidak gagal hanya karena managernya cuti; ia menunggu. Kebanyakan protocol integrasi tidak punya kosakata untuk menunggu, jadi keadaan itu diterjemahkan menjadi timeout, padahal timeout adalah kebohongan tentang giliran siapa sekarang. A2A memberi kemandekan itu sebuah state, status message yang menjelaskan apa yang dibutuhkan, dan task id untuk melanjutkannya. Aturan in-task authorization layak dibaca utuh, tetapi empat di antaranya menentukan desain Anda:

• Agent yang meminta otorisasi wajib melacak operasinya sebagai task, memindahkannya ke TASK_STATE_AUTH_REQUIRED, dan menyertakan status message yang menjelaskan apa yang diperlukan.
• Credential sebaiknya dikirim out of band. Credential yang lewat in-band melewati setiap agent dalam rantai, dan justru karena itu spesifikasi menyarankan mengikat credential ke agent yang memintanya.
• Client yang dirinya sendiri sebuah agent boleh memindahkan task miliknya ke TASK_STATE_AUTH_REQUIRED, membentuk rantai task mandek yang berujung pada manusia. Itu delegasi yang mengakui jati dirinya.
• Perpindahan state itu sendiri bukan persetujuan. Spesifikasi menyatakan agent tidak boleh menganggap perubahan state sebagai otorisasi untuk operasi apa pun, dan credential yang diperoleh saat satu kemandekan tidak otomatis mengotorisasi message berikutnya pada task yang sama.

Terminal berarti terminal, dan itu masalah penyimpanan

Begitu sebuah task mencapai completed, canceled, rejected atau failed, ia tidak bisa dijalankan ulang. Setiap perbaikan adalah task baru yang membawa contextId yang sama, dan boleh menyebut task lama lewat referenceTaskIds. Alasannya di spesifikasi adalah kejelasan audit dan saya setuju, tetapi konsekuensinya memindahkan kerja nyata ke sisi pemanggil: Anda kini memiliki state machine kecil yang durable untuk setiap delegasi, bukan sekadar satu request dan satu response.

// Terminal is terminal: a completed, failed, canceled or rejected task cannot
// be restarted. Follow-up work is a NEW task carrying the same contextId.
const TERMINAL = new Set([
  "TASK_STATE_COMPLETED",
  "TASK_STATE_FAILED",
  "TASK_STATE_CANCELED",
  "TASK_STATE_REJECTED",
]);

const INTERRUPTED = new Set([
  "TASK_STATE_INPUT_REQUIRED", // a human still has to answer something
  "TASK_STATE_AUTH_REQUIRED",  // a credential still has to be fetched
]);

async function onTaskUpdate(task: A2ATask): Promise<void> {
  const state = task.status.state;

  if (TERMINAL.has(state)) {
    // Never send to task.id again. A revision is a new task, same contextId,
    // with the old id listed in referenceTaskIds so the audit trail survives.
    await closeDelegation(task.id, state);
    return;
  }

  if (INTERRUPTED.has(state)) {
    // The stall is the normal case, not the error path. Park it against the
    // ERP document and notify a human -- but keep the subscription open:
    // an out-of-band credential can un-stall the task with no message from us.
    await parkForHuman(task.id, task.contextId, task.status.message);
    return;
  }

  // TASK_STATE_SUBMITTED / TASK_STATE_WORKING: keep exactly one of the three
  // update channels alive -- SubscribeToTask, a push-notification webhook, or
  // a GetTask poll. Drop all three and the completion arrives nowhere.
}

• taskId dan contextId, disimpan menempel pada dokumen ERP, bukan di memory, karena task yang mandek bisa berumur lebih panjang daripada proses yang memulainya.
• State terakhir yang teramati beserta timestamp-nya, supaya worker yang baru restart tahu harus resubscribe atau membiarkannya.
• Kanal update mana pun yang Anda pilih: stream SubscribeToTask yang terbuka, push notification config yang terdaftar, atau jadwal polling GetTask.
• Aturan tentang arti pengulangan, karena SendMessage kedua tanpa taskId membuka task yang berbeda, dan peer yang opaque tidak bisa memperingatkan bahwa itu duplikat dari yang pertama.

Itulah ongkos jujur dari mendelegasikan ke sesuatu yang isinya tidak bisa Anda lihat. Pada tool MCP, crash hanya menghilangkan satu panggilan yang bisa Anda ulang. Pada task A2A, crash menghilangkan satu-satunya pegangan Anda atas pekerjaan yang masih dikerjakan partner atas nama Anda.

Posisi A2A hari ini, setelah satu tahun

Soal tata kelola sekarang sudah jelas, berbeda dengan situasi 2025. Google mengumumkan A2A pada 9 April 2025 bersama lebih dari 50 launch partner lalu mendonasikannya ke Linux Foundation. Rilis satu tahun dari Linux Foundation, bertanggal 9 April 2026, menyebut lebih dari 150 organisasi pendukung, lebih dari 22.000 bintang di GitHub, dan versi 1.0 sebagai spesifikasi stabil pertama. Rilis yang sama mencatat Agent Payments Protocol punya lebih dari 60 organisasi pendukung.

Dukungan platform mudah diverifikasi: Microsoft mengintegrasikan A2A ke Azure AI Foundry dan Copilot Studio, AWS menambahkan dukungan lewat Amazon Bedrock AgentCore Runtime, dan Google Cloud juga mengirimkannya. Lima SDK disebut sudah production-ready, mencakup Python, JavaScript, Java, Go dan .NET. Pemakaian produksi disebut per vertikal, bukan per pelanggan, yaitu supply chain, financial services, insurance dan IT operations. Perhatikan apa yang tidak dikatakan kalimat itu. Tidak ada nama perusahaan, dan saya tidak akan menyusun roadmap di atas referensi tanpa nama.

Yang akan saya kirim kuartal ini, dan yang tidak

Untuk tim kecil, jawabannya sengaja asimetris: publikasikan Agent Card, jangan bangun peer mesh dulu. Mempublikasikan berarti satu file JSON statis ditambah endpoint yang bisa menjawab SendMessage untuk satu skill sempit. Sisi konsumsi yang mahal, karena di sana ada task store yang durable, penanganan interrupted state, urusan credential, dan partner yang mau menandatangani kesepakatan tentang apa yang boleh dilakukan agent mereka terhadap data Anda.

1. Tulis Agent Card untuk satu skill yang benar-benar rela Anda buka ke pihak luar, dan sajikan di path well-known di balik SSO yang sudah ada.
2. Implementasikan SendMessage dan GetTask di atas binding JSON-RPC untuk skill tunggal itu. Dua method saja sudah menjadi agent yang berfungsi.
3. Kembalikan TASK_STATE_INPUT_REQUIRED dan TASK_STATE_AUTH_REQUIRED secara jujur alih-alih memblokir atau menggagalkan, lalu simpan taskId dan contextId pada record ERP yang bersangkutan.
4. Berhenti di situ sampai ada partner bernama yang minta memanggil Anda. Membangun sisi keluar tanpa lawan bicara hanya menyisakan protocol client yang Anda rawat untuk satu pengguna imajiner.

State machine-nya adalah bukti untuk urutan itu. Semua yang mahal dari A2A berada di sisi pemanggil: interrupted state, aturan melanjutkan task, dan kenyataan bahwa terminal berarti final. Sisi penyedia hanya sebuah dokumen dan dua method.

MCP membuat tool milik sebuah agent jadi portabel. A2A berusaha membuat rekan kerja sebuah agent jadi portabel, dan itu lebih sulit, karena seorang rekan bisa menjawab belum sekarang. Nilailah protocol ini dari task lifecycle-nya, bukan dari jumlah partnernya. Standar yang menjadikan input-required dan auth-required sebagai state kelas satu adalah standar yang memang memperkirakan pekerjaan nyata akan mandek, dan perkiraan itulah alasan ia pantas diperhatikan tim ERP kecil sekarang, sebagai card untuk dipublikasikan, bukan mesh untuk dibangun.