Wiki · Concept · Last reviewed July 10, 2026

A2A Task Lifecycle

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

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: July 10, 2026 Last reviewed: July 10, 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, a background job, or a promise that the agent acted correctly. It is the protocol object that makes delegated work inspectable across time.

A task lifecycle should therefore be read as evidence infrastructure. It records what the remote agent says about the work's status and outputs. It does not by itself prove that the work was authorized, safe, compliant, reversible, or faithfully aligned with the user's intent.

Current Context

As of the July 10, 2026 review, the official A2A documentation presents v1.0 as the stable production-ready line of the protocol. That matters because v1.0 tightened operation names, binding behavior, version negotiation, security guidance, and enum serialization.

Current A2A examples and schema material should be checked for version. Older v0.3-era material may use method names such as tasks/get or lower-case task states such as input-required. The v1.0 protocol surface uses operation names such as GetTask, ListTasks, CancelTask, and SubscribeToTask, and ProtoJSON enum values such as TASK_STATE_INPUT_REQUIRED. A wiki entry or implementation note that says "A2A task state" without naming the version is underspecified.

State Model

The A2A specification defines task status as a container with a required state, optional associated Message, and optional timestamp. A task object can also carry artifacts, interaction history, and metadata. In the v1.0 definitions, the TaskState enum includes TASK_STATE_UNSPECIFIED, TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, TASK_STATE_INPUT_REQUIRED, TASK_STATE_REJECTED, and TASK_STATE_AUTH_REQUIRED.

Completed, failed, canceled, and rejected are terminal outcomes. Input required and auth required are interrupted states. Submitted and working are active states. Unspecified covers unknown or indeterminate status and should be treated as a telemetry problem, not as a successful or failed result.

This distinction matters for human-agent interaction. A task in TASK_STATE_INPUT_REQUIRED is asking the client or user for more information. A task in TASK_STATE_AUTH_REQUIRED is blocked on authentication. A task in TASK_STATE_REJECTED means the agent has refused or declined to perform the task. Collapsing all three into a generic "error" destroys the reason the workflow stopped.

Context, History, 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 this pattern in practice: a completed task is referenced by a later message, and the agent creates a new task in the same contextId for the refinement. That 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.

Artifact mutation is deliberately not fully solved by the protocol. The Life of a Task guidance says the client is in the best position to track artifact versions and decide which result is acceptable. A governed client should therefore preserve artifact IDs, predecessor references, accepted version, rejected versions, and the user or policy decision that made one artifact authoritative.

Operations and Observation

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. These operations appear across the protocol's A2A protocol bindings, including JSON-RPC, gRPC, and HTTP+JSON/REST.

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, webhook callback, broken stream, or reconnection.

Observation should be separate from authority. A status update that says a task is completed is a claim about protocol state. It should not automatically approve an irreversible external action, release sensitive data, close a human review queue, or override a local authorization policy.

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 and signature status if used, protocol version, protocol binding, tenant routing value if used, 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, listing, cancellation, streaming subscription, and push-notification configuration. 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.

High-impact deployments should also connect task lifecycle records to ordinary AI governance and security programs. NIST's AI RMF frames governance, mapping, measurement, and management as lifecycle activities, while the NCCoE agent identity project focuses on identifying, managing, and authorizing actions taken by software and AI agents. In that setting, A2A task state is one evidence stream among many: identity, consent, delegated scope, logs, policy checks, incident records, and human review decisions still need to be preserved.

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.

Cross-agent laundering. A receiving agent treats a prior agent's completed task as proof of user approval, instead of checking the original authority, delegated scope, and artifact provenance.

Cascading retries. A client or intermediary retries a submitted or working task without idempotency discipline, creating duplicated messages, repeated side effects, or conflicting artifacts.

Source Discipline

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

Claims about broader governance should not be sourced only to protocol documentation. Use NIST or comparable risk-management sources for lifecycle governance, identity, authorization, and incident-response claims; use security taxonomies such as OWASP's agentic guidance for cross-agent communication, identity abuse, cascading failure, and tool-misuse risk. Partner lists, SDK examples, and vendor demos are adoption signals, not evidence that a task lifecycle is safe in production.

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