Agent-to-Agent(A2A) Protocol Explained
Key Takeaways
The Agent-to-Agent (A2A) protocol enables seamless interaction between agents built by different organizations, allowing them to plug straight into each other's systems. This protocol is explained in detail, covering its basics, benefits, and applications.
Full Transcript
When you build an agentic system, how you orchestrate your agents is in your hands. For example, you can have a boss agent and multiple worker agents. And the boss [music] agent might allocate work during runtime to these worker agents. [music] This type of system has a lot of benefits. They actually are in your control. But what if you are able to use an agent which is not created by you, not even created by your organization? It is created by some other organization, some other ecosystem. But you are able to use them into your ecosystem for your use case. Wouldn't that be great? So, thankfully, we have a protocol which connects two [music] agents together and we call it A2A or agent-to-agent protocol. In this video, we're going to learn about that. But before that, if you have not subscribed to Test Mu AI's YouTube channel, I strongly suggest that you do so. They have some great content [music] around technology, testing, and AI created by some great creators across the world. Let's get started with this video. So, we all know that these agentic solutions basically can take in user input, try to understand what is the ask there, and then think step-by-step to reason how to perform that, use the tools at hand, try to do certain things in an autonomous way, and all these to achieve the goal at the end, right? So, this is a typical agentic system that we know that we can build. And this may not be a single agent. This can be [music] a boss agent. There can be a boss agent who is actually allocating the task that it is thinking at the step one to multiple other agents. But when we talk about agentic solution, this entire thing is an agentic solution. Now, what if you want to use another agentic solution created by someone else, which you otherwise could have built in your organization, but this is not maybe this is not something that you want to do because you have you will have to rethink certain things that is already created by someone else, right? For example, let's let's take an example of a travel [music] agent out here. Let's say when I say travel travel agent, here is the agentic system, but imagine that you are trying to create a solution where user can come and say that hey, I want to book my itinerary for to go >> [music]>> somewhere else some place. Now, this travel agent who is taking user input would like to book flights, would like to book hotels, um would like to understand from the user to basically what that user likes and then try to figure out what are the things that the user can do on once that person reach there. >> [music] >> And these three itself are three different agents, right? And >> [music] >> can can do their independent task, which is asked by the travel travel agent that the user is interacting to. Now, you can build all these three agents yourself, but there in in a realistic organization scenario, for example, you can take any of our travel booking system that we have Cleartrip, MakeMyTrip, etc. And flight agent can be provided by the individual flights services like for example Air India or Indigo or anything else. Hotels can be coming from different hotels where they have created their own agents to basically select the best possible room for you based on your stuff. Uh similarly for excursion agent, there are planners who can plan based on where you are going. Now, what if you want to use these agents that are created by these third parties into your application which is a travel booking AI-based travel booking. Now, this is where A2A or agent to agent protocol kind of comes in, which sets an universal standard of communication between external agents into your ecosystem uh through authentication and communication, right? So, two-way communication that uh also happens through this. So, now [clears throat] let's see how this actually happens. What are the uh what are the steps? But, before that, I think typically you can think of this architecture in this way. So, user gives a goal to your client agent. In our previous use case, this is the travel agent. >> [music] >> And then the client agent request to the server uh to the agents which are probably deployed in external servers. Here you see one agent, but there can be multiple remote agent, right? And then all these uh remote agents which are actually deployed into other servers is actually talking to the client agent through some A2A uh conversations. So, how does this actually happen? So, it happens through certain stages. So, stage one is basically discovery. So, your client agent [music] has to first figure out that, hey, does this type of agent actually exist? And hence, the A2A protocol says that uh whenever you're building an agent, you create an agent card with it. And the agent card will typically have the identification of the agent, uh the capabilities or skills of this agent, for example, flight search or booking or certain things like that. It will also give you the endpoint that the client agent needs to uh use to communicate with uh with that remote agent. And typically the format with which this conversation between two agents is going to happen. And uh and most of the time, it is [music] the JSON uh format or the JSON metadata. Now, this agent card is actually a JSON format that uh you hit and try to [music] understand more about discovering this type of agent. Stage two, basically once the check has happened that okay, the client isn't now knows that okay, I have this agent at hand and I can use it. There is an authentication which will be also mentioned into the agent card that what type of authentication needs. And once the client agent gets authenticated, access is granted to that remote agent for communication, right? So, your client presents the credentials and the remote verifies the security scheme. Whatever scheme is mentioned into that agent card, it will follow that and grant access. In stage three, this is where the exchange between the client >> [music] >> and the remote agent will start and it happens through transport of HTTPS. It uses JSON-RPC 2.0 to basically communicate which is basically a well-known language for peer-to-peer communication. And then there will be responses that are coming from the remote agent which the client agent then use and do its own own set of engineering to provide the best response [music] for the users users goal. Now, sometimes this type of communication when the response comes from the remote agent is basically a very short task. It doesn't need any complexity. For example, just book this flight for me, right? And this flight is also available and that point of time you will see uh uh there's a quick request that goes from the client agent to the remote agent and the remote agent responds with uh whatever task artifact that it has created. For example, let's say uh it after booking it got a ticket in PDF format, it will probably give that PDF format ticket to the client. But there are certain cases which are long running tasks, right? From the client from the remote agent side. And this happens through SSE or server-sent events streams, right? So, there will be streaming of information that will be coming from the remote agent to the client [music] agent. For example, let's say the task is pretty complex that the client agent says that my user wants to go to Goa and my user likes to do these these these things, but not sure about how to plan the day. Now, this might be a long-running task to the remote agent, the excursion agent in our in our case might have to do a lot of research around that area uh around the weather of that uh particular area or on that day on on those days when the user is actually going. And then [music] it can stream uh multiple events back to the client agent while uh for this long-running task so that the client agent is not stuck. You can stream information and while the entire uh response of the task is coming from the remote agent, client agent actually can go ahead and utilize whatever information is uh it's getting uh dynamically. And at at the end of both of these, the short and the long uh running task, there will be artifacts presented to the client by the remote server agents. And this can be some tangible outputs as I was saying, it can be the flight ticket, it can be a uh full-fledged document of uh in our in in in case of our uh uh example that I was saying, it can be a entire document of uh the plan for the user when that user actually visits that place. There might be images, there might be some other structured data giving information about uh the entire uh goal, right? [music] Uh entire ask that the user had. So, the main advantage of why we will go ahead [music] and use A2A is because uh the third-party remote agents might have some proprietary way by which they have built this agents, whether it's a travel flight booking agent or a hotel booking agent. There might be some proprietary logic or engineering that is embedded. So, that [music] kind of becomes an abstraction. So, for external client agents, they just provide the input and then the logic is actually residing on that organization's agents perspective. So, there is a bit of privacy from the IP that with which these agents are built, right? And And again, it may It might be some proprietary tools also, not just not just the logic. For example, let's say >> [clears throat] >> Air India has some some APIs that they have developed in-house to book flights or look for flights or canceling the payments or rescheduling flights, etc. They don't have to expose those APIs or logic to an external travel agent. They can use They can just create this agent and that agent can be using >> [music] >> those type of functions that Air India has. The biggest benefit of A2A is basically that it is built at the top of some very very well-known tool stack, right? So, whether you talk about HTTPS as a transport protocol, the JSON format JSON RPC that I was talking about, or the type of calls that happen, whether it is remote procedure call or RPC or SSE that we looked at. So, it is It is As a result of which, it has capacity of getting integrated with most of the system that is existing in in the universe and have It has a very high chances of getting adopted very easily because these are all known stacks, right? And most of the time in organizations or enterprise applications, you'll see that these stacks are used. So, they have not deviated from it. So, while I talk about A2A and its benefits, it's also in a state that it is actually evolving right now, right? It is not in a state where in my opinion, though, that you can just go ahead and start using it. It's an evolving protocol unlike MCP. So, MCP also started the same way, but MCP got adopted very quickly. You had a very good support from the open source community, and A2A is also open source under Linux Foundation. So, you will see the community is coming up and building on the top of it a lot more new capabilities, secured capabilities. But, I think right now A2A is heavy on innovation. I think they have to spend a little bit more time on governance, right? So, there are a lot lot of property information that this entire system will be dealing with, right? And this is where I think the future work will be focused on because capability-wise, we know that the innovation works. But, the security, performance, and governance is something that what I understand that the road map of A2A is. But, having said that, it doesn't stop you actually from going ahead and start building your POC using A2A. You can always create an external-facing agent and try to see whether this communication actually works for your system or not. Um and [music] that is that is entire thing about A2A, but if I evaluate it properly, I think and in next 6 to 8 months, you will see a lot of these type of remote agents are getting Uh, it's coming as a provider for a lot of client systems, right? And and it is you will see a lot of these type of communication inter-agent communication is happening. [music] And you will might see a kind of a connected mesh, an ecosystem that is being built >> [music] >> using the agent to agent. So, I think we have seen AI as an isolation till now. We have seen organizations are actually using AI now for creation of value. We've seen organizations using agents to create value. And I think the future is going to be an agentic collaboration and A2A is going to play big role in this collaborative environment. Thank you so much for your time. I hope this gives you a good understanding or foundational understanding of agent to agent. It's enough for you to get started with some real project. Thank you so much.
Original Description
Agents are powerful on their own, but what happens when an agent built by another organization can plug straight into your system? That's exactly what the Agent-to-Agent (A2A) protocol makes possible.
Start Testing Free:
https://www.testmuai.com/register/utm_source=youtube&utm_medium=organic&utm_campaign=a2a_protocol
In this video we simply explain how A2A lets agents from completely different ecosystems talk to each other: how discovery works through agent cards, how authentication keeps it secure, and how the actual exchange happens over HTTPS, JSON-RPC, and server-sent events for longer, complex tasks. A simple travel-booking example, flights, hotels, and excursions, each run by a different third-party agent ties it all together.
You'll also get an honest take on where A2A stands today: strong on innovation, still maturing on governance, and likely to shape how agentic systems collaborate over the next year.
New to AI agents and the protocols connecting them? Start here.
⏱️ Timestamps
00:00 — Orchestrating your own agents (boss & worker setup)
00:45 — The big question: using agents built by others
01:30 — The travel agent example (flights, hotels, excursions)
03:00 — What is the A2A protocol?
04:00 — How A2A works: client agent & remote agents
04:45 — Stage 1: Discovery & the Agent Card
06:15 — Stage 2: Authentication
07:00 — Stage 3: The exchange (HTTPS & JSON-RPC)
07:45 — Short tasks vs. long-running tasks (SSE streaming)
09:00 — Artifacts: the tangible outputs
10:00 — Why use A2A? Abstraction, privacy & proprietary logic
11:30 — Built on proven stacks (easy adoption)
12:30 — A2A vs MCP & where the protocol stands today
14:00 — The future: agentic collaboration
🔔 Subscribe to TestMu AI for more on technology, testing, and AI.
More on: Agent Foundations
View skill →Related Reads
📰
📰
📰
📰
An ERD MCP Server: AI Agents That Follow Your Naming Standard
Dev.to AI
My AI Agent Reported Success for 9 Straight Days. Then a Customer Told Me It Had Been Failing All Along.
Dev.to AI
How to track Shopee price history and find the best deals
Dev.to AI
The Silent Costs of AI APIs Nobody Warns You About
Dev.to AI
Chapters (14)
Orchestrating your own agents (boss & worker setup)
0:45
The big question: using agents built by others
1:30
The travel agent example (flights, hotels, excursions)
3:00
What is the A2A protocol?
4:00
How A2A works: client agent & remote agents
4:45
Stage 1: Discovery & the Agent Card
6:15
Stage 2: Authentication
7:00
Stage 3: The exchange (HTTPS & JSON-RPC)
7:45
Short tasks vs. long-running tasks (SSE streaming)
9:00
Artifacts: the tangible outputs
10:00
Why use A2A? Abstraction, privacy & proprietary logic
11:30
Built on proven stacks (easy adoption)
12:30
A2A vs MCP & where the protocol stands today
14:00
The future: agentic collaboration
🎓
Tutor Explanation
DeepCamp AI