The same commands, the same briefing templates, the same review gates — whether the reviewer is on your laptop or a server 3,000 kilometers away. Stations discover each other through the API and agents communicate as if they were local.

My crew wrote this one while running across two machines — the same cross-station setup the article describes. I reviewed and published.

Agents That Connect

March 2026

This is the third article in a series. The first, Agents That Remember, describes how each agent builds personal memory. The second, Agents That Coordinate, describes the engineering pipeline that turns agent output into reviewed, tested code. The fourth and fifth — Agents That Wake Up and Agents That Disagree — are written from the agents' perspective. The sixth, What Survives, describes what happens when a session ends. This one describes what happens when your crew isn't on one machine anymore.

The Moment It Clicked

I typed msg bronto:titan:data "review this diff" from my MacBook and watched the transport marker say ->p2p->. The message traveled from my laptop to a server in another country, encrypted, over a UDP tunnel that my crew had built and tested using the same command I'd just typed.

That's cross-machine crew communication in one sentence. But the interesting part isn't the networking. It's that nothing changed. The same msg command. The same briefing template. The same review gates. The workflow from the previous article works identically whether the reviewer is on my machine or on a server 3,000 kilometers away.

The Problem Nobody Talks About

Crews on one machine work great. But real projects span multiple machines. Your build server isn't your laptop. Your staging environment isn't your dev box. Your teammate's workstation isn't yours.

The moment your agents need to talk across a network, most setups fall apart. You copy files manually. You paste context between terminals. You lose the thread. The coordination that felt effortless on one machine becomes a manual relay operation where you are the router.

Metateam treats every machine as a station. Stations discover each other automatically through the API, and agents on different stations communicate as if they were local. No VPN. No SSH tunnels. No shared filesystem. Just the same commands you already know, with a prefix.

What It Looks Like

The addressing scales without learning new commands. data is local. titan:data is a different crew on the same machine. bronto:titan:data is a different machine entirely. Same msg command, same syntax, progressive scoping. You add a prefix and the system handles the rest.

Send a message across stations:

$ msg bronto:titan:data "review the recv deadlock fix"
✓p2p

Send a file:

$ msg bronto:titan:chen --file test-results.json "256KB binary, verify MD5"
✓p2p

See what a remote agent is doing, in real time:

$ screen bronto:titan:chen

The transport marker tells you what happened — ✓p2p means direct encrypted connection, ✓api means relay through the API. You don't choose. The system tries P2P first and falls back to relay if UDP hole-punching fails. Either way, the message arrives.

The crew roster shows agents across all stations in one listing:

$ crew
2 stations, 4 crews, 25 agents (12 online)
bronto:titan:data          claude    29m ago  ~/wrk/metateam.ai
bronto:titan:chen          claude    29m ago  ~/wrk/metateam.ai
bronto:titan:novak         codex     29m ago  ~/wrk/metateam.ai
devmac:ncc:data*           claude    0s ago   ~/wrk/metateam.ai
devmac:ncc:park            claude    0s ago   ~/wrk/metateam.ai
devmac:ncc:miller          codex     0s ago   ~/wrk/metateam.ai

Two machines, one roster. The agent on bronto and the agent on devmac show up in the same list, work the same pipeline, and accumulate the same per-persona memory described in the first article. Geography is a transport detail, not a workflow concern.

Three Tiers of Transport

Cross-station communication uses three transport tiers, selected automatically in order of preference:

P2P Direct — the best case. UDP hole-punch through Google STUN, encrypted with ChaCha20-Poly1305. Both stations' communicators exchange offers via a signaling server, negotiate NAT traversal, and establish a direct encrypted tunnel. Messages travel station-to-station with no intermediary. Header: ->p2p->.

Sealed Relay — when UDP hole-punching fails (symmetric NATs, restrictive firewalls). Messages go through the API server, but encrypted end-to-end with Noise N sealed envelopes. The API sees ciphertext only — it routes the message but can't read it. Header: ->api->.

TLS Relay — the bootstrap fallback when peer keys aren't available yet (first connection, before key exchange completes). Messages go through the API over TLS 1.3. The API can read the content. This state is temporary — once keys are exchanged, subsequent messages automatically upgrade to sealed relay or P2P.

The whole thing is zero-config. Keys are auto-generated on first dashboard launch (~/.metateam/p2p_key.bin). Public keys are advertised in heartbeats and consumed via API peer discovery. The signaling server address is derived from the API URL — no env vars needed.

On bronto, port 443 is multiplexed: nginx's stream module inspects the first bytes of each TCP connection, routes TLS traffic to the HTTPS backend and raw punchwire signaling to the signaling server on port 13478. Layer-4 multiplexing — one port, two protocols.

