0:00So far our client has stayed connected while the analyst writes its brief, either asking again or listening.
0:07This time it sends the question, and the analyst opens a task and starts working on it.
0:12The reply carries the new task's id, and the client keeps that id.
0:16Then the client goes away while the analyst is still working. It hung up, or its network dropped.
0:22The task is stored on the server, so the analyst carries on and finishes the brief either way.
0:27So the brief can still reach the client. It can come back later with that id and ask.
0:32Or it can leave an address with the analyst, and be told about each update as it happens.
0:37Let's look first at the client that comes back.
0:41This client starts by sending the question the same way our streaming client did.
0:45It listens until the first status update, which means the analyst is working, and keeps the task's id from it.
0:51Then it closes the connection and waits. How many seconds it stays away comes from the command line.
0:57When it comes back, it connects from scratch and asks for that task by its id. It can't know yet whether the task has finished.
1:03A subscription is only allowed while a task is still going, so this check comes before it.
1:07If it is still going, the client subscribes. The first event is the task as it is now, and the updates follow.
1:15If it has finished, the brief is already in the task the client just got, so there's nothing to subscribe to.
1:21Let's run it, and come back while the analyst is still working.
1:24The number at the end is three, so the client comes back after three seconds, well before the brief is done.
1:31It hung up as soon as the task was working, holding only the id.
1:34Three seconds later it was back, and the task it got was still working.
1:38So it subscribed, and the subscription opened with the task as it was at that moment.
1:42Then came the update the analyst published while it worked, with the reason for its lookup.
1:47Then the brief, and the completed status, which ended the subscription.
1:51Now let's stay away long enough for the brief to be finished before we come back.
1:55This time the client stays away for forty seconds.
1:58It hung up the same way, as soon as the analyst was working.
2:01Back after forty seconds, the task it got was already completed.
2:05The brief came back inside the task, so the client printed it and never subscribed.
2:09Either way the brief reached the client, because the server kept the task under its id.
2:14For the other way, the analyst calls the client. Let's look at what its server needs for that.
2:21This is the file that serves our analyst, and two things in it are new.
2:25Its card now says it can send push notifications, so a client knows it can leave an address.
2:31And the server keeps the addresses clients give it, with a sender that posts each task's updates to them.
2:37Let's run a client that leaves an address.
2:40This client runs a small web server of its own, and sends that address and a token along with the question.
2:46It sent the question and hung up straight away. The analyst's first events reached the webhook right after.
2:51Each one is an event a stream would carry, posted to the webhook with the token the client chose.
2:56The brief arrives the same way, in an artifact update.
2:59Then the completed status, and the client stops listening.
3:03The client never connected to the analyst again. Every update came to its own address, and that is a push notification.
3:12Our analyst still runs only on this machine. Serving it to others takes a few more things.
3:18Both clients relied on the server keeping the task. Ours keeps its tasks in memory, so a restart would lose them.
3:26The SDK also ships a task store backed by a database, which a service others depend on would use.
3:32Then there's the address it serves on.
3:34Served to others, the card has to name an address they can reach.
3:37Ours names one that only this machine can reach.
3:40In front of it, callers would also have to prove who they are.
3:43The card declares how they do it, and OAuth is a common way.
3:46The analyst also calls whatever address a client leaves, so a real agent refuses addresses on its own network. Ours, running locally, doesn't.
3:56Everything else is the same as running any web service. Let's look back at what the series built.
4:02This series began with another team's agent, built by other people on another framework, and the question of how to hand it work.
4:09The idea came down to two things. The card says what an agent can do, and the task carries the work.
4:16Then we built our own analyst and followed its tasks from the client's side, down to the messages on the wire.
4:22And in this last section it worked beside another team's agent, and its tasks carried on after the caller left.
4:28With a card to read and a task to follow, a client can hand work to an agent, whoever built it.
4:33That's the job of agent to agent, one agent handing work to another that plans its own steps.
4:38Connecting a model to what it can use is MCP's job, and that was the other series. Thank you for watching.

A Task That Outlives the Call

Created by Abhyuday DesaiPublished 4 Oct, v1Runs 4 min 50 sec

0 views

About this video

In Episode 12 of A2A Explained, the series finale, our client sends the analyst a question and hangs up before the brief is written. The task is kept on the server under its id, so the work carries on, and the brief still reaches the client in one of two ways: the client comes back and asks for the task, or it leaves an address and the analyst calls it with every update.

You'll learn how to:

Come back to a task by its id: ask for it first, then subscribe only if it is still going
Read what a subscription sends: the task as it is now, then every update that follows
Switch on push notifications in a served agent: one capability on the card, a store and a sender in the server
Watch a client that never reconnects receive the whole brief at its own webhook
Name what serving an agent for others adds: a durable task store, a public address, a security scheme, and checking the webhook addresses it calls

The episode closes the series: what the three sections built, and where agent to agent ends and MCP begins. The code it runs is in the series repo, pinned to the commit the video shows.

What changed

v104 Oct 2026abhydesai4 min 50 sec36e2c95

First published version.

0 views0 likes on this version