Message driven A2A

[c-mysec]

I was wondering if there are use cases where Event-Driven communication (i.e., Kafka) would be better than HTTP for handling tasks, states, messages and artifacts transport. Ok, currently we have push notifications and SSE. But SSE needs a tunnel initiated by a client agent and is not really 100% async. And push notifications can have delivery and reliability problems,

[c-mysec]

For example, when an agent publishes an event (i.e., something has happened), and one or more other agents react in a way that the original agent did not anticipate.
To draw a parallel with the HR department: when someone resigns (an event), multiple actions are triggered by different individuals who don't need to be directly prompted. They observe the event and respond according to their responsibilities.
Does this make sense?
I know this can be achieved using traditional event driven (agents listening on currently implemented event topics and streams).
I want to think if there are use cases where event driven A2A is better.

[c-mysec]

Some advantages of event-driven architecture that A2A can rely on include reliability, built-in retry policies in the infrastructure, and back-pressure handling.

[andreibesleaga]

There are already integrations with Kafka (useful for existing Enterprise systems as well).

https://www.confluent.io/blog/google-agent2agent-protocol-needs-kafka/

https://www.kai-waehner.de/blog/2025/05/26/agentic-ai-with-the-agent2agent-protocol-a2a-and-mcp-using-apache-kafka-as-event-broker/

https://www.kai-waehner.de/blog/2025/04/14/how-apache-kafka-and-flink-power-event-driven-agentic-ai-in-real-time/

[c-mysec]

A2A JsonRPC messages are messages and can use almost any kind of transport. It doesn't need an "integration".
Of course, you can use an integration but (i think) it adds a useless layer in most cases.
I think the protocol should be transport agnostic. But the standard limits to HTTP, SSE and Push Notification (3. Transport and Format).
I want to know which use cases can benefit from using an event-driven transport and why the specs limits the transport.

[dinesh707]

RFC: A2A Protocol Extension for Broker-Based Communication

• Status: Draft / Proposal
• Topic: Asynchronous Transport Layer Extension (Inbox & Registry Pattern)

1. Executive Summary

This RFC proposes an extension to the Agent2Agent (A2A) Protocol to support Message Brokers as a first-class transport layer. This proposal introduces the Agent Inbox Pattern for communication and a Discovery Registry Topic for stateful agent discovery, moving away from point-to-point HTTP lookups.

2. Motivation

In a broker-based architecture, agents shouldn't need to know each other's network addresses.

• The Inbox Pattern: Standardizes how messages are routed to specific agents via unique topics.
• Persistent Discovery: Traditional A2A requires querying a .well-known endpoint. In a broker environment, a persistent "Registry Topic" allows agents to discover the entire ecosystem simply by subscribing to a single stream.

3. Agent Discovery & Connection

3.1 Current State: Direct HTTP Discovery

Existing A2A relies on direct polling of an agent.json file hosted at a specific domain. If the domain is unreachable, the agent is effectively "invisible."

3.2 Proposed State: The Registry Topic

We propose a standardized Discovery Channel (e.g., a2a.registry).

• Stateful Stream: This topic should be configured as a "Compacted Topic" (Kafka) or use "Retained Messages" (MQTT/NATS).
• Announcement: When an agent comes online, it publishes its Agent Card to this topic using its agent_id as the message key.
• Continuous Discovery: Any new agent entering the network can read the a2a.registry from the beginning to instantly build a local map of all active agents and their "Inboxes."

Updated Agent Card (Inbox Specification)

The Agent Card now explicitly defines its inbox for receiving tasks:

{
  "agent_id": "agent-774-beta",
  "name": "ProductionAgent_v1",
  "transports": [
    {
      "type": "broker",
      "provider": "kafka",
      "connection_details": {
        "bootstrap_servers": ["kafka.cluster.local:9092"],
        "inbox_topic": "a2a.inbox.agent-774-beta",
        "registry_topic": "a2a.registry"
      }
    }
  ]
}

4. Technical Specification: The Inbox Pattern

4.1 Request-Response Flow

Communication is entirely asynchronous. To maintain the "request-response" semantics of A2A, we utilize the Return Inbox pattern.

1. The Inbox: Every agent listens to their own inbox_topic.
2. The Request: The Sender publishes a task.create payload to the Receiver's inbox.
3. Return Address: The Sender must include its own inbox name in the message metadata (reply-to).
4. The Response: The Receiver processes the task and publishes the status update or result back to the topic specified in the reply_to field.

4.2 Message Metadata (Headers)

Broker-specific headers must be used to route these messages without parsing the JSON body:

Header Key	Description	Example
a2a-msg-type	Type of A2A operation	task.create
reply-to	The sender's inbox for the response	a2a.inbox.sender-123
correlation-id	Matches the JSON-RPC ID	rpc-99821
agent-id	Identity of the sender	sender-123

5. Comparison Matrix

Feature	HTTP Transport (Current)	gRPC Transport (Current)	Broker Transport (Proposed)
Discovery	HTTP GET /.well-known/	Registry/Service Mesh	Subscribe to a2a.registry
Address	URL (DNS/IP)	Host:Port	Inbox Topic Name
Messaging	POST Request	RPC Call (Unary/Stream)	Publish to Inbox
Response	HTTP Response Body	RPC Response	Publish to reply-to Inbox
Persistence	None (Ephemeral)	None (Ephemeral)	Broker buffers (Reliable)
Coupling	Synchronous	Synchronous/Streaming	Fully Asynchronous

6. Backward Compatibility & Interoperability

1. Registry Bridges: A bridge service can poll the a2a.registry and expose those agents as a dynamic directory for legacy HTTP-only agents.
2. Inbox Gateways: A gateway can listen to an Inbox and convert the message into an HTTP POST for agents that cannot connect to the broker natively.

7. Security Considerations

• Topic Permissions: The a2a.registry should be "Write-Once/Read-Many" for agent IDs to prevent spoofing.
• Inbox Privacy: Agents should only have "Read" permissions for their own inbox topic and "Write" permissions for others' inboxes.
• Identity: Agent Cards in the registry should be digitally signed (JWS) to ensure the inbox_topic actually belongs to the claimed agent_id.

[Lancetnik]

@dinesh707 I have some doubts about the shared topic a2a.registry. It could be a bad idea for security reasons. What if I wanted to create a hierarchy of agent groups? In this way, agents from one group should not receive messages from another group. In your design, each agent knows each other.

[Lancetnik]

Also, it seems to conflict a bit with the current .well-known implementation. You should already know the agent's address (or card registry) to retrieve a card. What if we introduced the same RPC API for requesting an agent's card via a known channel? This channel could be owned by the registry or the agent itself.

[Lancetnik]

Unfortunately, not all brokers support RPC. However, it can be emulated using correlation-id mapping.

[Lancetnik]

Alternatively - we can split "Card discovery" and "Agents communication" parts of protocol.
This way we can stay with current HTTP Cards fetching, but communicate using topic from a card

[Lancetnik]

@dinesh707 another concern about Message Metadata (Headers) - not all brokers has a header field. Some of them (Redis as an example) allows just push a bytes.

So, A2A Async Protocol shouldn't rely on broker-specific things and encode all required data to single structure and push it as bytes

[Lancetnik]

Updated Agent Card (Inbox Specification) - I suggest to use AsyncAPI bindings here: https://github.com/asyncapi/bindings/tree/master/kafka

We can reuse combination of Server bindings + Channel bindings to describe agents' server and inbox

cc @derberg