Registry — 20 transports · verified 2026-09-25

Transports

The pipe, not the endpoint. A transport is the channel or wire format an agent's bytes travel over — MCP and A2A between software, Slack and email between people, SSH and mesh VPNs into machines, PSTN and WebRTC for voice. Integrations tell you what an agent connects to; transports tell you how the conversation physically moves.

T.01

Agent wire protocols — Wire formats between agents, hosts, and tool servers

T.02

Messaging channels — Human-facing chat and mail channels agents speak

T.03

Remote access & reachability — How the outside world reaches a local agent

T.04

Realtime media — Low-latency voice and media pipes

FAQ

Frequently asked

What counts as a transport?

The pipe, not the endpoint. A transport is the channel or wire format an agent's bytes travel over — MCP and A2A between software, Slack and email between people, SSH and mesh VPNs into machines, PSTN and WebRTC for voice. Integrations tell you what an agent connects to; transports tell you how the conversation physically moves.

Aren't Slack and Gmail already listed under integrations?

Yes — a channel can be both. As an integration, Slack is a target the agent connects to. As a transport, the Slack socket is how a human reaches the agent and how its replies get back out. The same channel appears in both registries when it plays both roles.

Why do wire protocols matter more than model choice?

Protocols outlive vendors. An agent that speaks MCP can use every MCP server ever written; one that speaks A2A can be discovered and tasked by any compliant orchestrator. The wire format determines who else the agent can talk to — swap the model and the transports still hold.

How are transports assigned to systems?

Only transports verifiable from each system's documented feature set are tagged — an MCP client or server mode, a documented Slack/Telegram channel, SSH into a provisioned workspace, telephony for voice agents. Tags are re-checked when the catalog is regenerated.