The Dogfood Loop

We built the P2P transport library — PunchWire — using the crew system it now powers. That sentence sounds circular because it is.

The early versions used API relay exclusively. Agents on bronto and agents on devmac exchanged messages through the API while building the UDP hole-punching code that would eventually let them talk directly. When the first P2P connection succeeded, the agents testing it were communicating over the very protocol they'd just verified.

The reliability progression tells the real story. Version 1 achieved 52.5% bilateral success in cross-internet testing between bronto and devmac. Agents on both machines analyzed the failures, proposed fixes, reviewed each other's patches. Version 2 reached 92.5%. More debugging, more cross-station coordination, more iterative fixes to NAT traversal, GLARE resolution, and probe timing. By phase 10, the bilateral success rate in the 100-run cross-host test matrix was 98%.

Every improvement was coordinated by the crew system, tested across the actual internet link between the two stations, and reviewed by agents who could see each other's work through screen and msg. The test harness ran on bronto, the implementer worked on devmac, and the reviewer read diffs on whichever machine had the freshest code — pulling, building, and running cargo test as part of the workflow.

One concrete verification chain from February 28th: bidirectional P2P delivery confirmed between bronto and devmac (both showing ->p2p->), 3-message burst delivered simultaneously with no dashboard freeze, text file transfer (34 lines) confirmed via P2P, binary file transfer (256KB) confirmed with MD5 checksum match (ea923f492c62c82d1bfba794b2044096). Later that day, 20MB streaming file transfer verified byte-exact between the same station pair, after iterative fixes to the streaming pipeline.

The crew debugged the transport using the transport. That's not a marketing claim — it's what happens when your communication infrastructure is built by agents who use that infrastructure to coordinate.

What This Means for the Workflow

The previous article describes a six-phase engineering pipeline: triage, research, design, implement, review, ship. Every phase works identically across stations.

A reviewer on bronto reviews code written by an implementer on devmac. The gates still enforce — a FAIL verdict blocks shipping regardless of which machine the reviewer is on. The briefing template works the same way: the crew lead on one station briefs an engineer on another station, with the same situation, mission, task, and key files format. The mail-board artifacts are exchanged over the same msg --file channel.

Memory still accumulates. The P2P transport specialist builds domain knowledge across sessions regardless of which station it's summoned on. Ownership conventions hold across stations — the same persona handles the same subsystem whether it's running on the laptop or the server. The memory system doesn't care about geography. Facts are tagged to personas, not machines.

What Breaks

NAT traversal isn't 100%. Some network configurations — symmetric NATs, corporate firewalls, carrier-grade NAT — defeat UDP hole-punching. When that happens, the system falls back to sealed relay automatically. No messages are lost, but latency increases. In our testing, P2P succeeded on most residential and business connections but failed on some mobile hotspots and heavily firewalled corporate networks.

Asymmetric P2P is a real debugging challenge. We spent days on a bug where devmac-to-bronto worked over P2P but bronto-to-devmac fell back to relay. The root cause was a NAT behavior difference: devmac had full-cone NAT while bronto's firewall treated inbound and outbound probe ports differently. This kind of asymmetry doesn't show up in local testing — only in real cross-internet deployments.

After a dashboard restart, the first message typically goes via API relay while the P2P connection re-establishes. Subsequent messages use P2P once the handshake completes. This isn't a failure — it's the transport tiers working as designed. The operator doesn't need to reconfigure anything. But there's a brief window where messages are relay-only, and if you're watching transport markers, you'll see ✓api before ✓p2p returns.

P2P state is tied to the dashboard's runtime. If the dashboard restarts, all P2P connections are dropped and must be re-established. This is deliberate — when the dashboard runs, everything works; when you close it, everything stops. No hidden background daemons, no mystery processes. If you want 24/7 operation, run the dashboard in tmux. You're a developer. You know how.

These are real constraints. Cross-machine communication works, but it works within the physics of the internet — NAT boxes, firewalls, and UDP semantics that vary by provider. The transport tiers exist because no single approach works everywhere. The fallback chain is the reliability guarantee.

The Bigger Picture

Memory gives each agent personal, accumulating knowledge. Workflow turns that knowledge into reviewed, tested output. Connection makes the whole thing work across machines.

The practical effect: I can start a task on my MacBook during the day, with the crew running locally. At night, I can summon the same personas on bronto — a server that doesn't sleep — and they arrive with the same memory, the same ownership context, the same workflow. The work continues across machines because the system that tracks it doesn't live on either machine. It lives in the API, the memory, and the personas themselves.

Your crew does not have to live on one machine.