Google’s A2A Protocol

READ THIS FIRST:

The structure of A2A has changed after this post was written. The commit below (20th May 2025) rationalised the types of A2ARequests.

https://github.com/a2aproject/A2A/commit/50a6d6d916a604926d079545119eda6f50289efb

While the overall post remains valid including the key insights around A2A being a cardboard box that you get the products you buy from say Amazon (and not the product itself). I have attempted to update key parts of this post to reflect the current state.

Now the post…

Google has release the A2A protocol which aims to provide a standard way for Agents to communicate with each other as well as provide a host of other services such as Enterprise-grade authentication.

Don’t fall for the hype that promotes A2A as the solution to all Agentic AI gaps. It is a very specific component within a larger ecosystem that includes Model Context Protocol, frameworks, and implementations.

The JSON Schema for the A2A Protocol can be found here: https://github.com/google/A2A/blob/main/specification/json/a2a.json

Helpful object constructors provided by Google here:

https://github.com/google/A2A/blob/main/samples/python/common/types.py

The most important aspect of any protocol are the interactions that it consists of. These interactions are defined by data objects that are exchanged in a given sequence. There are about 50 objects that make up A2A.

I have created a small utility that uses Gemini Flash 1.5 to process the schema objects in the JSON schema file above and creates examples to make it easier to implement. Where a particular object contains references it also pulls out there referred schema and includes it for the LLM. Link at the end of the post.

You can read the ‘Story’ section if you just want a high level view.

The Story

The story is quite simple. We have Agents working with each other to carry out Tasks.

Tasks are the Clients way of describing the work and expected outcomes. Messages are the ‘control plane’ of the A2A which helps ensure the correct processing is carried out and required output is achieved. These tasks are contained in an A2A Request.

Artifacts are the rich response objects generated by Agents as they carry out the Task. Parts are used in both Artifacts and Messages to exchange data – this could be data generated as part of Task completion or data that describes the Task (e.g., expected output format, instructions).

Clients create one or more Tasks as part of a particular session. Agents are responsible for managing the status of the Task. Agent has a level of autonomy in carrying out the task (e.g., straight away, schedule, refuse). There are a set of Error objects that help inform of issues during Task completion.

Agents can communicate with Clients outside a particular session using Push Notifications.

Agents and their skills can be discovered using Agent Cards.

The A2A Request

Currently, when we want to communicate with an Agent we define a custom protocol which largely consists of a lot of text flying back and forth between the user, LLM, and tools. The A2A Request object acts as a universal container being able to encapsulate different types of requests, leaving the handling to specific agents. Think of it like our network protocols that can transport any type of media (e.g., video, text, and audio) while leaving the handling to specific apps (e.g., Netflix, Chrome, and Spotify).

This is one of the core parts of the protocol. It allows Tasks to be initiated and managed as well as Push Notifications to be set and managed.

The image above shows the type of A2A requests. The Task Request has been rationalised using the Send Message Request/Send Streaming Message Request. This means Tasks are not separate constructs. They are part of message exchange. This makes sense because Agents are all about interactions that contain requests, questions, responses, answers, artefacts. Requests could be for specific resources (e.g., knowledge search) or for to carry out a task (e.g., create user account).

~~It can take the following payloads: SendTaskRequest, GetTaskRequest, CancelTaskRequest, SetTaskPushNotificationRequest, GetTaskPushNotificationRequest, and TaskResubscriptionRequest.~~

~~Below is an example of the ‘SendTaskRequest’ payload within an A2A Request.~~

An example of the A2ARequest container with SendTaskRequest payload.

The Agent Card

This object describes an agent. Below we can see the high level pieces of information associated with an agent: the name, description, provider, url, version, documentation, supported interaction capabilities (e.g., streaming), authentication, and the input and output modes (e.g., text).

The next part of the Agent Card describes the skills associated with the agent using a list of objects of type Agent Skill. This is important because skills allow us to select the correct agent. A skill consists of a name, description for the skill, a set of tags, examples, and input and output modes. For example, we can have a skill that generates a summary of a document. In this case input and output mode would be ‘text’ and a tag could be ‘document summary’.

An example of the skills section of the Agent Card.

The skills block is formed of an array of Agent Skill objects. An example given below:

Example Agent Skill object which describes skills for an Agent Card.

Error Objects

There are a large number of Error objects that help communicate issues with agent to agent interactions (requests/responses). Some common issues include: invalid parameters, invalid request payload, and issues with JSON parsing.

Message

Helps implement the control plane for the Task. Can be used to transmit agent thoughts, instructions, status, errors, context and other such data. As per the Google documentation – anything that is not generated by an Agent. It uses Parts to contain the actual data (see Artifact). The example below shows a message with Text Part, File Part (URI-based), and a Data Part.

Artifact

Artifacts represent the items being created by agents based on a request and they are immutable. Thus these are part of the response (once created cannot be changed). This could be a file (e.g., a document), piece of text (e.g., search result), or some data (e.g., user input). It is a critical part of the protocol because without this richness of response there will limited utility in agents communicating with each other.

The main thing to focus on is the type Parts array which consists of objects of type TextPart, FilePart, or DataPart. Each part is a fully formed chunk of content. Parts can exist in both requests (Message) and responses (Artifact).

Example of an Artifact object which represents items to be processed by the agent (e.g., file, text, data).

TextPart

TextPart represents free text input as Part of a Request to an agent for example a question to the LLM such as ‘what is nuclear fission?’. The agent would then Respond with an Artefact with a TextPart that contains a response to that request – a description of Nuclear Fusion.

FilePart

FilePart represents a file either as a URI (location) or base64 encoded byte data (never both). So fetch the data or here is the data. This uses the FileContent object to actually store the content. This is useful when an agent needs to processes files (e.g., stored at a location like a Cloud bucket) or communicate using files.

DataPart

This is the most interesting ‘Part’ in my view. This represents data being passed back and forth. For example, this could represent a conversational agent gathering details about a customer booking and sharing them with an agent that has a ‘Hotel Booking Management’ skill.

Task

Perhaps the most important object as this is the reason for the existence of the A2A framework. The ability to describe and complete Tasks. Each Task may be associated with a session in case multiple Tasks are running in parallel. The key function of the Task object is to represent a snapshot of the interaction as well as the overall status (given by the Task Status object).

The interaction snapshot can contain a historic record of messages, artifacts, and metadata. This makes a Task object a stateful object – which means when messing around with it we must be very careful to use idempotent operations.

A whole set of requests are available to create and manage Tasks and notifications.