feat(spec): Introduce native Pub/Sub primitives for scalable multi-agent collaboration

[aglicacha]

A Note on the "Runtime"
Throughout this proposal, the term "runtime" is used to describe the logical entity responsible for managing topics, handling subscriptions, and routing EventMessages from publishers to subscribers. It's crucial to understand that this "runtime" is an abstract role within the Pub/Sub pattern, not a prescribed component of the A2A protocol itself.

We refer to the concrete implementation of this role as the Runtime.

The A2A protocol deliberately does not dictate how this Runtime should be implemented. The choice of implementation is left to the system architect and depends entirely on the specific requirements of their environment. For instance, the Runtime could be:

A dedicated, standalone Agent that programmatically manages topics and subscriber lists.

A facade layer built on top of mature, battle-tested message queuing infrastructure such as RocketMQ, Kafka, or cloud-native services like AWS SNS/SQS or Google Cloud Pub/Sub.

Our strong recommendation is to leverage existing message queue infrastructure to fulfill the Runtime's responsibilities. This approach allows developers to benefit from the scalability, reliability, and rich feature sets of these specialized systems, while the A2A protocol remains focused on defining the interoperable contract for agent-to-agent communication.

In essence, the A2A protocol defines the language agents use to talk about Pub/Sub; the Runtime is the engine that makes the conversation happen.

Context & Motivation
The current A2A specification is built on a powerful point-to-point (P2P) model. This is excellent for direct request/response interactions. However, building scalable and resilient multi-agent systems requires a decoupled, event-driven communication pattern, for which Publish/Subscribe (Pub/Sub) is the standard.

Analysis of community examples and our production practice demonstrates that developers must currently implement a fragile, inefficient, and centralized "router" actor in the application layer to simulate Pub/Sub. This approach introduces a single point of failure and a performance bottleneck, while pushing infrastructure concerns (message routing) onto the developer.

To enable true multi-agent autonomy and system evolvability, Pub/Sub should be a first-class citizen in the A2A protocol.
Having comprehensively analyzed the prevailing specifications, We found that current A2A specification provides three well-defined communication patterns:

• RPC (Remote Procedure Call): Command-oriented requests for managing Task lifecycles (e.g., GetTaskRequest, CancelTaskRequest).

• Stateful Object Observation (Webhooks): A mechanism to subscribe to state changes of a single resource instance (e.g., SetTaskPushNotificationConfigRequest).

• Conversational Messaging: A direct, 1-to-1, request/response paradigm for interactive dialogue (SendMessageRequest).

These patterns serve their purpose well but lack a native mechanism for broadcasting information to a dynamic set of interested parties in a decoupled manner. This PR introduces the Pub/Sub pattern to fill this architectural gap, enabling use cases like system-wide alerts, real-time data feeds, and multi-service event notifications.

Fixes #1029

[darrelmiller]

Can I suggest that you wait a few days while we merge PR #1160 as both of the files that you changed will no longer be part of the specification as they do not contain normative content? Then it will be easier to discuss the changes you are proposing.

[aglicacha]

@darrelmiller Thank you for the reminder. I will temporarily stop modifying these files and submit the changes after the refactoring is merged.

[vongosling]

struct type is json object. If we send a binary, simple string, do we need to convert?

[aglicacha]

That's a good question. The information being published may exist in different forms, so it may be better to impose less constraints on its content format. Perhaps using bytes would be better? @darrelmiller What do you think?

[kevinkaylie]

Native Pub/Sub primitives for multi-agent collaboration pairs well with Enclave v0.9.5 for access control on topic subscriptions.

How Enclave fits:

• Enclave role → permissions can gate topic subscriptions — a viewer role cannot subscribe to high-sensitivity topics, an admin can publish to any topic
• enclave.vault can store topic metadata and access policies with signed receipts
• enclave.run_playbook() can orchestrate multi-stage workflows that publish to topics at specific stages

On the runtime abstraction: Enclave roles are defined at the enclave level, not per-runtime. The same agent presenting a valid Enclave capability token can subscribe across runtimes — the capability token is verifiable by any subscriber without a shared auth server.

The combination: Pub/Sub for message routing + Enclave for access control on subscriptions and topic policies = scoped collaboration with cryptographic enforcement.

Repo: https://github.com/kevinkaylie/AgentNexus — docs/ADR-013.md

[0xbrainkid]

The Pub/Sub extension fills a real gap — the current P2P model forces developers to build fragile centralized routers for any broadcast pattern, and pushing that infrastructure concern into the application layer is exactly the kind of thing a protocol should absorb.

One trust dimension worth considering in the Pub/Sub design: publisher identity verification for EventMessages. In the P2P model, the sender of a message is the agent you made the connection with — identity is implicit in the connection. In Pub/Sub, a subscriber receives EventMessages from a Runtime that is routing on behalf of potentially many publishers. The subscriber cannot assume the Runtime is trustworthy or that it has faithfully represented the publisher identity.

A minimal addition to the EventMessage schema:

{
  "type": "event",
  "topic": "market/price-update",
  "publisher": {
    "agent_id": "did:web:pricing-agent.example.com",
    "attestation_url": "https://agentfolio.bot/verify/pricing-agent",
    "signature": "base64-ed25519-sig-over-payload"
  },
  "payload": { ... }
}

The signature lets the subscriber verify the EventMessage came from the claimed publisher, independent of whether the Runtime is trusted. This is analogous to how signed git commits work — the intermediary (GitHub) does not need to be trusted for the commit signature to be meaningful.

Without this, a compromised Runtime can inject spoofed EventMessages with any publisher ID, and subscribers have no way to detect it. The publisher signature closes that gap with minimal overhead — one Ed25519 verify per received event.

[aglicacha]

The Pub/Sub extension fills a real gap — the current P2P model forces developers to build fragile centralized routers for any broadcast pattern, and pushing that infrastructure concern into the application layer is exactly the kind of thing a protocol should absorb.

One trust dimension worth considering in the Pub/Sub design: publisher identity verification for EventMessages. In the P2P model, the sender of a message is the agent you made the connection with — identity is implicit in the connection. In Pub/Sub, a subscriber receives EventMessages from a Runtime that is routing on behalf of potentially many publishers. The subscriber cannot assume the Runtime is trustworthy or that it has faithfully represented the publisher identity.

A minimal addition to the EventMessage schema:

{
  "type": "event",
  "topic": "market/price-update",
  "publisher": {
    "agent_id": "did:web:pricing-agent.example.com",
    "attestation_url": "https://agentfolio.bot/verify/pricing-agent",
    "signature": "base64-ed25519-sig-over-payload"
  },
  "payload": { ... }
}

The signature lets the subscriber verify the EventMessage came from the claimed publisher, independent of whether the Runtime is trusted. This is analogous to how signed git commits work — the intermediary (GitHub) does not need to be trusted for the commit signature to be meaningful.

Without this, a compromised Runtime can inject spoofed EventMessages with any publisher ID, and subscribers have no way to detect it. The publisher signature closes that gap with minimal overhead — one Ed25519 verify per received event.

This is indeed a great idea. The reason why this field is not currently included is mainly to consider the universality and extensibility of the protocol. It does not impose excessive restrictions on the fields and structure within the message but instead places everything in the payload. Users can extend it according to their system's needs. For example, how the subscriber should respond to the publisher after processing can also be specified in the payload.