Comparisons

The agent communication space is evolving fast. New protocols appear regularly, each with different goals, architectures, and trade-offs. This page explains where Subway fits — honestly, including where alternatives are stronger.

The three layers#

Before comparing individual protocols, understand that agent infrastructure has three distinct layers:

Most developers will use protocols from multiple layers. They are complementary, not competing. MCP connects your agent to a database. A2A manages a task between two agent systems. Subway is the network that makes agents reachable in the first place.

Quick comparison#

Subway vs MCP#

MCP is Anthropic's open standard for connecting AI apps to external tools and data. Think "USB-C for AI."

These are different layers. MCP defines what tools are available. Subway defines how agents find and talk to each other.

Use together

An agent connects to local MCP servers for tools (database, search, code execution) and uses Subway to communicate with other agents on the mesh. MCP handles the tool interface; Subway handles the network.

When to use what

• MCP alone: Your AI app needs tools and data sources. No agent-to-agent communication.
• Subway alone: Agents on different machines need to find each other and exchange messages.
• Both: Agents that use local tools and collaborate with remote agents.

Subway vs A2A#

A2A is Google's open protocol for communication between opaque agent systems. It focuses on structured task management and cross-framework interop.

The key difference

A2A assumes HTTP reachability. Every agent needs an addressable endpoint — a URL that other agents can reach. That works inside a data center or on the public internet with known addresses.

Subway solves the harder problem: agents behind NATs, firewalls, laptops, mobile devices, and networks you don't control. No fixed addresses needed. Agents register a name, and the mesh handles routing.

Use together

Subway as the transport layer, with A2A-style Agent Cards for capability discovery:

When to use what

• A2A alone: Agents on addressable HTTP endpoints with structured task management across different frameworks.
• Subway alone: Agents need to communicate across networks simply — just send, call, broadcast.
• Both: A2A task semantics over Subway's encrypted P2P transport.

Subway vs Hyperspace#

Hyperspace describes itself as the "Gossiping Agents Protocol" — a P2P protocol for agent discovery, coordination, commerce, and collective intelligence. The parent company operates a decentralized GPU inference network with 2M+ nodes.

This comparison requires nuance because Hyperspace exists at two levels: the protocol specification (ambitious) and the shipped product (different from the spec).

What Hyperspace gets right

Ambitious vision. Their protocol spec describes 9 primitives covering context, coordination, commerce, and collective intelligence — a superset of MCP, A2A, and Stripe MPP. The "Discover → Run → Learn → Gossip" mental model is elegant and easy to understand.

Strong narrative. Their positioning against existing protocols is clear and compelling. The comparison tables on their landing page are well-crafted.

Network scale. Their inference network claims 2M+ nodes and 3.6M downloads — significant numbers regardless of active usage.

Where they differ

Two different products. Hyperspace's shipped product is a decentralized GPU inference network where users earn points for contributing compute. The protocol specification — with its 9 primitives, collective learning, and micropayments — is largely unreleased. The @hyperspace/sdk referenced in code examples is not publicly available.

Token economics. Hyperspace is fundamentally a crypto project with points, validators, staking, and blockchain settlement. This is a design choice with real trade-offs:

• ✅ Creates economic incentives for network participation
• ❌ Adds complexity for developers who just want agents to communicate
• ❌ Points-based systems attract resource farmers, not necessarily builders
• ❌ Many enterprise environments prohibit crypto-adjacent dependencies

Collective intelligence. Their unique differentiator — agents learning from each other via trajectory gossip — is demonstrated through a research experiment (agents training GPT-2 models and sharing results). It's an interesting concept but not yet a general-purpose capability for arbitrary agent workloads.

Different philosophies

Hyperspace is building a token-incentivized ecosystem where agents contribute compute and knowledge to a shared network. The protocol is designed to be everything: context, coordination, commerce, and intelligence.

Subway is building simple, reliable agent networking — and nothing else. No tokens, no collective learning, no payment channels. Just: agents find each other, exchange encrypted messages, and get work done.

# Subway: working in 60 seconds
curl -sSL https://subway.dev/install.sh | sh  # install
subway agent --name a.relay                     # connect agent A
subway agent --name b.relay                     # connect agent B
subway send a.relay "hello"                     # B receives "hello"

When to use what

• Hyperspace when: you want to participate in a token-incentivized P2P compute network with collective learning — once the protocol SDK ships publicly.
• Subway when: you want agents talking reliably in 5 minutes. No tokens, no account, no waiting. Works today.

Subway vs NATS#

NATS is a mature, high-performance message bus with pub/sub, request-reply, and streaming (JetStream). It's battle-tested infrastructure used by companies like Synadia, Mastercard, and Tesla.

NATS is objectively stronger at

• Raw throughput — millions of messages per second vs Subway's agent-optimized path
• Message persistence — JetStream provides durable, replayable streams
• Maturity — battle-tested in production at massive scale
• Ecosystem — clients in 40+ languages, extensive tooling

Subway is stronger at

• Zero infrastructure — no cluster to deploy or manage
• End-to-end encryption — the relay genuinely cannot read your messages
• NAT traversal — agents behind firewalls, laptops, and mobile networks connect automatically
• Agent-native identity — built-in Ed25519 keypairs and human-readable names

When to use what

• NATS when: you're in a controlled environment (data center, cloud), need very high throughput, message persistence, or mature ops tooling.
• Subway when: agents need to communicate across uncontrolled networks — different machines, different NATs, different clouds — with end-to-end encryption and zero infrastructure.

Subway vs Kafka / gRPC#

Apache Kafka

Kafka is a distributed event streaming platform. It's not really an agent communication tool — it's a durable event log.

Use Kafka when: you need durable event streams, exactly-once processing, or data pipelines. Use Subway when: agents need real-time communication.

gRPC

gRPC is a high-performance RPC framework. It's great for service-to-service calls between known endpoints.

Use gRPC when: you have known services with strict API contracts. Use Subway when: agents discover each other dynamically across networks.

Subway vs Agent Frameworks#

LangGraph, CrewAI, AutoGen, Swarm — these are agent orchestration frameworks that define how agents think, plan, and execute.

These are complementary. The framework runs inside each agent. Subway connects agents to each other across machines. You can use CrewAI for local agent logic and Subway for inter-agent messaging over the network.

The bottom line#

Subway is the networking layer. The part that makes agents reachable, messages encrypted, and infrastructure unnecessary.

If you're building systems where agents need to discover and communicate with each other across networks — that's what Subway was built for.

curl -sSL https://subway.dev/install.sh | sh