Creativity · Agent Protocol
A2A Task Handoff — Semantics & Lifecycle
A2A models delegated work as a Task object with a well-defined lifecycle: submitted → working → input-required → completed / failed / canceled. The calling agent opens the task, the receiving agent streams status updates and artifacts back, and both sides can pause, resume, or cancel. This lets A2A handle long-running work — hours or days — that doesn't fit a single request/response.
Protocol facts
- Sponsor
- Google (+ industry partners)
- Status
- proposed
- Spec
- https://google.github.io/A2A/
- Interop with
- A2A, server-sent events, JSON-RPC, webhooks
Frequently asked questions
What states can an A2A task be in?
Standard states are submitted, working, input-required (agent is asking for clarification), completed, failed, and canceled. Transitions between states are streamed so the caller can render progress.
How does A2A handle tasks that take hours?
The protocol is asynchronous by design. The receiving agent keeps the task ID alive, streams periodic status updates, and the caller can reconnect later via the same task ID — or receive a webhook callback when the task completes.
Can the receiving agent ask the caller for more info mid-task?
Yes — that's what the input-required state is for. The agent pauses, emits a question, waits for the caller to supply additional input, then resumes.
Sources
- Google — A2A overview — accessed 2026-04-20