A2A Message

What is an A2A Message?

An A2A Message is a communication turn exchanged between an A2A client and a remote agent. In the [Agent2Agent Protocol](/glossary/agent2agent-protocol/), a message has a role—user or agent—and contains one or more parts.

Parts carry the actual content. Depending on the supported modes, they can represent text, files, or structured data. A message can also participate in a continuing interaction by referencing a task or context.

How it works

The client initiates an interaction by sending a message. The remote agent can return a direct message for a simple response or create an [A2A Task](/glossary/a2a-task/) when the work needs stateful processing and updates.

Messages may also continue an existing task. For example, if a task enters an input-required state, the client can send another message associated with that task to provide the missing information.

The message is the communication object at the protocol boundary. What each agent does internally—prompt construction, tool use, memory retrieval, or planning—is outside the A2A message definition.

Simple example

A client sends a message with the user role containing a text part: “Compare these supplier proposals,” plus file parts for the documents. The remote agent creates a task. Later, it sends an agent-role message asking which currency to use. The client answers with another user-role message tied to the same task.

A2A Message versus LLM prompt

A [prompt](/glossary/prompt/) is input presented to a language model. An A2A Message is a protocol-level communication turn between agent systems.

A receiving agent may transform a message into one or more model prompts, combine it with internal instructions, or handle it without an LLM. The A2A role is not automatically the same as a model API role, and protocol metadata should not be confused with model context.

Why it matters

A common message structure helps heterogeneous agents exchange text, files, and structured data without exposing their internal implementation. It also supports clear continuation of task-oriented conversations.

Builders must still validate content types, authorize task access, limit untrusted inputs, and preserve the distinction between external messages and trusted internal instructions.