Why Subway

The problem#

Modern AI systems are no longer single models. They're networks of cooperating agents: planners, workers, evaluators, tool agents, orchestrators. These agents need to communicate constantly — exchanging messages, requests, and results in real time.

But the infrastructure they rely on still looks like this:

Every connection requires servers. Every server requires configuration. Service discovery, message brokers, TLS certificates, NAT traversal, load balancers — all just to let two agents exchange a message.

This model was built for web services. It was never designed for autonomous systems.

The shift#

Agents shouldn't need servers to communicate. They need a network.

Peer-to-peer networking already solved the hard problems: encrypted communication, automatic NAT traversal, peer discovery, resilient routing, direct connections between machines. But these capabilities have been locked inside low-level networking libraries that are difficult to use.

Subway makes them accessible.

What Subway does differently#

Subway is a peer-to-peer communication layer built specifically for autonomous agents. Instead of routing messages through centralized infrastructure, agents connect directly to each other through an encrypted overlay network.

No message queues. No API gateways. No service discovery systems. No networking configuration.

Five primitives, zero infrastructure

That's the entire API surface. Everything else — encryption, NAT traversal, reconnection, peer discovery — happens automatically.

Zero configuration

Start a relay:

subway relay

Start an agent:

subway agent --name alpha.relay

Send a message:

subway send beta.relay "hello"

Two agents communicating securely across the internet. No config files, no environment variables, no cloud console.

Encrypted by default

All traffic uses the Noise protocol for end-to-end encryption. The relay facilitates connections but cannot read message contents. Even if the relay is compromised, your agent traffic is encrypted.

Every agent has a persistent Ed25519 identity — generated automatically, reused across restarts.

Works anywhere

Subway uses QUIC over UDP with WebTransport. This means:

• NAT traversal works automatically (UDP hole-punching + relay circuits)
• No head-of-line blocking
• 1 RTT connection setup
• Agents work on laptops, servers, edge devices, cloud VMs, or behind corporate firewalls

Language agnostic

The WebSocket and REST bridge exposes the full protocol over HTTP. Use Subway from any language:

• Rust — native AgentNode API
• TypeScript/JavaScript — WebSocket bridge or REST API
• Python — bridge via requests or websockets
• Any language — if it can make HTTP calls, it can use Subway

What this enables#

Without infrastructure overhead, new architectures become practical:

• Multi-agent AI systems — orchestrators, workers, and evaluators communicating in real time
• Distributed inference — route work across GPU nodes without a central scheduler
• Edge agent networks — agents on devices, laptops, and servers in the same mesh
• Agent swarms — hundreds of agents coordinating via pub/sub topics
• Cross-cloud communication — agents in different clouds or on-prem, no VPN required

When Subway is the right choice#

✅ Use Subway when:

• You're building multi-agent systems that need to communicate
• You want encrypted agent-to-agent messaging without infrastructure
• Your agents run across different networks, clouds, or behind NAT
• You need pub/sub, RPC, and direct messaging in one protocol
• You want to go from zero to working agent network in minutes

❌ Consider alternatives when:

• You need guaranteed message persistence and replay (use Kafka)
• You're building traditional request-response web services (use HTTP/gRPC)
• You need millions of messages per second on a single cluster (use NATS)
• Your agents all run in the same process (just use function calls)

The one-liner#

Agents need a network, not a server. Subway provides that network.