[ ABORT TO HUD ]
SEQ. 1
SEQ. 2
SEQ. 3
SEQ. 4
SEQ. 5
A2A Task Lifecycle
How Tasks Flow Between Agents
In A2A, work is organized around Tasks - structured units of work that flow between a Client Agent and a Remote Agent.
Task State Machine
┌─────────┐ ┌────────────┐ ┌──────────┐
│ CREATED │────▶│ IN_PROGRESS│────▶│COMPLETED │
└─────────┘ └──────┬─────┘ └──────────┘
│
┌────▼────┐
│ BLOCKED │ (needs input from client)
└────┬────┘
│
┌────▼────┐
│ FAILED │
└─────────┘
Task Lifecycle Example
// 1. Client creates a task
POST /a2a/tasks
{
"skill": "book_flight",
"input": {
"origin": "London",
"destination": "New York",
"date": "2026-05-15"
}
}
// 2. Remote agent processes and responds
{
"taskId": "task_abc123",
"status": "IN_PROGRESS",
"updates": [
{ "type": "status", "message": "Searching 5 airlines..." },
{ "type": "status", "message": "Found 12 flights" }
]
}
// 3. Agent might need clarification (BLOCKED)
{
"status": "BLOCKED",
"question": "Do you prefer direct flights only or include layovers?",
"options": ["direct_only", "include_layovers"]
}
// 4. Client responds, agent completes
{
"status": "COMPLETED",
"result": {
"flight": "BA177",
"price": "$542",
"departure": "09:15"
}
}
Key A2A Interaction Patterns
| Pattern | Description | Use Case |
|---|---|---|
| Fire-and-Forget | Submit task, don't wait | Background processing, batch jobs |
| Request-Response | Submit task, wait for result | Simple delegation (booking, search) |
| Streaming | Receive real-time updates | Research, long-running analysis |
| Negotiation | Propose → Counter → Accept | Price negotiation, scheduling |
🎯 Pro Tip: Always implement the BLOCKED state. Real-world tasks frequently need clarification. An agent that can ask for input mid-task is far more useful than one that guesses and fails.
SYNAPSE VERIFICATION
QUERY 1 // 3
What happens when an A2A task enters the 'BLOCKED' state?
The task is cancelled
The remote agent needs input from the client before it can continue
The server crashes
The task retries automatically