Researched guidance: How should an A2A client distinguish a message response from a durable task?

Summary

An A2A client distinguishes a direct response from durable work by the response oneof: a SendMessageResponse with message is a stateless direct Message; one with task is a stateful Task. For streaming, inspect each StreamResponse oneof and follow the Task lifecycle only when task/status_update/artifact_update records are present.

Candidate action

Parse SendMessageResponse and StreamResponse as explicit tagged unions, never infer durability from HTTP 200, latency, or a task status string alone. If message is present, deliver it as the direct response and do not poll, subscribe, or configure task push notifications. If task is present, persist task.id and context_id, inspect status.state, and use GetTask, SubscribeToTask, or push notifications according to the advertised Agent Card capabilities; continue an input-required or auth-required task with the same taskId/contextId and start a new task for follow-up after a terminal state.

Applicability

• A2A SendMessage responses in the current specification and official protocol definitions.
• A2A SendStreamingMessage and SubscribeToTask streams where each item has a tagged payload.
• Clients interoperating across protocol versions must select the AgentInterface protocol version and parse the representation appropriate to that version.

Procedure

• Select a supported AgentInterface from the Agent Card and send the declared A2A-Version; do not use patch versions for compatibility decisions.
• For unary SendMessage, require exactly one response payload: task or message. Treat message as a completed, stateless interaction with no task tracking; treat task as durable work and persist its server-generated id plus contextId.
• For streams, classify each item by its oneof payload: initial task or message, then task status-update or artifact-update events. A message-only stream contains one message and closes; a task stream begins with a task and ends when the task reaches a terminal state.
• For a Task, branch on status.state: terminal states are completed, failed, canceled, and rejected; interrupted states are input-required and auth-required. Poll with GetTask, subscribe when streaming is advertised, or use push notifications when configured.
• For input-required, send a follow-up with the same taskId and contextId. For auth-required, resolve authorization through the supported flow and keep monitoring. Do not send messages to a terminal task; create a new task in the same context for later refinements.
• Use the Agent Card to check streaming and push-notification capability before selecting SubscribeToTask or webhook delivery; otherwise use GetTask polling.

Key findings

• SendMessage returns exactly one of Task or Message; the client-side discriminator is which union payload is present. (S1, S3)
• A Task has a server-generated taskId, status state, and lifecycle; terminal tasks cannot be restarted, while input-required/auth-required states require follow-up handling. (S1, S2, S3)
• A message-only stream contains one Message and closes; a task stream begins with Task and may emit status/artifact updates until terminal completion. (S1, S3)
• Clients should inspect Agent Card capabilities before streaming or push notifications, and use GetTask polling where those capabilities are unavailable. (S1)

Known limitations

• An HTTP success status is not the discriminator: the application payload must be parsed as the protocol union.
• A direct Message has no task updates; messages should not be used to deliver task outputs, which should be represented as Task artifacts.
• Streaming can lose updates across disconnect/reconnect, so clients should not treat an open stream as reliable delivery for critical information.
• The official life-of-task guide explains the semantic distinction but explicitly does not specify a wire-level discriminator or complete streaming rules; the normative specification and official a2a.proto provide those details.
• Protocol representation differs across versions; the current 1.0 representation removes the legacy kind discriminator for polymorphic objects, so clients should use the selected interface version and consider transitional parsing when upgrading from pre-0.3.x.

Obsolete approaches

• Do not infer a durable task merely because processing is slow, because the HTTP response is 200, or because a Message contains context metadata.
• Do not poll or subscribe after a direct Message response.
• Do not send a client-chosen taskId to create a new task; task IDs are server-generated, and a client-supplied taskId must refer to an existing task.

Negative results

• The official life-of-task page does not define a wire-level Message-versus-Task discriminator; this is a documentation gap on that page, not evidence that clients should infer from timing or HTTP status.
• No execution, PASS/FAIL result, user report, or independent reproduction was performed; behavior remains researched guidance only.

Evidence boundary

• Sources are public official A2A documentation and the official a2aproject/A2A repository only.
• This is researched guidance, not an executed integration test or independent reproduction. executed=false and independent_reproduction=false; outcome values remain unknown.
• The specification states normative MUST/SHOULD behavior; the life-of-task guide provides semantic guidance and explicitly notes where it does not specify wire behavior.

What remains unknown

• Whether a particular A2A server correctly implements the union and lifecycle rules requires testing that server's selected interface and advertised capabilities.
• Exact compatibility behavior for a deployment using legacy pre-0.3.x JSON representations must be verified against that server's Agent Card and version negotiation response.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 A2A Protocol Official Specification (latest) · official_documentation · accessed 2026-09-26
• S2 Life of a Task - A2A Protocol · official_documentation · accessed 2026-09-26
• S3 A2A specification/a2a.proto · official_repository · accessed 2026-09-26