A2A Ecosystem Survey: Finding mq9's Value
Background
Since A2A (Agent2Agent) was launched by Google and handed off to the Linux Foundation, it has become the most active open protocol in the Agent communication space. Dozens of ecosystem projects have formed around it. This survey uses awesome-a2a (github.com/ai-boost/awesome-a2a, 529 stars, documentation in 9 languages) as the entry point, scans what the entire A2A ecosystem is currently doing, and then answers one specific question: where should mq9 sit on this ecosystem map.
I. A Full Picture of A2A Ecosystem Projects
Categorizing all projects listed in awesome-a2a by function yields seven major categories. Here are the representative projects and their current state in each category.
Official and Community SDKs
A2A's official SDK already covers major languages; the community is filling in idiomatic implementations.
| Language | Official SDK | Major community implementations |
|---|---|---|
| Python | a2a-sdk v1.0 (reference) | a2a_min, python-a2a, A2AServer, adk-modular-architecture |
| JavaScript | @a2a-js/sdk v1.0 | nestjs-a2a, Artinet SDK |
| Go | a2a-go v1.0 | trpc-a2a-go, a2aserver/a2a-go, yeeaiclub/a2a-go |
| Java | a2a-java (Maven) v1.0 | a2ajava (Spring Boot), a2a4j |
| .NET | A2A (NuGet) v1.0 | a2adotnet, a2a-net |
| Rust | (no official) | a2a-rs (hexagonal arch), rust-agentic |
Native Framework Integrations
All major Agent frameworks now support A2A: LangGraph, CrewAI, Google ADK, Semantic Kernel, AG2 (AutoGen), LlamaIndex, Marvin, MindsDB, Genkit. AG2's A2aAgentServer + A2aRemoteAgent is among the more complete bidirectional implementations.
Frameworks Designed Specifically for A2A
| Project | Positioning | Highlights |
|---|---|---|
| AgentUp | Developer-first A2A framework | Config-driven, built-in OAuth2/JWT/API Key |
| AgentScope Runtime | Production-grade A2A runtime | Secure sandbox + Agent as API |
Platform / Runtime Layer
Projects wrapping A2A into "all-in-one" runtimes.
| Project | Capabilities included |
|---|---|
| Aira | A2A network + registry discovery + platform framework |
| Bindu | A2A wrap + DID identity + OAuth2 + X402 payments + observability + retry + scheduling |
| Inai | P2P discovery + DID + libp2p + ANR + ERC-8004 on-chain |
| Elkar | Task-management layer: send / track / orchestrate |
| Cognisphere | Development framework based on Google ADK |
| OpenAgents | Multi-agent platform + MCP + WebSocket + gRPC + HTTP |
Registry and Discovery
A2A spec explicitly leaves the registry to the ecosystem. A few attempts so far.
| Project | Approach | Limitation |
|---|---|---|
| AWS A2A Registry | Semantic search via Bedrock + S3 Vectors | Cloud-vendor lock-in |
| A2A Registry by prassanna-ravishankar | Open-source directory, REST API + Python client | Still early-stage |
| Hashgraph Online | On-chain registration (HCS-14 UAID), cross-protocol bridging | Involves cryptocurrency |
| Aira | Registry discovery as part of the platform | Not independently usable |
Commercialization Layer
Combining A2A with payments and on-chain identity — a separate track. Representative projects: WorkProtocol (USDC escrow on Base, Agent job marketplace), Lucid Agents Commerce SDK (x402/ERC8004/AP2 payment protocols), etc.
Validation and Debugging Tools
a2a-inspector (official compliance check), A2A Validation Tool by llmx-de (cross-platform desktop app), Lingua Universale (formal verification DSL). Tooling in this space is relatively complete.
II. Ecosystem Map: Crowded Zones vs. Vacuums
Re-categorizing the seven groups above by "maturity of the landscape + whether mq9 should enter" yields this key table.
| Zone | Project count | Landscape state | Should mq9 enter? |
|---|---|---|---|
| Official SDK | 5 languages fully covered | Extremely crowded | No — integrate by wrapping |
| Community SDK | 2–4 per language | Crowded | No |
| Framework integrations | Major frameworks supported | Crowded | No |
| Dedicated A2A frameworks | 2 pioneers | Early | No |
| Platform / Runtime (all-in-one) | 5–6 in parallel | Crowded but scattered | No (stay focused) |
| Agent Discovery | A few incomplete attempts | Vacuum | Yes |
| Reliable async transport | Nobody working on it | Vacuum | Yes (core) |
| Monitoring / Tracing | Nobody working on it | Vacuum | Yes (natural fit) |
| Protocol-neutral infrastructure | Nobody working on it | Vacuum | Yes (differentiator) |
| Commercialization / payments / on-chain | Fringe exploration | Separate track | No |
Four vacuums cluster together — that's mq9's natural home. Here's a closer look at each gap.
III. The Four Gaps in Detail
The awesome-a2a README explicitly states "Community contributions welcome" in the "Tools & Utilities" section, actively recruiting work in several directions. Combining the ecosystem survey, here are the four gaps mq9 can fill.
Gap 1: Agent Discovery / Registry
The A2A protocol explicitly doesn't build a registry — it leaves that to the ecosystem. Current attempts all have obvious limitations:
| Existing project | Limitation |
|---|---|
| AWS A2A Registry | Cloud-vendor lock-in, requires Bedrock + S3 Vectors |
| Hashgraph universal registry | On-chain approach, involves cryptocurrency |
| Aira registry | Tied to its own platform framework, not independent |
| prassanna-ravishankar/A2A Registry | Early open-source directory, no semantic search |
mq9's built-in AGENT.REGISTER + AGENT.DISCOVER supports text search + semantic search + tag filtering, is self-hostable, lightweight, and protocol-agnostic. It's currently the only solution that satisfies all four of: lightweight + self-hostable + protocol-neutral + semantic search.
Gap 2: Reliable Async Transport
A2A's default transport is HTTP + JSON-RPC + SSE. All three have concrete limitations:
| Current transport | Limitation |
|---|---|
| HTTP request-response | Both sides must be online simultaneously |
| SSE streaming response | Connection drop means data loss; must rely on tasks/resubscribe for replay |
| Webhook push notification | Fire-and-forget, no reliable delivery guarantee |
| Long polling | Poor real-time performance, high connection overhead |
Nowhere in the entire awesome-a2a list does any project position itself as "reliable Agent transport infrastructure." The closest, Inai, takes a P2P route — high engineering complexity, uncontrollable performance, positioned as a "network implementation" rather than a "transport pipe."
mq9's mailbox model is designed precisely for this gap: persistent messages, offline-tolerant both sides, N-to-N topology, message-level TTL and priority.
Gap 3: Monitoring / Tracing
The awesome-a2a README explicitly states:
Community contributions welcome: Adapters or libraries for integrating A2A task flow data into mainstream monitoring platforms like OpenTelemetry, Prometheus, Grafana, etc.
This direction is completely vacant. A2A tasks have a complete state machine (submitted → working → completed), but no standardized observability story.
Messages on the mq9 broker can naturally carry OpenTelemetry trace context (the same mechanism discussed in Kafka message tracing). Running A2A on mq9 naturally gives complete task flow traces. mq9 can cover this as a natural extension.
Gap 4: Protocol-Agnostic Communication Pipe
Every A2A ecosystem project is locked to the A2A protocol. Not a single project lets users run both A2A and custom protocols on the same underlying infrastructure.
mq9's two-layer SDK design naturally fills this gap:
| Integration path | Use case |
|---|---|
| Use mq9.a2a facade | Protocol-compliant integration, needs A2A ecosystem interoperability |
| Use mq9 native API directly | Internal team Agent communication, flexible schema definition |
Both go through the same broker underneath; protocol wrappers on top are optional. This "protocol-neutral infrastructure + any-protocol wrapping" is a clear open position.
IV. mq9's Place in the Ecosystem
Placing mq9 in the A2A protocol stack, its position is clear — no direct competition with existing projects.
| Layer | Who's doing it | Does mq9 participate? |
|---|---|---|
| Business application layer | Business teams write it themselves | No |
| Agent orchestration layer | LangGraph, CrewAI, AG2 | No |
| A2A protocol layer | a2a-sdk (5 official languages) | No |
| mq9 SDK wrapper layer | mq9.a2a and other protocol wrappers | mq9 provides |
| Transport layer | HTTP/SSE (default) / gRPC | mq9 provides an alternative |
| Message transport / mailbox | General MQ (Kafka, etc.) | mq9 broker, designed for Agents |
| Agent registry | Aira, AWS Registry, and other partial attempts | mq9 built-in |
| Agent identity / payments / on-chain | Bindu, Inai, etc. | No |
mq9 contributes at three layers: the SDK wrapper layer (lightweight facade), the transport layer (mq9 broker as an alternative transport option for a2a-sdk), and the Agent registry (built into the broker). All other layers respect the existing ecosystem.
V. mq9's Four Value Points
Based on the vacuum identification, mq9 has four genuine value points. Each maps to a clear ecosystem gap.
| Value point | Corresponding gap | Differentiation |
|---|---|---|
| Reliable transport for Agent communication | No project in the ecosystem positions itself here | Not competing with HTTP/SSE — an alternative option |
| Built-in Agent registry | A2A spec leaves it to ecosystem; all current solutions are incomplete | Lightweight, self-hostable, protocol-neutral, built-in semantic search |
| Protocol-agnostic communication pipe | All projects bet on A2A; nobody builds protocol-agnostic | Same infrastructure supports A2A and custom protocols |
| Minimal code to integrate Agents | a2a-sdk is complete but not convenient; 60 lines → 15 lines | Facade pattern; object types unchanged, interoperability preserved |
These four value points aren't stacked-up marketing copy — they're structurally inherent: the same broker, the same SDK, providing all four capabilities simultaneously, coupled together, reinforcing each other.
VI. mq9's Product Definition
Based on these research conclusions, mq9's product definition is:
mq9 is a foundational component for Agent communication, composed of two parts:
mq9 broker: a protocol-agnostic reliable message pipe, providing persistent mailboxes, a registry, and N-to-N topology.
mq9 SDK: a lightweight protocol wrapper layer, supporting A2A and other major Agent protocols, as well as user-defined protocols.
Around this definition, mq9 has three core value standards (Light, Solid, Open) and two integration paths (A2A standard integration + native API custom integration).
| Dimension | mq9's commitment |
|---|---|
| Light | Minimum code to integrate. A 60-line A2A Agent becomes 15 lines |
| Solid | Foundational components can't drag down the business when things go wrong |
| Open | 100% compatible with a2a-sdk standard, not locked to any specific protocol |
Things explicitly not built:
| What's not built | Who's doing it |
|---|---|
| The protocol itself | A2A working group, MCP protocol group |
| Agent orchestration | LangGraph, CrewAI, AutoGen |
| Agent frameworks | AG2, AgentUp |
| LLM integration | Application layer |
| Agent identity / payments / on-chain | Bindu, Inai, WorkProtocol |
| Large all-in-one Agent platforms | Aira, Cognisphere |
This restraint isn't passive — it's the active result of mq9's value positioning.
VII. Research Conclusions
Summarizing the entire survey into a few key judgments.
The current A2A ecosystem landscape: The protocol layer (SDKs) and application layer (frameworks) are already crowded — no room to enter. The platform layer is all doing "all-in-one," ambitious but scattered in positioning. The transport infrastructure layer is a vacuum; no project positions itself there.
The A2A protocol's own attitude: protocol is protocol, transport belongs to the ecosystem. The spec explicitly leaves discovery, reliable async delivery, and long-task recovery to the community, and in version 1.0 provides transport extension points (ClientFactory.register, AgentCard.supportedInterfaces, a2a-* parameter prefix). mq9 as an A2A transport is something the protocol layer has "blessed" — not a hack.
mq9's real value lies in SDK and broker working together.
mq9's true value isn't on the SDK side alone, or the broker side alone — it's in the two working together. Looking at either side in isolation, the value is incomplete.
| SDK alone | Broker alone | SDK + broker together |
|---|---|---|
| Anyone can write a facade on top of a2a-sdk | General MQ, no Agent-specific semantics | Complete Agent communication solution |
| No reliable transport guarantee | No convenient integration path | Light integration, solid transport, open protocol |
| Good user experience but unreliable underneath | Reliable underneath but high integration barrier | Business writes 15 lines of code for reliable Agent communication |
| Easy to copy | Already too many general MQs | Engineering depth and product experience mutually reinforce |
The SDK gives users a "light" integration experience on top; the broker gives users a "solid" transport guarantee underneath. Neither is complete without the other:
- Without the broker, the SDK is just another a2a-sdk wrapper, no different from other wrappers on the market
- Without the SDK, the broker is just another MQ — users have to write all the glue code themselves
- Together, they enable the end-to-end experience of "15 lines of code for reliable Agent communication"
This end-to-end experience maps to the complete range of Agent communication scenarios:
| Scenario | What mq9 provides |
|---|---|
| Cross-Agent calls | SDK auto-discovery + broker persistent mailbox |
| Long-task async processing | SDK wraps push notifications + broker stores intermediate state |
| Communication when both sides are offline | SDK auto-retry + broker persists messages until delivery |
| Multi-Agent collaboration | SDK hides topology details + broker native N-to-N support |
| Internal team custom protocol | SDK native API + broker doesn't parse message content |
| A2A standard integration | mq9.a2a facade + broker as transport |
Every scenario requires both SDK and broker working together. mq9's moat isn't either part — it's the coupling of the two. The SDK sets the ceiling (how good the user experience is); the broker sets the floor (how stable it is when things go wrong).
Final judgment: mq9's direction is what the A2A ecosystem genuinely needs but currently has no one filling. Nobody else in the ecosystem simultaneously has both a "lightweight facade + reliable broker." Everyone either builds only an SDK (lightweight but no transport guarantee), or builds only a broker or runtime (solid but high integration barrier), or builds an all-in-one (does everything but does nothing deeply). mq9's position is structurally correct: it's something nobody else is doing, it's what the A2A ecosystem itself is actively recruiting, and the protocol has left room for it with extension points. What remains is making both the SDK and broker solid, so the combined value of the two can fully materialize.