Skip to main content
Tasks are the fundamental coordination mechanism in the A2A protocol. They represent stateful execution units that manage the complete lifecycle of work from client request to agent completion. Every interaction between a client and an agent is organized around tasks.

Task Object

A Task is the central coordination unit that tracks work execution. It encapsulates the entire interaction related to a specific goal or request, maintaining conversation history, execution state, and generated artifacts. Schema:
Realistic Example: Data Analysis Task A client requests sales data analysis. The task tracks the entire interaction:
What This Example Shows:
  • Task Identity: Unique id and contextId for tracking
  • Status Tracking: Current state (completed) with timestamp and agent message
  • Artifact Delivery: Complete analysis report with both text and structured data
  • History Preservation: Full conversation trail from initial request to completion
  • Metadata Context: Additional information about priority, duration, and categorization

TaskStatus Object

Represents the current state and context of a task at a specific point in time. Schema:
Example: Task Requiring Input

TaskState Enum

Defines all possible lifecycle states a task can be in during execution. Standard A2A States:
  • submitted - Task has been submitted and is awaiting execution
    • Initial state when task is created
    • Agent has acknowledged receipt but hasn’t started processing
  • working - Agent is actively working on the task
    • Task is being processed
    • May transition to input-required, completed, or failed
  • input-required - Task is paused, waiting for user input
    • Agent needs clarification or additional information
    • Task will resume once user provides required input
    • This is an interrupted state, not terminal
  • completed - Task has been successfully completed
    • Final deliverables are available in artifacts
    • This is a terminal state - task cannot be modified
  • canceled - Task has been canceled by the user
    • User explicitly stopped the task before completion
    • This is a terminal state
  • failed - Task failed due to an error during execution
    • Agent encountered an unrecoverable error
    • Error details typically included in status message
    • This is a terminal state
  • rejected - Task was rejected by the agent and was not started
    • Agent determined it cannot or will not perform the task
    • May occur during initial creation or after assessment
    • This is a terminal state
  • auth-required - Task requires authentication to proceed
    • Additional authentication needed from the client
    • Authentication expected to come out-of-band
    • Not a terminal state - task can resume after auth
Bindu Extensions <NotPartOfA2A>:
  • payment-required - Task requires payment to proceed
  • unknown - Task is in an unknown or indeterminate state
  • trust-verification-required - Task requires trust verification
  • pending - Task is pending execution (queued)
  • suspended - Task is suspended and not currently running
  • resumed - Task has been resumed after suspension
  • negotiation-bid-submitted - Task bid submitted for negotiation
  • negotiation-bid-lost - Task bid was lost in negotiation
  • negotiation-bid-won - Task bid was won in negotiation
State Transition Diagram: Legend:
  • Terminal States: completed, failed, rejected, canceled - Cannot transition further
  • Interrupted States: input-required, auth-required - Can resume to working
  • Active States: submitted, working - Task is being processed

Task Events

Events notify clients of task state changes and artifact updates, typically used in streaming (SSE) or push notification scenarios to keep clients informed without polling.

TaskStatusUpdateEvent

Sent by the agent when a task’s status changes, enabling real-time progress tracking. Schema:
Example: Progress Update During Processing
Example: Final Status Update (Completion)
Use Cases:
  • Real-time progress tracking for long-running tasks
  • Notifying clients when tasks require input or authentication
  • Alerting on task completion or failure
  • Streaming task execution updates via Server-Sent Events (SSE)

TaskArtifactUpdateEvent

Sent by the agent when an artifact is generated or updated, enabling incremental delivery of large outputs. Schema:
Example: First Chunk (New Artifact)
Example: Subsequent Chunk (Append)
Example: Final Chunk
Use Cases:
  • Streaming large reports or documents in chunks
  • Progressive rendering of generated content
  • Real-time display of agent-generated outputs
  • Reducing memory overhead for large artifacts
Chunking Strategy:
  • append: false - Start new artifact or replace existing
  • append: true - Add content to existing artifact
  • lastChunk: true - Signal completion of artifact delivery

Task Operations & Parameters

Parameters used for various task operations including execution, querying, and management.

TaskSendParams <NotPartOfA2A>

Internal parameters for task execution within the Bindu framework. Schema:
Example:

TaskIdParams

Simple parameters containing a task ID, used for basic task operations. Schema:
Example: Cancel Task

TaskQueryParams

Parameters for querying task details with optional history limiting. Schema:
Example: Get Task with Limited History
Response:
Use Cases:
  • Retrieving task status without full history
  • Reducing payload size for list operations
  • Efficient polling for task updates
  • Getting recent conversation context only

ListTasksParams <NotPartOfA2A>

Parameters for listing multiple tasks with optional history limiting. Schema:
Example: List All Tasks with Limited History
Response:
Use Cases:
  • Dashboard views showing multiple tasks
  • Task management interfaces
  • Batch status checking
  • Filtering tasks by status or context
  • Pagination with history control

TaskFeedbackParams <NotPartOfA2A>

Parameters for providing feedback on completed tasks. Schema:
Example: Positive Feedback
Example: Constructive Feedback
Response:
Rating Scale:
  • 5 - Excellent: Exceeded expectations
  • 4 - Good: Met expectations well
  • 3 - Satisfactory: Met basic expectations
  • 2 - Poor: Below expectations
  • 1 - Very Poor: Did not meet expectations
Use Cases:
  • Quality assurance and agent improvement
  • User satisfaction tracking
  • Identifying areas for enhancement
  • Training data for agent optimization
  • Performance metrics and analytics
Best Practices:
  • Provide specific, actionable feedback
  • Use ratings consistently across tasks
  • Include context in metadata
  • Submit feedback promptly after task completion
  • Be constructive in criticism

Message Sending Parameters

Parameters for sending messages to agents to initiate or continue task interactions.

MessageSendConfiguration

Configuration options for message sending behavior. Schema:
Example: Blocking Request with JSON Output
Example: Non-Blocking with Push Notifications

MessageSendParams

Parameters for sending a message to an agent. Schema:
Example: Initiate New Task (Blocking)
Response: Completed Task
Example: Continue Existing Task (Provide Input)
Important Notes:
  • Cannot restart tasks in terminal states (completed, canceled, rejected, failed)
  • Use blocking: true for quick operations, false for long-running tasks
  • acceptedOutputModes helps agent format response appropriately
  • Include taskId in message to continue existing task

Push Notification Parameters

Parameters for managing push notification configurations associated with tasks.

ListTaskPushNotificationConfigParams

Parameters for retrieving all push notification configurations for a task. Schema:
Example:
Response:

DeleteTaskPushNotificationConfigParams

Parameters for removing a push notification configuration from a task. Schema:
Example:
Response:
Use Cases:
  • Clean up obsolete webhook endpoints
  • Remove notification configs after task completion
  • Update notification routing by removing old configs
  • Manage webhook lifecycle
Related Methods:
  • tasks/pushNotificationConfig/set - Add or update notification config
  • tasks/pushNotificationConfig/get - Retrieve specific config
  • tasks/pushNotificationConfig/list - List all configs for a task