A2A Task

What is an A2A Task?

An A2A Task is the Agent2Agent Protocol’s stateful unit of work. It has a server-generated unique identifier and progresses through a defined lifecycle. A Task can track status, conversation history, and generated [A2A artifacts](/glossary/a2a-artifact/) for work that needs more than a direct message response.

Not every A2A interaction requires a Task. For a simple exchange, a remote agent may return an [A2A message](/glossary/a2a-message/) directly without task tracking.

How it works

A client sends a message to an A2A server. The server may create a Task and return its current state immediately while processing continues. The client can then receive updates through supported mechanisms such as polling, streaming, or push notifications.

Task states let participants understand whether work is active, completed, failed, canceled, rejected, waiting for input, or waiting for authorization. The exact protocol representation matters because clients use it to decide what interaction is valid next.

For multi-turn work, later messages can reference the task identifier. A context identifier can also group related tasks and messages across a broader interaction.

Simple example

A procurement agent asks a supplier agent to prepare three quotes. The supplier agent creates a Task because the work takes time. It publishes progress, requests missing delivery details, and eventually attaches a structured quote comparison as an artifact.

The client does not need access to the supplier agent’s internal plan. It tracks the standardized task boundary and outputs.

A2A Task versus generic agent task

A generic agent task is any piece of work in a plan or workflow. An A2A Task is a protocol object with defined identity, lifecycle, and interaction semantics between A2A participants.

An agent may complete many internal subtasks while processing one A2A Task. Conversely, a multi-step conversation can involve multiple A2A Tasks linked by a shared context.

Why it matters

Tasks allow independently built agents to coordinate stateful and long-running work without exposing internal memory or reasoning. They give clients a stable object to monitor, continue, cancel when supported, and associate with results.

Systems still need retention, authorization, idempotent update handling, and failure policies around that protocol object. See [Single-Agent vs Multi-Agent Systems](/single-agent-vs-multi-agent-systems/) for the architectural context.