Should MRP Pivot to "The A2A Relay"? — Strategic Evaluation

Date: March 31, 2026 Context: Evaluating whether to overhaul MRP around the thesis: "A2A defines the standard, MRP provides the relay. Every protocol needs infrastructure. HTTP needed web servers. SMTP needed mail relays. A2A needs a broker for the agents that can't be servers."

The Thesis is Directionally Right

The gap is real. Here's who's doing what:

The search for "A2A relay" returns zero results. Nobody is building this exact thing.

What Gives Me Pause

Concern 1: How Big is the Addressable Problem?

Agents that genuinely can't host an HTTP endpoint:

The honest truth: the biggest A2A market (enterprise cloud agents) doesn't need a relay. They already have endpoints. The segment that needs a relay is real but smaller — concentrated in developer tooling and local agent space.

Concern 2: HiveMQ is Already Here With More Firepower

HiveMQ has published a 4-part series on exactly this thesis: "A2A is point-to-point and that doesn't scale; you need a broker." They have:

• Enterprise customers already running MQTT at scale
• The IoT/edge angle (constrained devices)
• A team, funding, and market presence
• A working demo of A2A over MQTT

Their weakness: MQTT is not HTTP/WebSocket. It's a different protocol stack. Developers building AI agents think in HTTP and WebSocket, not pub/sub topics with QoS levels. That's a real opening for MRP.

Concern 3: The Full Engineering Effort is Significant

To build a credible A2A facade:

That's 3-4 months before you can claim "A2A-compatible relay."

Concern 4: Dependency Risk

Positioning as "infrastructure for A2A" means your fate is tied to A2A's decisions. If A2A v2.0 adds a native relay/broker mode (which they could — the gap is well-documented), your differentiation evaporates overnight.

The Recommended Path: Don't Overhaul. Evolve.

The right play isn't "rewrite MRP as an A2A relay." It's a three-phase strategy that keeps what works, adds interoperability incrementally, and focuses scarce time on the highest-leverage moves.

Phase 0 — Get Users First (Now, 2-4 weeks)

This is the most important thing and it has nothing to do with A2A.

MRP's #1 problem isn't protocol compatibility — it's that nobody is using it. No amount of A2A compatibility fixes a cold network.

Focus on:

• One killer use case with a built-in audience: Claude Code agents talking to each other via the Bridge. This already works. Make it dead-simple, write a tutorial, ship example workflows (code review agent, test runner agent, deployment agent).
• Get 50 real agents on the relay. Not hypothetical. Real developers using the Bridge to connect real coding agents.
• Ship the MRP streaming feature. LLM-powered agents need streaming. This is table stakes.

Why this first: nobody adopts an A2A relay that has zero agents on it.

Phase 1 — Lightweight A2A Read Bridge (Month 2-3)

After you have real agents and real usage, add a thin A2A compatibility layer:

1. Auto-generate A2A Agent Cards from MRP agent profiles. Serve at /.well-known/agent.json per agent. ~500 lines of Go.
2. Accept message/send JSON-RPC and translate to MRP messages. ~800 lines of Go.
3. Map tasks/get to MRP thread retrieval. ~300 lines of Go.

This is 3-4 weeks of work, not 16. You skip the hard parts (OAuth, SSE streaming, outbound A2A client) and focus on the highest-value feature: any A2A client can discover and message your agents.

Don't build the OAuth bridge yet. Use API keys for the A2A facade initially.

Phase 2 — Evaluate and Double Down (Month 4+)

By this point you have data:

• Are external A2A clients actually discovering and messaging MRP agents?
• Is the Bridge driving real adoption?
• Is anyone asking for outbound A2A (MRP agents calling external A2A agents)?

If yes → invest in the full bidirectional bridge, OAuth, streaming translation. If no → the A2A relay thesis was wrong and you didn't waste 4 months on it.

The Technical Opportunity: What Maps Cleanly

Despite the caution above, the protocol mapping between A2A and MRP is surprisingly clean:

A2A Agent Card ↔ MRP Agent Profile

A2A Task ↔ MRP Thread + Message Schemas

Proposed A2A Relay Architecture

┌──────────────────────────────────────────────────────────┐
│                    MRP Relay Server                       │
│                                                          │
│  ┌─────────────┐    ┌──────────────┐    ┌─────────────┐ │
│  │  A2A Facade  │    │  MRP Core    │    │  MRP Native │ │
│  │  (JSON-RPC)  │◄──►│  (existing)  │◄──►│  WebSocket  │ │
│  └──────┬───────┘    └──────────────┘    └──────┬──────┘ │
│         │                                        │        │
└─────────┼────────────────────────────────────────┼────────┘
          │                                        │
          ▼                                        ▼
   ┌─────────────┐                          ┌─────────────┐
   │  External   │                          │  MRP Agent  │
   │  A2A Client │                          │  (behind    │
   │  (standard) │                          │   NAT/FW)   │
   └─────────────┘                          └─────────────┘

Is It Worth It?

The narrow A2A facade (Phase 1) — yes, absolutely. 3-4 weeks for A2A discoverability is high leverage. It turns every MRP agent into an A2A-visible agent with zero work from the developer. Nobody else offers this.

The full overhaul to "A2A Relay Platform" — not yet. The market signal isn't strong enough to justify 3-4 months of solo engineering, especially when:

• HiveMQ is attacking the same gap with more resources
• Agent Gateway could add relay features at any time
• A2A's spec is still evolving (dependency risk)
• You have zero users to validate the thesis with

The One-Line Version

Keep the MRP wire protocol. Add A2A Agent Card generation and message/send translation as a feature (not a rewrite). But spend 80% of your time getting real agents on the relay — that's the moat, not protocol compatibility.

The right sequence is users → traction → interoperability, not interoperability → hopefully users.

Sources: Agent Gateway · HiveMQ: A2A Enterprise Limitations · HiveMQ: A2A Over MQTT · Zuplo: A2A Guide · A2A Protocol Spec · A2A Key Concepts · Everything Wrong with A2A