Wiki · Concept · Last reviewed June 25, 2026

A2A Task Lifecycle

The A2A task lifecycle is the state machine that lets an Agent2Agent client track stateful, long-running work across messages, status updates, artifacts, interruptions, and terminal outcomes.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: A2A, AI Agents, Task State, Audit Trails, Interoperability, Governance

Definition

The A2A task lifecycle is the stateful work model inside Agent2Agent Protocol. A remote agent may answer a client message with a stateless Message for immediate interaction, or it may initiate a Task when the work requires tracking, progress updates, additional input, artifacts, or longer-running execution.

The official A2A core concepts page defines a task as a stateful unit of work with a unique ID and defined lifecycle. That is the key boundary: a task is not merely a chat turn. It is the protocol object that makes agent work inspectable across time.

State Model

The A2A specification defines task status as a container with a required state, optional associated Message, and optional timestamp. The current task-state enum includes unspecified, submitted, working, completed, failed, canceled, input required, rejected, and auth required states; the unspecified state covers unknown or indeterminate status. Completed, failed, canceled, and rejected are terminal states. Input required and auth required are interrupted states.

This distinction matters for human-agent interaction. A task in TASK_STATE_INPUT_REQUIRED is not failed; it is asking the client or user for more information. A task in TASK_STATE_AUTH_REQUIRED is not complete; it is blocked on authentication. A task in TASK_STATE_REJECTED means the agent has decided not to perform the task, either during creation or after determining it cannot or will not proceed.

Context and Immutability

A2A uses contextId to group related tasks and messages across an interaction. A first message can create a new context, and later messages can reuse that context to continue the same broader workflow. Follow-up or refinement work should start a new task in the same context rather than restart a terminal task.

The official Life of a Task page is explicit about immutability: once a task reaches completed, canceled, rejected, or failed, it cannot restart. This makes each task a clearer unit of work. It also gives audit systems a cleaner chain: the original request, the task that handled it, the artifacts produced, and any later refinement task that depends on it.

Operations

A2A task operations include sending a message that may create or update a task, sending a streaming message, retrieving a task with GetTask, listing tasks with optional filtering and pagination, canceling a task, and subscribing to a task stream. The specification says SubscribeToTask returns the current task first, then status and artifact update events, and it cannot be used on terminal tasks.

Streaming and push notifications are two ways to observe state changes. Streaming uses an open Server-Sent Events connection for real-time status and artifact updates. A2A Push Notifications use a webhook for disconnected or very long-running tasks. Polling with GetTask remains the conservative fallback when a client needs the current state after an event or reconnection.

Governance Requirements

A governed A2A task record should preserve the task ID, context ID, referenced prior tasks, originating message ID, user or agent principal, selected remote agent, Agent Card version, protocol binding, task status timeline, status messages, artifacts, cancellation request, authorization interruption, input request, final terminal state, and follow-up task IDs.

Access control must cover task retrieval and listing. The A2A specification's security section says implementations must scope results to the authenticated caller's authorization boundaries and must check authorization before operations that could reveal resources outside that boundary. That makes ListTasks a sensitive operation, not just a dashboard convenience.

Failure Modes

State collapse. A client treats input required, auth required, failed, rejected, and canceled as the same generic "error," losing the reason the agent stopped.

Terminal restart. A workflow mutates a completed task instead of creating a new task in the same context, damaging traceability.

History leakage. GetTask or ListTasks exposes messages, artifacts, or task existence beyond the caller's authorization boundary.

Artifact confusion. A later refinement task updates an artifact, but the client keeps using an older version because artifact linkage is not tracked locally.

Cancellation theater. A user sees a cancel control, but the downstream task keeps running or has already triggered an external side effect.

Source Discipline

Claims about states, operations, terminal behavior, authorization scoping, and streaming should cite the official A2A specification. Claims about context IDs, task refinements, task immutability, parallel follow-ups, and artifact mutation should cite the Life of a Task page. Claims about polling, streaming, and webhook update patterns should cite the streaming and asynchronous operations page.

Spiralist Reading

The A2A task is a ledger line for delegated machine work.

It says: a request became a unit of work, the unit entered a state, the state changed, artifacts appeared, the agent asked for input or authentication, and the work either ended or spawned a follow-up. Spiralism cares about that mundane structure because without it, agent collaboration becomes a fog of helpful activity with no accountable shape.

Open Questions

Sources

Return to Wiki