Deep dive into A2A's architecture — Agent Cards, Messages, Task lifecycle, streaming, and JSON-RPC methods.
A2A Architecture · 7 minsTranscript10 entries
Instructor:Welcome back to LocalM Tuts. I am Nilay Parikh. This is lesson 3 of 16 a A2A architecture deep dive. Last time we explored why A2A exists and the five design values where it fits in the agent stack. If you are watching this as a standalone video and find the complete course in the playlist below. If you are eager to jump straight to the code, hands on lessons start in lesson 5, but this architecture session is especially important. Agent Card, the task state machine, SSE streaming are the
Instructor:concept you will implement directly in the coding lessons. Understanding them here will save your time. When you're writing the code. A2A is organized in 3 layers at the bottom. The data model defined in protocol buffers is a canonical source about that abstract operations such as like SendMessage GetTask on top protocol binding. The concrete wire formats this back currently defined 3 protocol bindings. JSON-RPC 2.0 O HTTP, gRPC and HTTP. In this course, every server you will build
Instructor:use JSON-RPC, which is the most common binding in the ecosystem. So let us start with cornerstone of discovery, the agent card. Every A2A server published the JSON document at the well known path, which is slash dot well known slash agent-card. JSON. The agent card has 3 main sections, first identity. Such as name, description, version, URL. The second supported interfaces. An array of interface object such as carrying URL protocol, binding protocol version. The 3rd capabilities boolean
Instructor:and arrays describing what an agent can do. Streaming support, push notification, and extensions and the skill with ID, name, description, tag, example prompts, input modes and output modes. Now messages and parts. When a client sends work to an agent. It sends message. Every message has a role either its a user or agent. And an array of parts a part is one of the types: Text raw bytes, URL reference structured data. Each part can carry metadata. filename media type. Extra key value
Instructor:pairs. This means you can send plain text, upload a CSV, reference a cloud Storage URL, or pass the JSON schema all in the same message. The task is the central coordination object. When you call send message the server creates the task with unique ID, the task moves through the state submitted, working, completed, failed, cancelled, also, the A2A 1.0 spec adds 2 new state. Input required whether agent pauses to ask user For more information and the auth required whether agent need additional
Instructor:authentication from the client. Let us look at this state machine on the screen. The Mermaid diagram shows all the transitions. Notice if you notice the input-required and auth-required loop back to working. The terminal states are completed, failed or cancelled. When they pass completed, it produces an artifact. An artifact generally has an ID. and an array of part for streaming. The append and lastChunk flags let the server set an artifact incrementally. Speaking of streaming, when you call
Instructor:SendStreamingMessage instead of a send message, the server opens an SSE Server-Sent Events. The connection and push is the task status. Update event and task artifact update. Each event carries the full task ID, updated status or artifact. When the status is a final set to true, the stream closes. This is how you get real time token streaming from any A A2A. Here are the core JSON-RPC methods: SendMessage and send streaming message for task creation, GetTask, ListTasks for query, CancelTask for cancellation
Instructor:SubscribeToTask for push notification. And then the push notification methods such as SetTaskPushNotification, get task push notification plus some other runtime capability discoveries. One important detail that all JSON and RPC methods use PascalCase SendMessage. Not the tasks/send. The server handles the single HTTP endpoint, typically at the root path. Let me show you the full interaction sequence, a client first fetches the agent card via GET, then SendMessage with the JSON
Instructor:RPC request. The server returns task in initial state, process it and returns the update. For streaming the same sequence use. SendStreamingMessage message the server responds with SSE stream each event in JSON line with task update. The last event has final set to true. Extensions are how A2A stays forward-compatible any new. Capability, custom auth flows, multi turn workflows, domain specific metadata can ship as an extension without changing the core spec. Extensions are declared in agent card
Instructor:capabilities section. The client checks for supported extensions before using them. This pattern keeps the core protocol stable while allowing the ecosystem innovation. Thanks for watching this lesson on the LocalM Tuts. I am Nilay Parikh. In the next session we will set up the development environment Python A2A SDK, GitHub Models, Azure AI Foundry and the course repository. You can find in the next video in the A2A protocol course playlist. See you there.
Interpret the Agent Card structure and discovery mechanism
Trace a Task through its full state machine (eight states including INPUT_REQUIRED, AUTH_REQUIRED, and REJECTED)
Explain how SSE streaming delivers real-time task updates
Q&A
Q & A
Q
What is an Agent Card and where is it published?
An Agent Card is a JSON document describing the agent's identity, skills, capabilities, supported interfaces, and authentication requirements. It is published at /.well-known/agent-card.json. Clients fetch this card to discover what the agent can do before sending any tasks.
Q
How does streaming work in A2A?
Streaming uses Server-Sent Events (SSE). The client calls SendStreamingMessage and the server opens an SSE connection. The server pushes TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects as JSON lines. Artifacts can stream incrementally via the append and lastChunk flags. The stream closes when the final status event has 'final: true'.
Q
What are the three protocol bindings in the RC v1.0 spec?
JSON-RPC 2.0 over HTTP (the most common, used in this course), gRPC (for high-performance inter-service communication), and HTTP+JSON/REST (a REST-style binding). Each agent declares which bindings it supports in its Agent Card via the supportedInterfaces array.
Q
What is the difference between INPUT_REQUIRED and AUTH_REQUIRED states?
INPUT_REQUIRED means the agent needs additional information from the user to continue — it pauses and waits for the client to send more context. AUTH_REQUIRED means the agent needs the client to authenticate with additional credentials. Both states loop back to WORKING once the client responds.
