Index of figures

Every figure in the manual, by the claim it makes.

Each number links to its figure, and the claim is the bold sentence that opens the caption.

Fig.	The claim it makes
0.1	Each of the seven arrow styles marks one kind of exchange, and the label on each arrow is a real name from a run of the kit.
1.1	A2A defines the card, the bindings, the operations, and the objects, while test-runner's server parts and agent logic below the dashed line belong to its owner.
1.2	A2A fixes the messages, states, and events between agents, while trust, discovery, retention, and exactly-once effects stay with the host.
1.3	A streamed task opens with the task itself, reports its work as status and artifact frames, and ends when the server closes the stream after the terminal status.
2.1	One `GET` returns what a client needs before its first message: who the agent is, where to reach it, what it demands, and what it offers.
2.2	Three routes lead to one card, and a client takes the first interface it speaks and checks a capability flag before each optional operation.
2.3	The same `GetExtendedAgentCard` call fails with HTTP 401 before any A2A method runs, then returns a card with a second skill once a token is attached.
2.4	The signature covers the RFC 8785 bytes of the card without `signatures`, so an edit to the description changes those bytes and verification fails.
3.1	A message carries an id its sender mints, while its `contextId` and `taskId` come from the server and the client echoes them to continue.
3.2	The kit's captures use all four kinds of part, and only the `image/png` part fails, because `code-reviewer` does not accept that media type.
3.3	The five chunks of `test-log.txt` become five parts of one stored artifact in frame order, and `lastChunk` ends that artifact while the stream continues.
3.4	A task carries its own id, its context, one current status, its artifacts, and its history, and every message and artifact inside it is made of parts.
3.5	The kit's captures show nine transitions between task states, and none of them leaves a double-bordered terminal state.
3.6	The review task holds both exchanges of the conversation, and a follow-up review joins the same context as a new task, because the review task is terminal.
4.1	The same `SendMessage` to `code-reviewer` returns a message for a question and a task for a diff, and only the task gives the client something to follow.
4.2	A blocking send holds one request open until this task completes, while `returnImmediately` answers at `TASK_STATE_SUBMITTED` and leaves the client to poll.
4.3	The question arrives as the status message of a paused task, and the answer is a new message that carries the same task and context ids.
4.4	The deploy waits in `TASK_STATE_AUTH_REQUIRED` while the stream stays open, and the operator's approval travels outside A2A before the same stream carries the result.
4.5	`GetTask` trims history to the newest messages you ask for, and `ListTasks` returns newest-first pages that leave out artifacts until you ask for them.
4.6	The agent chose three of these endings and the client one, and once a task ends, the server refuses any further message or cancel.
4.7	A dropped stream loses the frames sent while it was closed, and SubscribeToTask resumes with a Task snapshot that already holds their content.
4.8	With a webhook registered, test-runner posts eight StreamResponse bodies to the planner's receiver after the SendMessage call has already returned.
5.1	JSON-RPC posts every operation to one URL and names it in the body, HTTP+JSON names it with a verb and a path, and gRPC calls an rpc.
5.2	One rpc sends the request with its metadata, the server streams StreamResponse messages until the task ends, and the rpc status closes the stream.
5.3	The same TaskNotFoundError arrives as HTTP 200 with code -32001 in JSON-RPC and as HTTP 404 in HTTP+JSON, carrying the same ErrorInfo.
6.1	The card names the scheme, HTTP rejects a request without the token before A2A runs, and a running task can still stop for an approval.
6.2	The card lists the extension, the request names it in `A2A-Extensions` and keys its data by the URI, and a missing required extension answers -32008.
6.3	Data crosses six boundaries in the kit's system, and each needs a check of its own, because A2A labels nothing it carries as safe.
7.1	The planner reads three cards, delegates three skills in turn, answers a question, escalates an approval, and decides from data parts before each next step.
7.2	A request passes authentication, the version check, and the capability check before Agent.send stores a task, and every event then leaves through one broadcast.
7.3	The planner sees only each agent's card and endpoint, while each agent calls its own logic and tools below a line that A2A never crosses.

A2A protocol 1.0.1 · 3303592 · 2026-05-28 · Edition 2026.10