Antigravity Swarms
Architecture Pattern 1 WebRTC Mesh Flag-Gated in Production

Method 1: Native Cloud Relay & WebRTC Mesh Architecture

How Google Antigravity's internal remote control daemon, signaling channel, and WebRTC engine function under the hood, and why production swarms currently default to central WebChannel streaming.

1. Deep Disassembly & Internal Protocol Findings

Inspection of the Antigravity CLI binary (~/.local/bin/agy) reveals that Google engineered a dual-mode communication engine inside google3/third_party/jetski/language_server/remotecontrol/.

flowchart TD subgraph CentralBroker ["Google Central Cloud Plane"] PA["Cloud Code PA (Auth & Token Exchange)"] WC["jetski-webchannel.googleapis.com:443\n(Chunked XMLHTTP Streaming Relay)"] Sig["Signaling Broker\nApiService/InitiateMeshSession\nApiService/SendSignalingMessage"] end subgraph NodeA ["Host A: dell5040 (Remote Daemon)"] AGY1["agy --remote-control\n(server.go / remote_control_v2.go)"] MD1["MeshDaemon (P2P SCTP DataChannel)"] end subgraph NodeB ["Host B: Cloud GPU Worker"] AGY2["agy --remote-control\n(server.go / remote_control_v2.go)"] MD2["MeshDaemon (P2P SCTP DataChannel)"] end AGY1 -- "1. Outbound HTTPS:443" --> WC AGY2 -- "1. Outbound HTTPS:443" --> WC AGY1 -. "2. InitiateMeshSession Handshake" .-> Sig Sig -. "3. ICE Candidate Exchange" .-> AGY2 MD1 -. "WebRTC Direct DataChannel (DTLS-SRTP)\n[Currently Disabled by Mendel Feature Flag]" .- MD2 WC ==> "Active Production Traffic:\nWebChannel XMLHTTP Long-Poll Relay" ==> AGY2
The Mendel Flag Constraint: Binary log disassembly shows the exact runtime log message: [remote-control-v2] WebRTC P2P mesh disabled by flag; using WebChannel transport only. While the full P2P WebRTC stack is compiled into the binary, Google's backend dynamically disables peer-to-peer data channels via server-driven Mendel flags during the initial OAuth handshake.

2. Protocol Stack Components

Subsystem Symbol / File Protocol & Role Status
Relay Transport remote_control_v2.go Outbound HTTPS (port 443) to jetski-webchannel.googleapis.com using chunked XMLHTTP streaming. Active
P2P Mesh Daemon remotecontrol.MeshDaemon Negotiates direct WebRTC peer connections using DTLS-SRTP, SCTP data channels, and ICE candidates. Flag-Gated
Signaling API ApiService/InitiateMeshSession Exchanges public keys, ECDSA P-256 signatures, and STUN/TURN server allocations for peer pairing. Compiled
Command Proxying ApiService/ProxyCommand Envelopes CLI commands, terminal streams, and agent turns destined for remote host UUIDs. Active via Cloud
Daemon Manager run_agy_remote_control.sh Probes local ports 4400-4500 and launches agy --remote-control --hub-port <port>. Active

3. Step-by-Step Daemon Configuration (Linux / Debian)

To run Antigravity Remote Control as a resilient system service on a host (e.g. dell5040):

Step 1: Install the Daemon Launcher

# Run the official daemon installer
curl -fsSL https://antigravity.google/cli/agy-daemon.sh | bash -s -- install --name dell5040

Step 2: Authenticate Remote Access

The daemon requires a valid OAuth token stored at ~/.gemini/antigravity-cli/antigravity-oauth-token. Follow the browser link printed by the CLI to authenticate with your Google developer account.

Step 3: Enable Session Lingering

# Ensure systemd user services continue running after SSH logout
loginctl enable-linger $USER

Step 4: Verify Systemd User Service

systemctl --user status agy-remote-control.service
tail -f ~/.antigravity/agy_daemon.log

4. Detailed Engineering Assessment

Advantages

  • Zero Port Forwarding: Outbound HTTPS (:443) bypasses restrictive corporate NATs and CGNAT seamlessly.
  • Built-in Authentication: Inherits Google Identity OAuth security; no need to manage custom TLS certificates.
  • Web Cockpit Included: Access and steer all machines directly from antigravity.google.

Limitations

  • No Direct Peer-to-Peer: Since WebRTC mesh is flag-gated off, all traffic incurs 100-300ms cloud round-trip latency.
  • No Autonomous Agent-to-Agent Triggers: Remote control was engineered for human-to-agent steering, not autonomous agent-to-agent IPC.
  • Stream Timeouts: Long-polling streams automatically reset every 1–14 hours, requiring re-handshakes.
← Back to Overview Next: Method 2 (AgentAPI & SDK) →