contextId
A contextId groups many tasks into one conversation, a taskId groups many messages into one job, and only the server creates a task id.
code-reviewer stops halfway through a review and asks your planner which base branch to use. The answer must reach that same review. Later the diff changes, and the planner wants a second review that remembers the first. Two ids carry this: the task id for the job and the context id for the conversation.
When you finish this section, you can continue a task, start a follow-up in the same context, and know who creates each id.
Two ids, two scopes
Context: an optional identifier that groups related tasks and messages. Tasks and messages with the same contextId should count as one conversational session.
Task id: the id of one stateful job. The server generates the task id when it creates a new task in response to a message. Message gives the rules for sending one back.
The server usually creates the context too. An agent is allowed to generate a new contextId for a message that has none, and the response must carry it. In the kit, every first message carries no ids, and every answer, even the direct reply in 02-message-reply.http, brings back a new context.
A client should treat a contextId from the server as an opaque identifier. Behind the id, the agent can keep internal state, conversation history, or LLM context across many interactions.
Propose your own context id only when you understand how the server will process it. A server that cannot take it must reject the request with an error, and it must not generate a new contextId for the response. The concept guide describes the context id as an identifier that the server generates, which leaves no room for a proposal (conflict D28). The specification wins, so expect either answer.
Continuing a task
When a task waits for you, answer on that same task and send both of its ids, as Message explains. Interrupted states follows the review's answer.
Only a task that is not terminal takes more messages. A message to a finished task fails with UnsupportedOperationError, as CancelTask and terminal states shows.
A follow-up is a new task
Once the review completes, a second round cannot reopen it. A refinement must start a new task in the same contextId. The specification gives the client two fields for that. A client is allowed to send a contextId without a taskId to start a new task in an existing context. A client should use the referenceTaskIds field of the message to point to related tasks.
The captures stop before such a follow-up. The kit's server would accept one: given a contextId and no taskId, its send creates a new task in that context. The kit's server code shows this. Figure 3.6 draws the captured review beside the follow-up a client would send next.
Nothing limits a context to one task at a time: agents can create a separate, parallel task for each follow-up message.
What the agent keeps
The review task keeps its four messages in history, and GetTask and ListTasks shows how to read them. Do not treat that history as a full transcript, because the agent decides which messages it keeps in the task history. In particular, messages from before the task was created can be missing from the history.
Contexts do not live forever either. An agent is allowed to expire or clean up contexts, and it should document any such policy. Check the agent's documentation before you rely on an old context id.
A2A protocol 1.0.1 · 3303592 · 2026-05-28 · Edition 2026.10