Wiki · Concept · Last reviewed June 25, 2026

A2A Push Notifications

A2A push notifications are the Agent2Agent Protocol mechanism for sending asynchronous task updates from an A2A server to a client-provided webhook when a task changes state.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: A2A, AI Agents, Webhooks, Observability, Audit Trails, Security

Definition

A2A push notifications are the asynchronous update path in Agent2Agent Protocol. Instead of requiring an A2A client to hold a persistent streaming connection open, the server can notify a client-side webhook when a long-running task reaches a meaningful change, such as a terminal state, an input-required state, or an auth-required state.

This is not the same as a mobile app notification or a social-platform alert. In A2A, the push surface is a server-to-client webhook for task state. It belongs with AI Agent Observability and AI Audit Trails, because it is one of the points where delegated machine work becomes visible after the original prompt turn has already moved on.

Protocol Surface

The official A2A streaming and asynchronous operations page says an A2A server declares support for this feature in its Agent Card by setting capabilities.pushNotifications: true. The client supplies a PushNotificationConfig either in the initial SendMessage or SendStreamingMessage request, or later through CreateTaskPushNotificationConfig for an existing task.

The configuration includes the webhook url, an optional token for client-side validation, and optional authentication details that tell the A2A server how to authenticate to the webhook. The specification also defines operations to create, retrieve, list, and delete push notification configurations. Listing may use pagination, and deletion must permanently remove the specified configuration so no further notifications are sent to that webhook.

The notification body uses the same StreamResponse shape used by streaming operations. The payload can carry a task, message, status update, or artifact update. After receiving and verifying a notification, the client typically calls GetTask with the task ID to retrieve the complete current task object and any artifacts.

Streaming Versus Push

A2A has two update patterns. Streaming is best for low-latency observation of active work, incremental artifacts, and interactive exchanges. Push notification is better for disconnected scenarios: tasks that run for minutes, hours, or days; mobile or serverless clients; and workflows where the client only needs significant state changes rather than continuous output.

The governance difference is simple. Streaming keeps the connection visible. Push creates a later callback, often into a different service boundary. That callback needs its own authentication, replay protection, endpoint validation, logging, and incident handling.

Security Boundary

The A2A docs are explicit that push notifications are security-sensitive because they are asynchronous and server-initiated. On the server side, implementations should not blindly post to any URL supplied by a client. A malicious configuration can point at internal services or unrelated third parties, creating SSRF or amplification risk. The docs name allowlisting, ownership verification, and egress controls as mitigation patterns.

On the client side, the webhook receiver must verify that incoming notifications came from the legitimate A2A server. The docs mention signatures, tokens, API keys, HMAC, mTLS, and JWT/JWKS-style flows as possible mechanisms. They also call out replay protection through timestamps and nonces or unique event IDs, plus key management and rotation.

Governance Requirements

A governed A2A deployment should preserve the Agent Card capability that advertised push support, the task ID, configuration ID, webhook URL, tenant value if used, authentication scheme, token policy, registration time, deletion time, notification payload type, verification result, retry count, and the follow-up GetTask record. If the webhook triggers another workflow, that downstream action must be logged as a separate delegated step.

Operators should separate "notification received" from "task truth." The notification tells the client to inspect task state. It should not by itself approve a side effect, unlock a record, finalize a purchase, or mark human review complete.

Failure Modes

Webhook laundering. A notification from an agent is treated as authoritative approval instead of a cue to fetch and verify current task state.

SSRF and amplification. A client registers an internal or third-party URL, and the A2A server becomes an unwitting request sender.

Replay. An old notification is resent after task state has changed, causing duplicate processing or stale review.

Lost deletion. A configuration is supposed to be removed after completion or explicit deletion, but retries continue into an obsolete endpoint.

Audit split. The A2A server logs the task, the webhook logs the callback, and the downstream system logs the side effect, but no trace ties them together.

Source Discipline

Claims about A2A push notification operations should cite the official A2A specification and name the operation or object involved. Claims about disconnected scenarios, webhook responsibilities, SSRF risk, authentication to the webhook, replay protection, and JWT/JWKS examples should cite the A2A streaming and asynchronous operations page. Do not treat a vendor SDK example as the whole protocol.

Spiralist Reading

A2A push notification is the knock after the agent has left the room.

The human may no longer be watching the stream. The client may be asleep. The task may be running in another system under another operator's policy. A small webhook call then claims: something changed. Spiralist discipline asks what changed, who says so, which key proved it, which task it belongs to, and what the receiver is allowed to do next.

Open Questions

Sources

Return to Wiki