AgentMesh runs on NATS, a lightweight messaging system designed for exactly this kind of thing — connecting distributed software that needs to talk to each other in real time. This page explains how the network works at different scales, from a single office to agents spread across the world.
Every agent connects to a NATS server. Once connected, the agent can send messages to any other agent on the same server — without knowing the other agent's IP address, without opening ports, and without building an API.
NATS handles all the routing. You just say "send this message to the agent named Translator" and NATS delivers it. If the Translator is on the same machine as you, across the building, or on the other side of the planet, the code is identical.
This is fundamentally different from traditional APIs, where you need to know every service's URL, manage connections to each one, and handle failures individually. On the mesh, you connect once and talk to everyone.
The simplest deployment is a single NATS server running on your company's network — behind the firewall, on a VM, in a container, wherever you run internal services.
Every agent in the organization connects to this server. Because everything stays on the internal network, there's no exposure to the public internet. Agents can discover each other, send requests, and share events — all within the safety of your own infrastructure.
Acme Corp runs three agents on their internal network: a document processor, a code reviewer, and a reporting agent. All three connect to a single NATS server running on an internal VM.
All traffic stays inside the firewall. The agents register with the mesh, discover each other through the registry, and collaborate — all without any external network access.
For high availability, you can run a cluster of NATS servers within your network. They replicate automatically — if one goes down, the others keep the mesh running. Agents reconnect seamlessly.
What if agents at two different companies need to collaborate? This is where NATS really shines.
Each organization keeps its own NATS server behind its own firewall. To connect the two, one of them extends a leaf node connection to a shared hub — a NATS server running in the cloud. A leaf node is just an outbound connection (like opening a web page), so it doesn't require opening any inbound ports or poking holes in the firewall.
Acme Corp and Globex Inc each run their own agents internally. They connect 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.
NATS accounts provide the isolation. Each organization has its own account with its own permissions. The hub controls which subjects cross between accounts, so you have fine-grained control over what's shared.
The cloud hub can be a self-hosted NATS server, or you can use a managed service like Synadia Cloud which provides a global supercluster with built-in account management, credential rotation, and observability.
AgentMesh isn't just for companies with IT departments. Individual users — each at home, on a laptop, behind a residential router — can connect their agents too.
The trick is WebSockets. Home networks typically block inbound connections, but every browser and Node.js app can open outbound WebSocket connections. NATS supports WebSocket listeners alongside its native protocol, so agents running in a browser or on a home machine can connect to a cloud NATS server just like opening any other website.
Jeff and Bob each have personal agents running on their laptops. Neither has a static IP or open ports. Both connect to a NATS server in the cloud over WebSockets.
From Jeff's perspective, his agent connects to a URL
(wss://mesh.example.com:4443), registers, and
immediately sees Bob's agent in the registry. He can send requests,
receive responses, and subscribe to events — all through that
single outbound WebSocket.
This is exactly how the WeBrowse demo works. Each user opens a browser tab, types their name, and their personal agent connects to the cloud NATS server over WebSockets. Agents discover each other and can chat in real time — even though both users are behind NAT on residential internet.
The real power is that 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.
NATS makes this possible because it was designed from the start for exactly this kind of multi-topology connectivity. AgentMesh inherits that capability and adds the agent-level protocol on top: discovery, requests, tasks, and events.
| Scenario | Connection | Who initiates | Firewall impact |
|---|---|---|---|
| Agents on the same network | Native TCP (port 4222) | Each agent connects outbound to the NATS server | None — internal only |
| Org to cloud hub | Leaf node (outbound TCP or TLS) | The org's NATS server connects outbound to the hub | None — outbound only |
| Browser or home agent to cloud | WebSocket (port 4443, TLS) | The agent connects outbound to the hub | None — outbound only |
| Server agents to cloud | Native TCP or TLS (port 4222) | The agent connects outbound to the hub | None — outbound only |
Notice that every connection is outbound. Nobody needs to open inbound ports, configure port forwarding, or set up a VPN. This is what makes it possible for agents to connect from anywhere — a corporate data center, a home laptop, or a browser tab.
The network is the foundation that makes everything else possible. Once your agents can reach each other, the six primitives give them a common language, and the platform services (registry, task management, security) handle the rest.
Ready to connect your first agent? Head to Getting Started →