Learn A2A - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood why A2A was born: agents from different frameworks need a shared language, and interaction was chosen to be as opaque peers. Now it's time to see how this protocol is structured.

Episode 2 is a concept map. You'll understand the two main roles — client agent and remote agent — and then the four building blocks: Agent Card, Task, Message/Part, and protocol bindings. Each block will be dissected more deeply in episodes 3 to 5, so focus on how everything fits together into one flow.

#Two Roles: Client Agent and Remote Agent

The entire A2A architecture rests on two roles:

• Client Agent — the party that sends the task. It starts the conversation, requests work to be done, and receives the result.
• Remote Agent — the party that receives and completes the task. It provides an agent service through an HTTP endpoint.

It's important to understand: these roles are not permanent. An agent can be a client in one collaboration and a remote agent in another. This is the peer-to-peer nature we discussed in episode 1 — there's no permanent hierarchy between the two roles.

Client Agent  --(1) fetch Agent Card-->  Server endpoint
Client Agent  --(2) send task-------->  Remote Agent
Remote Agent  --(3) reply status------>  Client Agent
Remote Agent  --(4) send result------->  Client Agent

#Agent Card: The Discovery Gateway

Before sending a task, a client agent must discover and understand the remote agent. This is where the Agent Card comes in — a JSON document the remote agent publishes at its public URL. Its contents describe who the agent is and what it can do:

{
  "name": "Agent Dukungan",
  "description": "Membantu troubleshooting produk",
  "url": "https://dukungan.example.com",
  "capabilities": {
    "streaming": true
  }
}

The concept is exactly analogous to OpenAPI: before calling an API, a client reads its spec. The difference is that the Agent Card focuses on agent capabilities, not just a list of endpoints. Episode 3 will dissect every field. To see a card in its raw form, try curl -s https://dukungan.example.com/.well-known/agent-card.

#Task Lifecycle: The Communication Contract

A single unit of work in A2A is called a Task. The Task is the "thread" that connects the entire conversation between the client and the remote agent. Each task has an identifier, a status, and a message history.

{
  "id": "task-123",
  "status": {
    "state": "working"
  },
  "messages": []
}

The task status flows through a state machine: from submitted, it becomes working, can stop at input-required if the agent needs additional information, and ends at completed, failed, or canceled. We'll dissect this state machine completely in episode 4.

#Message and Part: Multimodal Content

A conversation within a task is represented as a sequence of Messages, and each message contains one or more Parts. The beauty of this model: content is not limited to text.

An agent can send a result made up of text plus a CSV file plus structured data in a single message. This multimodal capability is what sets A2A apart from a plain text API — and we'll put it into practice in episode 8.

#Protocol Bindings: JSON-RPC, HTTP, gRPC, and SSE

A2A doesn't bind itself to a single transport. Its data model is defined over JSON-RPC 2.0, but it can be carried over several bindings:

• JSON-RPC over HTTP — the primary binding; requests are sent via POST to a single endpoint.
• SSE (Server-Sent Events) — a streaming channel for real-time results from the remote agent to the client.
• gRPC — available since v0.3, suitable for high throughput and backpressure (details in episode 11).

This separation between the data model and transport makes A2A flexible: the protocol logic doesn't change when you move from HTTP to gRPC. This is one reason its design has survived to v1.0.

#Putting All the Components Together

Now let's assemble all the blocks into one complete flow. An A2A collaboration runs like this:

1. The client agent loads the Agent Card from the remote agent's URL to learn its capabilities and authentication method.
2. The client sends a task via the message/send method over the JSON-RPC over HTTP binding.
3. The remote agent responds with a task status, moving from submitted to working.
4. If streaming is enabled, partial results flow over SSE as a series of Message/Part objects.
5. The task finishes with the completed status, carrying the final multimodal result.
6. The client can read the entire conversation at any time via the tasks/get method.

Technically, step two looks like this over HTTP:

curl -s -X POST https://dukungan.example.com \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":"1","method":"message/send","params":{"message":{"role":"user","parts":[{"text":"Bantu analisis log error"}]}}}'

All these steps work without the client ever seeing the remote agent's internal state, memory, or tools — consistent with the opacity principle we learned in episode 1.

#Conclusion

Here's the core takeaway:

• A2A's architecture consists of two dynamic roles: client agent and remote agent.
• The Agent Card is JSON metadata for discovery, analogous to OpenAPI.
• A Task is a single unit of work that carries the entire conversation and its status.
• Message/Part enables multimodal content: text, files, and structured data.
• The JSON-RPC 2.0 model can be carried over HTTP, SSE, and gRPC without changing the message content.

In episode 3 we dissect the first component thoroughly: Agent Card & discovery — from the agentName, description, capabilities, skills, and authentication fields to the signed security cards in v1.0. You'll learn to read and write your own Agent Card. See you there!