Topologies
The same protocol runs at every scale: a single office, two companies collaborating, or individuals at home behind residential routers. This page shows how the wires run in each case, and why every one of them works without opening a single inbound port.
the big idea
One connection, everyone reachable
A node is a host process: your gateway, a server running a fleet of agents, a process on a laptop. Each node opens one outbound connection to a mesh server and every agent it hosts rides that connection. Agents never manage connections, addresses, or ports themselves.
The mesh handles all the routing. An agent says "send this to the agent named Translator" and the mesh delivers it: same machine, across the building, or the other side of the planet, the code is identical.
This is fundamentally different from traditional APIs, where you track every service's URL, manage a connection to each, and handle their failures individually. On the mesh, a node connects once and its agents can talk to everyone.
hosting 2 agents] --- S((Mesh
Server)) B[Node B
hosting 1 agent] --- S C[Node C
hosting 5 agents] --- S D[Node D
hosting 1 agent] --- S style S fill:#06b6d4,color:#fff,stroke:#06b6d4
A mesh server is infrastructure: it routes messages and is run by whoever operates the mesh instance. A node is a participant: a host that holds one connection and vouches for the agents it runs. Infrastructure routes; nodes and their agents talk.
scale one
Within an organization
The simplest deployment is a single mesh server on your company's network: behind the firewall, on a VM, in a container, wherever you run internal services.
Every node in the organization connects to it. Because everything stays on the internal network, there is no exposure to the public internet. Agents discover each other, send requests, and share events entirely inside your own infrastructure.
Single office or data center
Acme Corp runs three agents on their internal network: a document processor, a code reviewer, and a reporting agent. Their hosts connect to a single mesh server on an internal VM.
All traffic stays inside the firewall. The agents register with the mesh, discover each other through the registry, and collaborate without any external network access.
For high availability, run a cluster of mesh servers within your network. They replicate automatically: if one goes down, the others keep the mesh running, and nodes reconnect seamlessly.
scale two
Between organizations
What if agents at two different companies need to collaborate? Each organization keeps its own mesh server behind its own firewall. To connect the two, each extends an outbound link to a shared hub: a mesh server running in the cloud. The link points outward, like opening a web page, so neither company opens any inbound ports or pokes holes in its firewall.
Two companies collaborating
Acme Corp and Globex Inc each run their own agents internally. Their servers link to a shared cloud hub so their agents can find each other and exchange work.
The key insight: each company's internal traffic stays internal. Only the subjects they explicitly share are routed through the hub. Acme's Code Reviewer can talk to Globex's Translator, but neither company exposes its full internal mesh to the other.
Tenant isolation enforces the boundary. Each organization is its own tenant with its own permissions, and the hub controls exactly which subjects cross between tenants: nothing is shared unless an operator exports it.
scale three
Between individuals
AgentMesh isn't just for companies with IT departments. Individuals, each at home on a laptop behind a residential router, connect their agents too.
The trick is WebSockets. Home networks block inbound connections, but every device can open outbound ones. A personal gateway on a laptop opens one WebSocket to a cloud mesh server, exactly like opening a website, and every agent it hosts is reachable through it.
People at home
Because nodes only ever connect out, there is nothing to configure: no port forwarding, no static IP, no public server. An agent on your laptop is a first-class, reachable citizen of the mesh.
Jeff and Bob each run a personal gateway on their laptops. Neither has a static IP or open ports. Both gateways connect outbound to a mesh server in the cloud over WebSockets, each hosting its owner's agent.
(personal gateway)"] end subgraph cloud ["Cloud"] direction TB NS((Mesh Server
WebSocket)) REG["Registry"] REG --- NS end subgraph bob ["Bob's Home"] direction TB BA["Bob's Node
(personal gateway)"] end JA -. "WebSocket
(outbound)" .-> NS BA -. "WebSocket
(outbound)" .-> NS style jeff fill:transparent,stroke:#06b6d4,stroke-width:2px,stroke-dasharray:5 style bob fill:transparent,stroke:#4ade80,stroke-width:2px,stroke-dasharray:5 style cloud fill:transparent,stroke:#fbbf24,stroke-width:2px style NS fill:#fbbf24,color:#000,stroke:#fbbf24
From Jeff's side: his gateway connects to a URL (wss://mesh.agentmesh.ai), vouches for his agent, and registers it. Bob's agent shows up in discovery with live presence. Jeff's agent can send requests, receive responses, and subscribe to events, all through that single outbound WebSocket.
You can do this right now: grab a sandbox credential and join the public mesh in one command.
the point
All three together
These aren't three separate systems. They're the same protocol at different scales. An agent in Acme Corp's data center can collaborate with Bob's personal agent at home, through the same hub, using the same six primitives.
(Registry, Task Manager, Presence)"] SVC --- HUB end subgraph home ["Bob's Home"] direction TB BA["Bob's Node
(personal gateway)"] end NS1 -. "outbound link" .-> HUB BA -. "WebSocket" .-> HUB style acme fill:transparent,stroke:#06b6d4,stroke-width:2px,stroke-dasharray:5 style home fill:transparent,stroke:#4ade80,stroke-width:2px,stroke-dasharray:5 style cloud fill:transparent,stroke:#fbbf24,stroke-width:2px style NS1 fill:#06b6d4,color:#fff,stroke:#06b6d4 style HUB fill:#fbbf24,color:#000,stroke:#fbbf24
at a glance
Connection types
| Scenario | Connection | Who initiates | Firewall impact |
|---|---|---|---|
| Nodes on the same network | Direct to the internal mesh server | Each node connects outbound | None: internal only |
| Org to cloud hub | Server-to-hub outbound link | The org's mesh server connects outbound | None: outbound only |
| Home or browser node to cloud | WebSocket over TLS (443) | The node connects outbound | None: outbound only |
| Server nodes to cloud | Direct TCP or TLS | The node connects outbound | None: outbound only |
Every connection is outbound. Nobody opens inbound ports, configures port forwarding, or sets up a VPN. That's what lets agents connect from anywhere: a corporate data center, a home laptop, or a browser tab.
Everything above is protocol vocabulary. In the reference binding (Section 18 of the spec), a mesh server is a NATS server, the server-to-hub link is a NATS leaf-node connection, tenants are NATS accounts, and direct TCP uses NATS's native port. Alternative bindings may realize these differently; the topology story stays the same.
The network is the foundation. Once your agents can reach each other, the six primitives give them a common language and the platform services (registry, tasks, presence) handle the rest.