0:00We have an analyst serving behind its card, and clients of our own that ask it for a brief. Everything they have sent each other, we saw only after the SDK had turned it into objects.
0:11Those objects did not cross the network. The two sides were exchanging HTTP requests with JSON bodies.
0:17So, where the analyst was listening, we put a small program of our own, and started the analyst behind it on another port.
0:23Both of our clients went through it on one question. The one that asks for the task again, and the one that streams.
0:29Neither client changed, and nothing in the exchange did. What it left behind is one file holding the whole sitting.
0:37This is the program that wrote that file. Fifty three lines, and nothing in it understands agent to agent.
0:42It starts the analyst on a port of its own, and opens the file it is going to write.
0:47The rest of it is one loop.
0:48It reads a chunk from one side, writes it to the other untouched, and writes the same chunk down.
0:54That is the whole tap. Let's open what it left behind.
0:58Over a thousand lines, both directions, in the order they crossed.
1:01The first thing across is a GET for the card, at the well known address.
1:05One header rides with it, naming the version of the protocol the client speaks. Every request in this file carries it.
1:12It comes back as a JSON document, the card we wrote. There is no handshake, and no session to open.
1:17Underneath it is that card in full. Further down is the question.
1:21It goes out as one POST, to the one address the card named.
1:25The body is an envelope, and this line names the operation.
1:28The spec defines three of these envelopes, and an agent may offer any of them.
1:32Ours is the JSON-RPC one, which is what the card said. The operations and the task inside are the same whichever one an agent offers.
1:40Back in our own envelope, the parameters hold two things.
1:43Our question, and the role that sent it.
1:46And one setting, which asks the agent to answer as soon as there is a task, rather than when the work is done.
1:52Last, an id of the envelope's own, so the answer can be matched to this request.
1:57What came back is not the brief. It is a task.
1:60An id of its own, the context it belongs to, and a state. Submitted means the agent has it and has not started.
2:07The rest of it is the message we sent. Nothing is finished, so there is no artifact anywhere in here.
2:13A second later, the client asks for that task again.
2:16The same envelope, with a different operation and one parameter. The id of the task it wants.
2:21Canceling a task, or subscribing to one, is this same envelope again under its own name.
2:26The answer is the whole task again, and this time the state says working.
2:31That exchange runs thirteen times, once a second, and twelve of the answers say the same thing. This is the thirteenth.
2:38Its state is completed, and the task carries something it did not carry before.
2:43The brief, on the task as an artifact, under a name and an id of its own.
2:48Every one of those answers came back because the client asked for it. The other client in this file never asks twice.
2:55It starts the same way the first one did, by fetching the card before it sends anything.
2:59Then its question goes out, and most of this request is the same as the one we read.
3:04One line is new. The client says it will take an event stream.
3:08And the operation has a name of its own, for the send that streams.
3:12At the foot of it, an id for this one request.
3:14Marked, so we can follow it. Every time it turns up from here on, it is this one request being answered.
3:22The reply says it is an event stream, sent in chunks. So it never closes on one body the way the others did.
3:29Each chunk is a size, then one data line carrying one event.
3:32The first of them is the task itself, submitted, which is what the other client was handed.
3:38The agent keeps sending while it works.
3:40This update carries a message from the analyst, saying what it is fetching and why.
3:45Then the deliverable.
3:47The brief comes back as an event of its own, on the same task, named the way it was on the other run.
3:52The fifth and last event closes the task.
3:55Completed, with a time on it, and nothing left to send.
3:58The same id on the last event, as on all the others. Five events, and every one of them answers that single request.
4:05Then a chunk of length zero, and the connection is finished.
4:10What crossed was ordinary. A GET for the card, a POST for every request, and JSON in the bodies both ways.
4:16What makes it agent to agent is what those bodies carry. Where a function would have returned an answer, the reply carried a task.
4:23And when our client asked to be told as the work happened, that one request stayed open. Every event on it came back under the same id.
4:31Next time the analyst keeps serving exactly this, while its own lookup moves behind an MCP server.

What Goes Over the Wire

Created by Abhyuday DesaiPublished 4 Oct, v1 of 2Runs 4 min 36 sec

0 views

About this video

In Episode 08 of A2A Explained, a small proxy sits where the analyst listens and writes both directions of one sitting to a file. We read that file line by line: the GET for the card at its well-known address, the POST that carries the question, the task that comes back before any work is done, the repeated asks while it runs, and the streaming call whose reply stays open and arrives as separate events.

You'll learn how to:

Read an agent to agent exchange as what it is: HTTP requests with JSON bodies
Recognize the JSON-RPC envelope, its method name, its parameters and the id the answer carries
See why the reply to a send is a task rather than a result
Tell the three bindings apart, and know that they carry the same methods and the same task
Spot the protocol version that rides on every request as a header
Follow a streaming reply: one request left open, each event its own JSON, all answering the same id

This video is for developers who know MCP's vocabulary. The code is in the series repo, pinned to the commit the video shows.

What changed

v204 Oct 2026abhydesai4 min 42 secre-render of the same sourcea216515

Re-recorded with the closing attribution card, which the first cut left out.

Same chapters and transcript. 6 sec longer.

0 views0 likes on this version

Watch v2

v104 Oct 2026abhydesai4 min 36 seca216515

First published version.

0 views0 likes on this version