0:01Last time we saw that one agent can hand work to another, over one agreed form. Before ours sends a job, though, it has to find the other agent and learn what it offers.
0:11Let's start with the MCP server, because that order is the one we know. Our agent connects to it first.
0:18Then it asks what the server offers, and the list of tools comes back over the connection it just opened.
0:24So with MCP, our agent learns what is on offer after it connects. That is the order we know.
0:30With another agent, the order is the other way round.
0:33The agent publishes a document about itself, called its agent card, and the card is there whether anyone is connected to the agent or not.
0:40It is served at a fixed path under the agent's own address. A client gets the address from a registry or from its own configuration, and then it knows where to look.
0:49That path is part of the standard, so it is the same for every agent.
0:52One plain web request, and the card is back. No work has been sent to the agent yet.
0:57And our agent already knows a good deal about the other side.
1:00What the agent is called, what it is for, the skills it offers, and where to send work. All of it was in the card.
1:08That is enough to decide whether this is the right agent for a job, and where to reach it.
1:12Only now does work go to the agent, at the address the card gave. So with agent to agent, the order is read first, then connect.
1:22Let's read what is in the card.
1:24Every agent that speaks agent to agent publishes one of these, and the protocol fixes which fields it has.
1:30The first two are for people as much as for programs. A name, and a description of what the agent does.
1:36Then where to send work. An agent lists one or more interfaces.
1:41Each one is an address where messages go, and the binding they are wrapped in. JSON-RPC over HTTP is the one this series uses.
1:49Skills are the heart of the card. This is the contract we named last time: a description of what the agent can do, in words, not a schema of arguments.
1:59Each one has an identifier the client can refer to, and a name for a reader.
2:03The description says what the skill does, and the examples show what to ask. A client, or its model, reads these to tell whether this is the right agent for a job.
2:14Capabilities say what the agent supports beyond a plain send.
2:17Results delivered as they happen, and a notification when work finishes. Both come up in section two.
2:24And security schemes say how a client must prove who it is before the agent takes work.
2:29An API key, a bearer token, or a sign-in flow. Those are the main fields. So who reads the card, and who is behind it?
2:38The side that reads the card and sends the work is the client. In agent to agent, that word means the whole program doing the sending.
2:47Ours has a model of its own, but a client does not need one. A plain program that reads a card and sends one message is a client too, and the protocol does not distinguish.
2:57The side behind the card is the remote agent. Remote because it is somewhere else, behind an address, and an agent because it plans its own steps.
3:07Behind the address is a whole agent, built by that team.
3:10It has a model of its own and tools of its own, and both were that team's choice.
3:14From the client's side none of that is visible, and none of it is in the card.
3:18Everything the client knows about the other side is in that one document. It says what the agent can do and where to send work, so the job goes to that address.
3:29The result comes back, and how it was made stays behind the card. A card promises what, and never how. And our agent can be on the other side of one too.
3:38Suppose an app that a user talks to hands our agent a job.
3:41That exchange follows the same protocol, and in it our agent is on the other side.
3:46The labels were roles in one exchange. Toward their agent ours is the client. Toward this app it is the remote agent, behind a card of its own.
3:54Work comes in from the app.
3:56Part of it goes on to their agent, and section two builds our agent and the card it publishes.
4:00Next time we follow the work itself.
4:02What one agent sends to another, and what comes back while the job is being done.

The Agent Card

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

0 views

About this video

In Episode 02 of A2A Explained, A2A first departs from MCP in a visible way. In MCP the host connects and then asks what is offered; in A2A you read the agent card before any connection. The episode shows what the card holds, where it lives, and who the parties are.

You'll learn how to:

Find a card at its well-known address, and read what an agent publishes about itself: name, description, where to send work, skills, capabilities, security schemes
Name the roles on one picture: the client that reads cards and sends work, the remote agent behind the card, the user upstream of both
See that the same program can be client to one agent and remote to another
Hold the rule the section builds on: the card is a promise about what the agent can do, and nothing about how

This video is for developers who know MCP's vocabulary. The card's JSON is shown live in Episode 04.

What changed

v204 Oct 2026abhydesai4 min 12 secd7f62ff

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

Same chapters and transcript. 5 sec longer.

0 views0 likes on this version

Watch v2

v102 Oct 2026abhydesai4 min 7 sec484dddd

First published version.

0 views0 likes on this version