A2A Artifact: Task Outputs and Streaming Chunks
An Artifact is a tangible output that an agent generates while working on a Task : a document, an image, a block of structured data. It is the actual deliverable of the task, as opposed to the conversation around it. Like a message, an artifact is made of Parts .
Fields
| Field | Required | Description |
|---|---|---|
artifactId | Yes | Unique identifier for the artifact. It must be unique within the task |
parts | Yes | The content, as a list of Parts . It must contain at least one part |
name | No | A human-readable name |
description | No | A human-readable description |
metadata | No | Extra key-value metadata |
extensions | No | URIs of extensions present in or contributed to this artifact |
Artifacts live in the artifacts list of a Task. ListTasks leaves them out of the response unless the request sets includeArtifacts to true, to keep payloads small.
Artifacts, not messages, carry results
The core interaction in A2A is that a client sends messages to start a task, and the task produces one or more artifacts. The specification says messages SHOULD NOT be used to deliver task outputs, and that results SHOULD be returned as artifacts. See Message for what messages are for.
This is a completed task that carries one text artifact, from the specification’s basic scenario:
{
"id": "task-uuid",
"contextId": "context-uuid",
"status": {"state": "TASK_STATE_COMPLETED"},
"artifacts": [{
"artifactId": "artifact-uuid",
"name": "Weather Report",
"parts": [{"text": "Today will be sunny with a high of 75°F"}]
}]
}The same shape carries files. In the file exchange scenario the agent returns an image as an artifact whose part points to the content by url, and the Part
page shows that full response.
Streaming artifacts in chunks
A long result does not have to wait for the task to finish. With streaming, the agent sends a TaskArtifactUpdateEvent, delivered as an artifactUpdate, whenever a new artifact or a new piece of one is available. The event has these fields:
| Field | Description |
|---|---|
taskId, contextId | The task the artifact belongs to, and its context |
artifact | The artifact that was generated or updated |
append | If true, append this content to a previously sent artifact with the same ID |
lastChunk | If true, this is the final chunk of the artifact |
metadata | Optional metadata about the update |
The specification’s streaming example shows an artifact update between the working and completed states. It is abbreviated: a real artifact also carries its required artifactId.
HTTP/1.1 200 OK
Content-Type: text/event-stream
data: {"task": {"id": "task-uuid", "contextId": "context-uuid", "status": {"state": "TASK_STATE_WORKING"}}}
data: {"artifactUpdate": {"taskId": "task-uuid", "contextId": "context-uuid", "artifact": {"parts": [{"text": "# Climate Change Report\n\n"}]}}}
data: {"statusUpdate": {"taskId": "task-uuid", "contextId": "context-uuid", "status": {"state": "TASK_STATE_COMPLETED"}}}Streaming requires capabilities.streaming: true in the Agent Card. The event stream for a task begins with the Task and closes when the task reaches a terminal state. See Streaming and Asynchronous Operations
.
Refining an artifact
A task that reached a terminal state cannot be reopened, so a refinement is a new task in the same contextId, and its output is a new artifact. In the Life of a Task
example, the agent first generates a sailboat image. The artifact from the first task:
{
"artifactId": "artifact-boat-v1-xyz",
"name": "sailboat_image.png",
"description": "A generated image of a sailboat on the ocean.",
"parts": [
{
"filename": "sailboat_image.png",
"mediaType": "image/png",
"raw": "base64_encoded_png_data_of_a_sailboat"
}
]
}After the client asks for a red boat, the new task produces an artifact with the same name and a new artifactId:
{
"artifactId": "artifact-boat-v2-red-pqr",
"name": "sailboat_image.png",
"description": "A generated image of a red sailboat on the ocean.",
"parts": [
{
"filename": "sailboat_image.png",
"mediaType": "image/png",
"raw": "base64_encoded_png_data_of_a_RED_sailboat"
}
]
}Tracking which artifact replaces which is a client concern and is not part of the A2A specification. The guidance is for serving agents to reuse a consistent artifact name for a refined version, and for clients to keep their own version history and name the exact artifact they want refined, ideally the latest one from their point of view.
Related pages
- Task : where artifacts are stored and how tasks end.
- Part : what an artifact contains.
- Task Runtime Guide : how artifacts arrive on the event stream, how to check the event order, and how to recover from a dropped stream.
- Data Structures : the complete field reference.
Source: A2A official specification: Artifact, Streaming Events, and Common Workflows and Life of a Task