Membongkar Task sebagai unit kerja: state machine dari submitted, working, input-required, hingga completed/failed/canceled, beserta progress dan metadata. Lalu membedah Message/Part dengan role user dan agent, tipe part text/file/structured, serta streaming delta.

Di episode 3 kita memahami bagaimana sebuah agent ditemukan lewat Agent Card. Sekarang kita masuk ke inti eksekusi: apa yang terjadi setelah client mengirim pekerjaan. Semua itu diatur oleh Task lifecycle dan Message/Part.
Episode 4 menjawab dua pertanyaan: di mana sebuah task berada dalam perjalanannya? dan bagaimana konten percakapannya direpresentasikan? Dengan menguasai kedua konsep ini, kalian akan membaca dan menulis traffic A2A tanpa kebingungan.
Sebuah Task adalah unit kerja tunggal dalam A2A — satu permintaan dari client agent yang dikerjakan remote agent. Setiap task membawa identifier, status, dan riwayat message. Karena task adalah object JSON, seluruh progress-nya bisa di-query kapan saja.
{
"id": "task-7f3a",
"status": {
"state": "working",
"message": {
"role": "agent",
"parts": [
{
"text": "Sedang memproses laporan keuangan..."
}
]
}
},
"messages": [],
"metadata": {
"request_id": "req-0001"
}
}Field id menjadi pegangan seluruh percakapan berikutnya. status merefleksikan posisi task saat ini, messages menyimpan riwayat lengkap, dan metadata menampung data tambahan yang disepakati kedua belah pihak.
Status task mengalir melalui state machine yang telah distandarkan. Tidak ada status di luar daftar ini:
submitted --> working --> input-required <--+--> completed
| |
+-----> failed |
+-----> canceled <-----------+submitted — task baru diterima remote agent, belum diproses.working — remote agent sedang mengerjakan task.input-required — agent butuh informasi tambahan dari client sebelum melanjutkan; task kembali ditunda menunggu pesan baru.completed — pekerjaan selesai dan hasil akhir tersedia.failed — terjadi error; detail kegagalan dibawa di dalam status.canceled — task dibatalkan, baik oleh client maupun remote agent.Transisi dari working ke input-required adalah mekanisme utama pola human-in-the-loop — saat agent menemui persoalan yang butuh keputusan manusia. Client yang menerima status ini mengirimkan message balasan, dan task melanjutkan dari working kembali. Saat berpraktik nanti, transisi ini bisa diamati langsung lewat curl -s -N http://localhost:8080/sse?taskId=task-7f3a.
Task yang berjalan lama tidak bisa hanya diam menunggu. A2A menyediakan dua mekanisme untuk membuat progress terlihat:
{
"status": {
"state": "working",
"progress": {
"current": 2,
"total": 5,
"message": "Meringkas halaman 2 dari 5"
}
}
}current dan total yang memperlihatkan seberapa jauh pekerjaan berjalan.Kedua informasi ini sangat berguna untuk observability — misalnya mengukur durasi setiap tahap. Nanti di episode 15, kita akan melihat bagaimana metadata ini dihubungkan ke OpenTelemetry untuk tracing end-to-end.
Info
Field progress bersifat opsional. Agent boleh mengirimkannya hanya saat streaming atau polling; pada task singkat, progress biasanya tidak pernah dikirim sama sekali.
Percakapan dalam task direpresentasikan sebagai rangkaian Message. Setiap message memiliki satu role yang menunjukkan siapa pengirimnya:
| Role | Pengirim |
|---|---|
| user | client agent yang mengirim permintaan |
| agent | remote agent yang memberikan respons |
{
"role": "agent",
"parts": [
{ "text": "Analisis selesai. Berikut temuan utamanya..." }
]
}Role ini membantu kedua belah pihak memahami konteks percakapan — dan juga menjadi data penting untuk audit log di kemudian hari (topik episode 15). Urutan message di dalam task.messages mencerminkan kronologi percakapan.
Setiap message berisi satu atau lebih Part, dan setiap part memegang satu bentuk konten. Tiga tipe inti:
{
"role": "agent",
"parts": [
{
"text": "Berikut hasil analisis dalam beberapa format."
},
{
"file": {
"name": "laporan-triwulan.pdf",
"mimeType": "application/pdf",
"url": "https://analisis.example.com/dl/laporan.pdf"
}
},
{
"structured": {
"data": {
"risiko": "tinggi",
"skor": 87
}
}
}
]
}dataURI, lengkap dengan mimeType dan nama berkas.Kekuatan model Part: satu message bisa mengirim penjelasan, dokumen, dan data terstruktur secara bersamaan — persis kebutuhan kolaborasi agent nyata. Episode 8 akan mengupas tipe konten ini lebih dalam.
Untuk hasil yang dikerjakan lama, client tidak harus menunggu task selesai. Dengan streaming, remote agent mengirimkan message parsial secara bertahap melalui SSE — inilah yang disebut streaming delta.
agent --> [delta 1] "Menganalisis..."
agent --> [delta 2] "menemukan anomali pada"
agent --> [delta 3] "cabang Surabaya."
agent --> [status: completed]Setiap delta adalah message berstatus working yang membawa potongan hasil. Client bisa menampilkan potongan tersebut secara real-time sambil terus menunggu status akhir completed. Inilah perbedaan pengalaman antara polling penuh dan pengalaman streaming yang terasa langsung.
Inilah inti yang harus dibawa pulang:
id, status, messages, dan metadata.submitted, working, input-required, completed, failed, canceled.input-required menjadi dasar pola human-in-the-loop dan dialog lanjutan antar agent.user dan agent, membawa satu atau lebih Part.completed.Di episode 5 kita membedah lapisan protokolnya: JSON-RPC methods & binding HTTP — metode message/send, tasks/get, tasks/cancel, tasks/pushNotificationConfig, dan messages/list, plus bagaimana POST ke satu endpoint dan SSE menghidupkan seluruh lifecycle di atasnya. Sampai jumpa!