Why architecture matters here
A2A task state matters because real delegated work is often long-running, interactive, and cancellable -- not simple request/reply -- so a stateful task lifecycle is essential for A2A to handle real agent-to-agent work. When an agent delegates a task, the task might be long-running (a complex process taking time), interactive (needing more input mid-task), or cancellable (needing to be stopped) -- not a quick synchronous request/reply. A stateful task model (a lifecycle -- submitted, working, terminal states, input-required) handles this: the task is tracked as a stateful entity (via its task id and state), the caller doesn't block (it tracks the task asynchronously -- status updates), interactive tasks pause for input (input-required), and tasks can be cancelled and persisted. This is what lets A2A handle real delegated work (long-running, interactive, cancellable) -- versus a limited request/reply model (which couldn't handle long or interactive tasks). For A2A (agents delegating real work to each other), the task-state model is essential, and understanding it (the lifecycle, states, tracking) is understanding how A2A manages delegated work.
The state-machine insight is the structural core, and it's what makes task tracking well-defined. A delegated task is modeled as a state machine -- a well-defined set of states and transitions. The task starts submitted (delegated, not yet started), moves to working (the agent processing it), and reaches a terminal state (completed -- success with results; failed -- error; cancelled -- stopped) -- with the possible input-required state (the agent needs more input -- pausing until provided, then resuming to working). This state machine (well-defined states and transitions) makes the task's status well-defined and trackable: at any point, the task is in a known state (the caller can query/observe it), and the transitions are defined (submitted → working → completed/failed/cancelled, or working → input-required → working) -- so the caller always knows the task's status and what it means. This well-defined lifecycle (versus an ad-hoc, unclear task status) is what makes A2A task tracking reliable (a clear state model -- the caller knows exactly what state the task is in and what's happening). The terminal states (completed/failed/cancelled) clearly indicate the outcome (the caller knowing if the task succeeded, failed, or was cancelled -- and getting the results on completion). Understanding the state-machine core (a well-defined lifecycle of states and transitions -- making task status clear and trackable) is understanding the structural core of A2A task state.
And the long-running-async-plus-input-required reality is what makes the task model handle real work, beyond request/reply. Two aspects make A2A tasks more than simple request/reply. Long-running async: many delegated tasks take a long time (a complex analysis, a multi-step process) -- too long for a synchronous request/reply (the caller can't block waiting minutes/hours). So the task is asynchronous: the caller submits it (getting a task id) and doesn't block -- it tracks the task's state via status updates (streaming -- the server pushing state changes -- or polling -- the caller checking) -- so the caller can do other work while the task runs, checking its progress. This handles long-running tasks (asynchronously tracked -- not a blocking request/reply). Input-required: some tasks are interactive -- the agent needs more input partway (e.g., a clarification, a decision, additional data) to proceed. The input-required state handles this: the task pauses (entering input-required -- signaling it needs input), the caller provides the input, and the task resumes (back to working). This enables interactive, multi-turn tasks (the agent and caller exchanging information mid-task -- not just a one-shot request/reply). So the long-running-async (tasks tracked asynchronously -- handling long tasks) and input-required (interactive tasks -- handling mid-task input) aspects are what make the task model handle real delegated work (long-running and interactive -- beyond simple request/reply). Understanding the long-running-async and input-required reality (asynchronous tracking of long tasks, interactive input mid-task) is understanding how the task model handles real work.
The architecture: every piece explained
Top row: the task and states. The task: a unit of delegated work (an agent delegating a task to another -- modeled as a stateful entity). State machine: the task lifecycle -- submitted (delegated, not started) → working (being processed) → terminal -- a well-defined state machine. Terminal states: completed (success, with results), failed (error), cancelled (stopped) -- the outcomes (the caller knowing the result). Task id + tracking: each task has an id (for reference and tracking -- the caller using it to query/track the task's state).
Middle row: async and interaction. Long-running tasks: tasks that take a long time (asynchronous -- not synchronous request/reply -- the caller not blocking, tracking the task instead). Status updates: how the caller tracks the task -- streaming (the server pushing state changes/progress -- real-time) or polling (the caller checking the state periodically) -- tracking the async task. Input-required state: the task needs more input from the caller to proceed (pausing in input-required, resuming when the input is provided) -- enabling interactive tasks. Artifacts + results: the task's outputs (artifacts -- files, data -- and results -- produced on completion) -- what the task delivers.
Bottom rows: durability and control. Persistence: tasks surviving across sessions/restarts (a long-running task outliving a single connection -- persisted so it continues and can be tracked across sessions) -- durability for long tasks. Cancellation: stopping a running task (the caller cancelling -- transitioning the task to cancelled -- the agent stopping the work) -- control over running tasks. The ops strip: state tracking (tracking the task states -- the caller knowing each task's state; the server maintaining it -- via streaming/polling), timeouts (task timeouts -- handling tasks that run too long or get stuck -- so they don't hang indefinitely; and input-required timeouts -- if the caller doesn't provide input), and observability (observing the tasks -- their states, transitions, durations, failures -- for monitoring and troubleshooting the delegated work).
End-to-end flow
Trace a long-running task through its lifecycle. An agent delegates a complex analysis task to another agent (via A2A). The task is submitted (the caller getting a task id) -- and since it's long-running, the caller doesn't block (it tracks the task via its id). The task moves to working (the agent processing the analysis). The caller tracks the progress via status updates (streaming -- the server pushing state/progress updates -- so the caller sees the task progressing). Partway through, the agent needs more input (a clarification) -- so the task enters input-required (signaling it needs input). The caller provides the input, and the task resumes (back to working). Finally, the task completes (reaching the completed terminal state) -- producing the results/artifacts (the analysis output) -- which the caller retrieves. So the task went through its lifecycle (submitted → working → input-required → working → completed), tracked asynchronously by the caller (via the task id and status updates), with an interactive input mid-task (input-required) -- handling the long-running, interactive delegated work (beyond a simple request/reply). The task-state model managed the real delegated work.
The async-tracking and input-required vignettes show the key aspects. An async-tracking case: the task is long-running (taking minutes) -- so the caller doesn't block (it submitted the task, got the id, and tracks it via streaming status updates -- doing other work meanwhile, seeing the task's progress) -- the asynchronous model handling the long task (versus blocking on a synchronous request/reply, which would be impractical for a minutes-long task). The async tracking handled the long-running task. An input-required case: the task needed a clarification mid-way -- so it entered input-required (pausing, signaling the need) -- and the caller provided the clarification, resuming the task -- the interactive input-required state enabling the multi-turn task (the agent and caller exchanging information mid-task). The input-required handled the interactive task.
The cancellation and persistence vignettes complete it. A cancellation case: the caller decides to cancel the task (it's no longer needed) -- so it cancels the task (transitioning it to the cancelled terminal state -- the agent stopping the work) -- the cancellation controlling the running task (stopping it cleanly). The cancellation stopped the task. A persistence case: the task is long-running (outliving the caller's session -- e.g., the caller disconnects and reconnects) -- so the task is persisted (surviving across sessions -- the caller reconnecting and tracking the task via its id, even after a disconnect) -- the persistence letting the long task outlive a single session. The persistence handled the long task across sessions. The consolidated discipline the team documents: model delegated tasks as stateful entities with a well-defined lifecycle (the state machine -- submitted → working → completed/failed/cancelled, with input-required -- making task status clear and trackable), handle long-running tasks asynchronously (the caller tracking via task id and status updates -- streaming/polling -- not blocking), support interactive tasks (input-required -- the agent getting mid-task input), deliver artifacts/results on completion, persist tasks (surviving across sessions -- for long tasks), support cancellation (stopping running tasks), and manage state tracking, timeouts (stuck/long tasks, input-required), and observability -- because real delegated agent work is often long-running, interactive, and cancellable (not simple request/reply), so a stateful task lifecycle (the state machine, async tracking, input-required, persistence, cancellation) is essential for A2A to handle real agent-to-agent delegated work.