The Agent-to-Agent (A2A) Protocol

1. The Agent-to-Agent (A2A) Protocol

MCP isn't the only framework on the block for supporting agent interoperability.

2. Agent-to-Agent (A2A)

Google developed the Agent-to-Agent, or A2A, framework to make it easier for agents to collaborate with one another, even if they were created by different vendors or built using a different tool stack. Let's examine the need for A2A with an example.

3. Example: Corporate travel

Our organization wants to roll out an agent for booking corporate travel. Employees will chat with this agent to provide the desired location, their pickup location, and the times to set off and arrive.

4. Example: Corporate travel

This agent will retrieve the organization's travel policy documents and communicate this along with the user information to several different agents:

5. Example: Corporate travel

one for checking and booking air travel,

6. Example: Corporate travel

another for booking accommodation,

7. Example: Corporate travel

one for booking airport pickups,

8. Example: Corporate travel

and a final one for submitting reimbursements. There's a lot of agents involved here, and each will likely require inputs and authentication in a unique and specific way. That's a lot of coding, and will require significant updates and changes if we wish to change providers for any of these tasks, or if the provider changes their agents. Let's see how A2A can enable this use case more robustly.

9. Agent-to-Agent (A2A)

A2A facilitates communication between a client agent and a remote agent. A client agent is responsible for

10. Agent-to-Agent (A2A)

formulating and communicating tasks, while the remote agent is responsible for

11. Agent-to-Agent (A2A)

acting on those tasks in an attempt to provide the correct information or take the correct action. In our corporate travel example, the user interacts with the client agent - the company's corporate travel agent. This client agent then formulates the tasks required to achieve the end-goal and communicates the tasks with several remote agents.

12. Agent cards

A2A allows agents to discover each other through an Agent Card. This is similar to how an MCP server shares a list of available tools and their descriptions. Agent cards include the name of the agent, a description of the kind of tasks it can complete, and a list of different features it supports, such as streaming in real-time. This transparency means agents "understand" when and why they would call the other agents.

13. A2A components

Speaking of calling another agent, this is also done in a standardized way using an Agent Executor. The Agent Executor passes the context of the user chat to the remote agent, so it can understand the task to be completed. As the length of time the tasks take to complete can vary,

14. A2A components

there is also an Event Queue for handling updates and passing messages between the client agent and remote agents. This is important in production systems because we don't want the connection between our agent to be closed before it completes its task. Once the remote agent has completed the requested task,

15. Creating artifacts

it becomes an artifact. An artifact contains the result of the agent's work, a description of what was completed and the text context is sent through the protocol. This then closes the connection with the remote agent until it is needed again.

16. MCP and A2A

Although MCP and A2A are both interoperability frameworks, they are complementary rather than being in competition. MCP can be used to integrate tools and context from data into agents, and A2A can be used to help these agents communicate.

17. Let's practice!

Now let's apply your new-found knowledge in the exercises!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.