Connect two AI agents across machines
without opening a port

Part 1The setup, the night the whole network went dark

We have two AI assistants. One runs on a Mac at home, the other on a server in the cloud (a box left on around the clock on the internet). We want the two to talk, with the one on the Mac driving the one in the cloud.

It sounds like just running a cable between them, but there is a hidden wall you would not know about until you try. Let me lay the groundwork so you can see the wall first, then I will tell you how to cross it.

Part 2Groundwork, why getting two machines to "talk" is not easy

Think of each computer like a phone. For two to talk, the one answering needs a "number" the other can dial.

The problem is that most home machines and phones can dial out, but have no number for others to dial in. It is like living in a condo with a single shared front number. You can call out fine, but no one outside can call your unit directly. The technical name for this state is being behind NAT.

A cloud machine is different. It has its own public "number," and anyone can come in. But that is the double edge: a machine anyone can reach is also a machine anyone with bad intent can probe. So these machines run a firewall, a fence that keeps every door shut by default and opens only the ones you mean to open. Each door here is called a port.

So the wall is this. The Mac (the one that wants to drive) happens to be the side with "no number to dial in." The cloud machine keeps every door shut for safety. So how do you get the two to talk?

Part 3Two easy paths that look right but cost too much

Path one, open a door on the cloud machine and let the Mac walk straight in. It works, but it also means opening that door for the whole internet to see. Anyone can come knock, with only a password as the single barrier. That is adding risk to solve a small problem.

Path two, lay a private network (VPN) on top, something like Tailscale, to make the two machines feel like they are on one network. We tried it, and the result was the whole network going dark. This Mac already routes its internet through a company VPN, so when a second VPN went on top, the two fought over "which way traffic should go," competing for the main route, and the machine got confused and could not reach the internet at all.

Both paths cost too much, either risk or a dead connection, to solve a small problem. The answer we actually use turned out to be an old tool that already ships on every machine.

Part 4The idea, if it can dial out on its own, you never have to open a door

Here is the key. A machine behind NAT may have no number to dial in, but it can always dial out. And in fact, we already run SSH from the Mac out to the cloud machine every single day.

An SSH tunnel just flips the angle. Instead of waiting for the cloud to reach in to the Mac (which it cannot), we have the Mac dial out and hold a "pipe" open, through the SSH connection that is already trusted and encrypted. The mouth of the pipe on the Mac side is a door on its own machine, and stepping through that pipe lands you at the service in the cloud.

Think of it as: instead of cutting a new door through the wall (risky), you use a private elevator that already connects the two, and quietly send packages through it.

What you get

• Not a single port opened to the internet. The cloud service listens only on its own machine, and outsiders cannot see it.
• No fight with the company VPN. This pipe is just one program running. It does not touch the machine's routing, so the two coexist.
• Encrypted end to end, because it rides the SSH connection you already trust.

So the AI assistant on the Mac talks to the one in the cloud through "a door in its own house" that comes out in the cloud, while the outside world sees nothing at all.

Part 5Making the tunnel permanent, not just while the machine is left on

A pipe you open by hand has one weak spot: shut the machine or drop the connection and the pipe is gone, and whatever depends on it goes down with it.

The fix is to hand this job to a "background worker" that shows up for work on its own and gets back up if it falls over. On the Mac that is launchd, in the cloud it is systemd. We set three of them to start by themselves and recover by themselves.

1. The assistant service on the Mac side
2. The SSH pipe itself
3. The service on the cloud side

With all three legs in place, the system comes back on its own after a reboot, with no need to reconnect it by hand every time.

A boundary worth knowing: this pipe is one-way (the Mac dials out to the cloud), which happens to match exactly what we want, the Mac in the driving seat. If one day you want two-way control, move the hub to the side that has a public number (the cloud machine) instead.

Part 6A bonus lesson, almost rebuilt the whole thing over a wrong command

Right after wiring it up, we checked whether the link was live. The command we ran said "it only sees its own machine," as if nothing had connected. We nearly tore the whole thing down to rebuild.

Luckily we first went and read the raw data straight from where the system reports its real status, and it was plain that the other machine was connected and responding fine. The real fault was that we ran the wrong command ourselves. The one we ran watches something else, not the connection status. Use the right command and everything showed up at once.

The principle that came out of it: before concluding that something is broken, check whether you are asking in the right place, using the right tool, then confirm against the real data. So often what looks "broken" is really us asking in the wrong place. That holds for everything, not just this job.

Part 7The short version, ready to use

• If you need to connect two machines and one of them sits at home behind NAT, do not start by opening a port or layering on a VPN. Try having that machine dial out and open an SSH tunnel first.
• It is safer (no public opening) and does not clash with the VPN you already run.
• To make it permanent, hand it to the system's background workers (launchd / systemd) so it starts and recovers on its own.
• Before concluding something is broken, check that you are using the right command or tool, then confirm against the real data.

Written from real work, not theory, the actual job of connecting a fleet across machines.