Skip to main content
Tasks are the core unit of work in the A2A protocol, managing the complete lifecycle from submission to completion with built-in state tracking and storage. The user asks for task status; the agent calls A2A JSON-RPC to list or cancel remote tasks.

How It Works

Quick Start

1

Send Message (Creates Task)

2

Get Task Status

3

Cancel Task


Task Lifecycle

Every A2A interaction creates a Task that progresses through defined states:

Task States

Python Task States


Task Structure

A task contains all information about an A2A interaction:

Task Fields

If you embed TaskStore directly: update_status, add_artifact, and add_to_history are no-ops once a task is terminal — they return the task unchanged.

JSON-RPC Methods

tasks/get — Retrieve a Task

Response:
Task not found:

tasks/list — List Tasks

The tasks/list method is available in the task store but not yet exposed via JSON-RPC. This method is planned for future implementation.
The task store supports listing tasks with optional context filtering:
Planned JSON-RPC Interface:

tasks/cancel — Cancel a Task

Response:
tasks/cancel also works on in-flight message/stream tasks — the stream stops and ends with a final cancelled status event. Response when the task is already terminal (completed, failed, or cancelled) — the state is left unchanged:

Python Client Implementation

Use the built-in A2AClient for task management from Python instead of hand-rolling aiohttp/requests calls — it wraps the JSON-RPC surface and handles auth, streaming, and task lifecycle for you.

Task Store

The A2A server maintains an in-memory task store that tracks all tasks:
  • Tasks are automatically created when message/send or message/stream is called
  • Streamed tasks follow the same lifecycle as message/send: they move working → completed | failed | cancelled; on success the final response is appended to history and the artifact is stored on the task. The task stays in the store while the stream is running.
  • Each task gets a unique UUID
  • Tasks within the same conversation share a contextId
  • Task history includes both user messages and agent responses
  • Artifacts contain the agent’s output
  • Store is per-server-instance and does not persist across restarts
  • The store holds up to 10,000 tasks; once that cap is reached, the oldest terminal tasks are evicted first. Tasks whose response is still being produced are pinned and never evicted.

Context-Based Conversations

Tasks can be grouped by contextId for multi-turn conversations:

Error Handling

Common error codes returned by task management methods: Error Response Format:

Best Practices

Always check task state before assuming completion. Tasks can fail or require input.
Use context IDs to group related tasks and maintain conversation history.
Cancel unnecessary tasks to free resources and avoid confusion.
Handle JSON-RPC errors and HTTP errors gracefully.
Once a task reaches completed, failed, or cancelled, its status cannot change. tasks/cancel on a terminal task returns -32002 and the state is unchanged. Treat these three states as sinks in your client.

A2A Protocol

Server setup and configuration

Handoffs

Multi-agent communication patterns