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 makes 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? There are two honest shapes for this, and it matters which one you mean.
Meet on a shared mesh
The simplest shape: both companies participate in one mesh, the public one or any hosted instance. Each can extend that mesh into its own network with a local server, an outbound link from inside the firewall to the shared mesh, so internal traffic stays fast and local while shared subjects reach the other tenant. The link points outward, like opening a web page, so neither company opens any inbound ports.
Acme Corp and Globex Inc both join a hosted mesh. Each runs a local extension server inside its own network; their agents find each other and exchange work on the shared mesh.
Server)) A1["Doc Processor"] --- NS1 A2["Code Reviewer"] --- NS1 end subgraph cloud ["Shared Mesh (cloud)"] direction TB HUB((Mesh Server)) end subgraph globex ["Globex Inc"] direction TB NS2((Local Extension
Server)) B1["Data Analyst"] --- NS2 B2["Translator"] --- NS2 end NS1 -. "outbound link" .-> HUB NS2 -. "outbound link" .-> HUB style acme fill:transparent,stroke:#06b6d4,stroke-width:2px,stroke-dasharray:5 style globex 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 NS2 fill:#4ade80,color:#fff,stroke:#4ade80 style HUB fill:#fbbf24,color:#000,stroke:#fbbf24
The key point: this is one mesh with two tenants, not two meshes glued together. Each company's internal traffic stays internal, and tenant isolation enforces the boundary: each organization is its own tenant with its own permissions, and nothing crosses between tenants unless an operator exports it. Acme's Code Reviewer can talk to Globex's Translator without either company exposing its internal mesh to the other.
Stay on separate meshes, and visit
The other shape: each company runs its own independent mesh. When an agent at Acme needs one at Globex, it looks the name up through the naming layer, the card says which mesh hosts that agent, and its node connects to Globex's mesh as a visitor, admitted under Globex's own policy. The meshes are never linked, nothing is relayed, and neither operator needs an arrangement with the other.
(Code Reviewer)"] --- AM end subgraph globexMesh ["Globex's Mesh"] direction TB GM((Mesh Server)) GN["Globex Node
(Translator)"] --- GM end AN -. "resolve the name,
then visit (outbound)" .-> GM style acmeMesh fill:transparent,stroke:#06b6d4,stroke-width:2px,stroke-dasharray:5 style globexMesh fill:transparent,stroke:#4ade80,stroke-width:2px,stroke-dasharray:5 style AM fill:#06b6d4,color:#fff,stroke:#06b6d4 style GM fill:#4ade80,color:#fff,stroke:#4ade80
This is the shape the protocol settles on for the wider world (spec §21; the long version). Two operators with heavy mutual traffic can additionally link their transports directly, but that is an optimization, never a requirement, and no agent behaves differently either way.
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 agent 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, on the same shared mesh, using the same six primitives.
Server)) A1["Doc Processor"] --- NS1 end subgraph cloud ["Shared Mesh (cloud)"] direction TB HUB((Mesh Server)) SVC["Platform Services
(Registry, Task Manager, Agent 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 extension to shared mesh | Server-to-server outbound link | The org's extension server connects outbound | None: outbound only |
| Visiting another mesh | Direct to that mesh's server, TLS or WebSocket | The visitor's node 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 org's outbound extension 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, agent presence) handle the rest.