The A2A Task Lifecycle: Why Agents Need More Than Request-Response

A2A is task-centric. When a client sends work to a remote agent, that work becomes a Task with its own identifier and an observable lifecycle.

The states are: submitted (received, not started), working (actively processing), input-required (waiting on the client for more information), and the terminal states completed, failed, and canceled.

Unlike a simple request-response call, a Task is stateful: it can run for a long time, stream updates, pause to ask a question, and resume. That is what makes A2A suitable for real work rather than toy demos.

The six states

• submitted — the Task has been received but work has not yet begun.
• working — the remote agent is actively processing the Task.
• input-required — the agent needs more information and is waiting on the client before it can continue.
• completed — the Task finished successfully; Artifacts are available.
• failed — the Task ended in error.
• canceled — the Task was stopped by request.

A Task is created when a client sends its first Message, and from there it moves through these states until it reaches a terminal one.

The four methods you need

message/send     # send a message; create or continue a task
message/stream   # send a message and subscribe to live updates
tasks/get        # retrieve a task's current state and artifacts
tasks/cancel     # cancel an in-progress task

That's the whole surface for driving a task. A client starts one by sending a Message; the response carries the Task, including its identifier and current state. From there it can poll with tasks/get, or — better — subscribe to streaming updates so it learns of state changes as they happen.

The rule you cannot break

Every Task must reach a terminal state. A well-behaved remote agent always emits a terminal event, because a client that never hears one waits forever.

This is the single most common bug in early implementations: the work finishes internally but no terminal state is reported, and the caller hangs. If a client of yours hangs, this is the first thing to check — and it applies to error paths too, not just the happy one.

Never let a failure disappear.
Every failure reaches the caller as an error or a failed task — never as silence.

input-required is a feature, not an error

Real delegation is rarely one-shot. The input-required state lets a remote agent pause and ask a clarifying question mid-task, then resume when the client answers — turning a rigid call into a genuine collaboration.

Consider: an agent is asked to generate a report. Partway through it realizes it needs a date range. Instead of guessing or failing, it moves the task to input-required and asks:

event: task state -> input-required
event: message  -> "Which time range should I cover?"

# client replies on the SAME task
event: task state -> working

Same task, no lost context. The alternative — failing and starting over — throws away everything the agent had already done.

Tasks are not stateless calls

The instinct from REST is to treat each call as independent. A2A tasks are the opposite: they hold state across many messages and can span a long conversation, including pauses for input.

Related tasks can also share a context, so an agent can connect a follow-up request to earlier ones and reason about the whole thread rather than each request in isolation. Designing as if every call were stateless throws away exactly what makes A2A suited to multi-step collaboration.

Three ways to receive updates

• Poll with tasks/get for simple cases where you just need to check in.
• Stream with Server-Sent Events (message/stream) for live progress on interactive work a person is waiting on.
• Push notifications for long jobs: the client registers a callback, disconnects, and the agent notifies it on state changes.

The underlying Task is identical in all three. Only how you receive updates changes — so you can start interactive and fall back to notifications for the long tail without changing your model.

Why an explicit lifecycle helps

Modeling tasks as stateful, observable objects is what makes A2A operable. You can build dashboards that show every in-flight task, retry logic that reacts to failed states, and orchestration that waits on completion before triggering the next step.

The lifecycle is not bureaucracy — it is the observability layer that lets multi-agent systems be operated, not just launched.