Recognize the A2A interaction lifecycle

Learning objective

Recognize Agent2Agent (A2A) Agent Cards, task states, status updates, and artifacts as distinct stages and objects in a remote-agent interaction. This lesson focuses on reading the lifecycle, not on choosing between A2A and Model Context Protocol or designing a multiagent workflow.

Core idea

Read an A2A interaction as discover, delegate, observe, and collect:

1. Discover: An Agent Card describes how to contact the remote agent and what it advertises.
2. Delegate: A client sends a message. The agent can return a direct Message or create a stateful Task.
3. Observe: The client follows the task’s state and status updates. It supplies input or authentication when the task is interrupted.
4. Collect: Artifacts carry the task’s generated outputs.

Each object answers a different question. The Agent Card answers Can and how should I interact with this agent? The task state answers Where is this unit of work now? A status update answers What changed? An artifact answers What did the work produce?

How it works

Discover the remote agent

An Agent Card is a JSON metadata document that an A2A server publishes. The current A2A specification defines fields for the agent’s identity, supported interfaces, version, capabilities, security requirements, input and output media types, and skills. Clients can obtain a card from the well-known URI, a registry, or direct configuration.

Use the card to select a compatible interface and decide whether optional features such as streaming or push notifications are available. A card is a discovery contract, not a live task record. It also does not grant access or prove that a particular request is authorized or will succeed.

Create and track a task

The client delegates work by sending a Message. For a simple, self-contained exchange, the server can return another Message; no task lifecycle follows. For trackable work, the server returns a Task with a server-generated task ID, current status, and optional history and artifacts. The official Life of a Task guide explains this message-or-task branch.

The task’s status contains a required state plus an optional explanatory message and timestamp. The task-state model groups the states by their effect on the caller:

Interrupted does not mean failed. For example, an agent can request a missing delivery date with TASK_STATE_INPUT_REQUIRED, then continue after the client responds. TASK_STATE_AUTH_REQUIRED is only a signal that more authentication is needed. The state transition itself is not authorization for an operation, as the specification’s in-task authorization guidance makes explicit.

A terminal task does not restart. A refinement or follow-up creates a new task, usually in the same context, so the original input, state, and outputs remain a clear unit of work.

Read the lifecycle as a loop that returns to working after each interruption and exits once at a terminal state.

Separate updates from outputs

A TaskStatusUpdateEvent reports a new TaskStatus for a task. An optional status message can explain progress or request input. A TaskArtifactUpdateEvent reports an artifact that was generated or updated. Artifact updates can append content to an artifact with the same ID and mark the last chunk. See the specification’s definitions of streaming events.

This separation matters: status communicates control state; artifacts carry results. An artifact has its own ID and one or more content parts, such as text, a file reference, or structured data. A completed state says that work finished successfully; the associated artifacts contain the task outputs. A direct Message response is the exception because it completes without a tracked task or task artifacts.

Clients can observe tasks by retrieving the latest task, receiving a stream of status and artifact events, or accepting push notifications when the Agent Card declares the required capability. Streaming gives low-latency progress but requires a live connection. Polling is simpler but adds delay and repeated requests. Push notifications suit disconnected or very long-running clients, but require a secured callback and duplicate-safe processing.

Key distinctions and trade-offs

• Agent Card versus task: The card describes the server; a task records one unit of delegated work.
• State versus status: State is the lifecycle enum. Status wraps that state with an optional message and timestamp.
• Status update versus task snapshot: An update reports a change. GetTask returns the latest task state, artifacts, and optional history.
• Message versus artifact: A message is a communication turn. An artifact is an output of a task. Do not hide a required deliverable in progress text.
• Failed versus rejected: Failed means the task ended with an error. Rejected means the agent decided not to perform it.

Architecture / decision scenario

A procurement coordinator delegates a quote request to a supplier agent. It first reads the supplier’s Agent Card and confirms a matching quote skill, compatible output media type, security requirements, and push-notification support. Because the coordinator runs as a short-lived serverless process, it chooses authenticated push notifications instead of holding a stream open.

The supplier returns a task in TASK_STATE_SUBMITTED, then reports TASK_STATE_WORKING. It later sends TASK_STATE_INPUT_REQUIRED with a message asking for the delivery window. The coordinator supplies that input on the same nonterminal task. The supplier emits an artifact update containing a structured quote and finally reports TASK_STATE_COMPLETED.

The coordinator processes duplicate notifications safely, validates the task ID, retrieves the latest task, and reads the quote from the artifact. If the supplier reports TASK_STATE_REJECTED, the coordinator chooses another agent. If it reports TASK_STATE_FAILED, the coordinator applies its retry or escalation policy. A revised quote becomes a new task in the same context, not a restart of the completed task.

Common exam traps

• Treating an Agent Card as a task instance, runtime health check, or access grant.
• Assuming every A2A message creates a task; a server can return a direct Message.
• Classifying INPUT_REQUIRED or AUTH_REQUIRED as terminal failure.
• Treating AUTH_REQUIRED itself as proof of authorization.
• Reading a progress message as the task’s output instead of inspecting its artifacts.
• Sending a refinement to a terminal task instead of creating a new task.
• Choosing streaming or push notifications without checking the Agent Card’s advertised capabilities.

What to remember

• Use the Agent Card to discover compatibility, not to track work or grant access.
• A direct Message has no task lifecycle; a Task is stateful and trackable.
• Distinguish active, interrupted, terminal, and indeterminate task states.
• Use status updates to follow control state and artifacts to obtain task outputs.
• Start a new task for follow-up work after a task reaches a terminal state.

Knowledge check

References

• A2A Protocol, Agent2Agent Protocol specification
• A2A Protocol, Life of a Task
• A2A Protocol, Core concepts and components
• A2A Protocol, Streaming and asynchronous operations
• A2A Protocol repository, Normative protocol schema