Push Notification Reliability Characteristics: an AgentCard extension for delivery guarantee discovery

[devmaha]

Problem

A2A's spec is explicit that push notification delivery isn't guaranteed (§3.7: "MUST NOT be considered a reliable delivery mechanism"; §3.5.3/§4.3.3 leave retry/backoff to MAY/SHOULD). In practice, implementations are already filling that gap independently and incompatibly:

• a2a-python's core transports have no built-in retry today (feat(proto)!: improve grpc ergonomics #871).
• a2a-java ships an optional Kafka-based queue manager as a separate module.
• a2a-redis (independent, not core-maintained) built two different
  reliability tiers — Redis Streams for durable delivery, Redis Pub/Sub for best-effort — because the SDK provides neither by default.

Three different technical answers to the same gap, with no way for a client
to discover which one a given agent has chosen before depending on it.

What this isn't

Checked directly: gateway products (LiteLLM, Solace Agent Mesh) don't invent retry semantics — both stay thin and delegate to whatever messaging infrastructure sits underneath. So this isn't a case for standardizing a retry algorithm — that would fight a layering the ecosystem has already chosen. It's a case for discovery: let a client learn what an agent's notification path guarantees, the same way capabilities.streaming already lets it learn what the agent supports, before choosing an interaction strategy.

Proposal

A data-only extension adding one field:

​json { "uri": "https://github.com/<org>/a2a-push-notification-delivery/tree/v0.1", "description": "Delivery guarantee for this agent's push notification channel", "required": false, "params": { "notificationDeliveryGuarantee": "best-effort" } } ​

notificationDeliveryGuarantee: best-effort / at-least-once / exactly-once — the one piece of vocabulary that converges across mature messaging systems checked (NATS JetStream, RabbitMQ), scoped explicitly to notification delivery, not task execution.

Full write-up, including field names considered and dropped along the way, here: [link to a public gist]

Open question I'd genuinely like input on

Is this stable/agent-level enough for AgentCard, or should it wait for a transport-specific descriptor A2A doesn't have yet? AgentCard.version is an existing precedent for deployment-tied information living in the card, but I don't think that fully settles it either way.