A2A Messages, Tasks, and Artifacts

Version note — reviewed 2026-09-29. The official A2A specification site still labels v1.0.0 as the latest released specification. The A2A repository also publishes a v1.0.1 patch release with specification bug fixes. This Lesson remains pinned to the published v1.0.0 specification and treats the patch release as compatibility/release-note evidence.

Goal

Track A2A v1.0.0 messages, task identity/status, and artifacts as different protocol objects with clear lifecycle and validation rules.

Imagine a group project. You send a teammate a note saying, "Please make the chart for our science report." That note is communication. The assignment itself has a separate identity: who owns it, whether it is still being worked on, and whether it was cancelled or finished. When the teammate finally uploads chart.png, the file is the produced result.

Separate message, task, and artifact

A2A keeps those three ideas separate. A message is what participants say to one another. A task is the identifiable piece of work and its changing status. An artifact is an output produced by that work. If you mix them together, a file arriving can be mistaken for proof that the whole job is finished, or a later status update can become detached from the job it belongs to.

A message carries communication between participants. It can contain parts representing text, files, or structured data. A message may start work or continue an existing interaction, but the message itself is not the durable lifecycle of the work.

A task represents work with identity and status. The v1.0.0 specification defines task operations such as sending messages, getting tasks, listing tasks, cancelling, subscribing to updates, and asynchronous delivery mechanisms. Your harness should store remote task identifiers so later updates attach to the correct work.

Track task lifecycle

An artifact represents output produced during a task. A research agent might return a report file or structured result as an artifact while status updates describe progress. The parent should validate artifact type, source task, and expected schema before using it.

Context identity and task identity serve different scopes in multi-turn interaction. A context can connect related exchanges, while a task identifies a particular unit of work. The local harness should not guess identifiers from text when the protocol provides explicit fields.

A harness might keep a simplified local tracking record like this; it is not the A2A wire object:

{"task_id":"task-17","status":"working","message_id":"msg-4","artifact_id":"report-2"}

Asynchronous work changes error handling. A send operation may create a task that finishes later. The client needs a deliberate update mechanism such as streaming, polling through task retrieval, or push notification support where appropriate. The exact choice depends on capability and deployment policy.

Handle asynchronous updates

Cancellation is a request about task lifecycle, not a guarantee that every external effect can be undone. A remote agent may already have produced an artifact or performed an irreversible action. The parent should record the cancellation request and then inspect the resulting task state.

Artifacts and messages are remote data. Even if their envelopes are valid, their contents may be wrong, unsafe, or outside the expected task. Validate scope, schema, provenance, and policy before they influence further actions.

Validate remote content

By separating communication, work state, and outputs, the harness can answer three different questions: what was said, what work is currently happening, and what result was produced.

Predict

A remote agent returns a PDF while the task is still marked working. What should the parent infer?

An artifact exists, but task status must still be interpreted independently rather than assuming completionThe task is automatically complete because any artifact ends the lifecycleThe PDF should be ignored because artifacts are allowed only after completion

Run the local Lab

Run:

python3 labs/notebooks/level-13/l13-08-a2a-objects.py

The Lab validates that messages, task-status updates, and artifacts all keep the same task identity.

1. Run it unchanged and confirm every event is marked ok for task-7.
2. Find the artifact event with "task_id": "task-7". Before editing, predict whether a protocol-shaped artifact with a different task ID should be accepted.
3. Change only that artifact's task ID to "task-8", then rerun.
4. Confirm the artifact line becomes FAIL, the provenance check rejects the sequence, and the script exits non-zero. Restore the starter afterward.

Loading lab…

Quick Check

1. What is the main role of a Task object?

Store the remote agent's private chain of thoughtReplace every message and artifact with one text fieldRepresent identifiable work and its lifecycle

2. How should an artifact be accepted?

If the producing agent was discovered successfullyCheck task association, schema, and provenance before useBy checking that its filename looks correct

3. What does cancellation mean for external effects?

Completed effects may still need reconciliation after cancellationCancellation reverses completed external effectsCancellation deletes the task history

0 of 3 questions answered.

Explain it back

Give an example where one message starts a task, two status updates follow, and one artifact is produced. Explain how the parent stores identifiers and decides when the result is usable.

Key Takeaways

• Messages, tasks, and artifacts serve different roles.
• Task identifiers support asynchronous lifecycle tracking.
• Artifacts require provenance and schema checks.
• Cancellation does not guarantee reversal of completed effects.
• Protocol-visible identity is safer than guessing linkage from text.

Next Lesson

Next, L13.9 — Multi-Agent Coordination Patterns moves from one remote task to systems where several agents work on related goals.

References

• Agent2Agent Protocol, v1.0.0 Specification.
• Agent2Agent Protocol, official release notes.