Run an Agent Network Without Cloud Dependency

"What happens to my devices if the cloud service shuts down?" This question used to be hypothetical. It is not anymore.

In April 2022, Insteon -- one of the largest smart home platforms in the United States -- went dark overnight. The company ceased operations without warning. Their cloud servers went offline. Every Insteon hub, switch, dimmer, and sensor stopped responding. Customers who had spent thousands of dollars building their smart homes woke up to expensive paperweights. There was no migration path, no export tool, no local fallback. The devices were physically functional but digitally dead, because every command routed through servers that no longer existed.

Insteon was not an outlier. It was a preview.

In August 2023, Google shut down Cloud IoT Core, its managed service for connecting and managing IoT devices. Millions of devices that depended on Google's MQTT broker for communication needed to be migrated to alternative platforms. Google gave 18 months of notice, which was generous compared to Insteon's zero, but the migration was still painful: new SDKs, new authentication flows, new billing accounts, new terms of service.

In January 2026, Belkin announced the end-of-life for Wemo's cloud services. Every Wemo smart plug, switch, and camera that relied on the Wemo app for remote access lost that capability. Local control still works for some devices, but only if you are on the same Wi-Fi network. Remote access -- the entire point of a "smart" device -- is gone.

The pattern is clear: cloud-dependent devices are rented, not owned. The vendor controls the infrastructure your devices depend on, and the vendor can take it away at any time, for any reason.

Why Cloud Dependency Is a Design Flaw, Not a Feature

Cloud dependency is not inherent to networked devices. It is a design choice -- and it is the wrong one for most deployments. Here is why.

Single Point of Failure

When every device communicates through a cloud service, that service is a single point of failure for your entire fleet. If the cloud has an outage, all of your devices stop working simultaneously. AWS has had multiple multi-hour outages affecting us-east-1. Google Cloud had a global networking outage in 2023. Azure had a 14-hour authentication outage in 2025. During each of these events, millions of IoT devices became unresponsive -- not because the devices had problems, but because the cloud they depended on did.

Latency for Local Communication

Two devices in the same room should not need to communicate through a data center on another continent. But in cloud-dependent architectures, they do. A temperature sensor sends a reading to the cloud, the cloud processes a rule, the cloud sends a command to the thermostat, and the thermostat adjusts. Round-trip: 200-500ms. The same operation over a local connection: 2ms.

This is not just a performance issue. For safety-critical applications -- industrial control, medical devices, autonomous vehicles -- the latency introduced by cloud round-trips can be dangerous. An emergency stop command that takes 500ms because it routes through AWS is 498ms too slow.

Privacy and Data Sovereignty

Cloud-dependent devices send all of their data to the vendor's servers. Every sensor reading, every camera frame, every voice command, every usage pattern flows through infrastructure you do not control. The vendor's privacy policy governs your data, not your own policies. If the vendor is acquired, if they change their terms of service, or if they receive a legal request from a jurisdiction you have never heard of, your data is exposed.

For businesses operating under GDPR, HIPAA, or industry-specific regulations, cloud dependency creates a compliance burden. You need to audit the vendor's data handling practices, sign data processing agreements, and monitor their compliance continuously. Peer-to-peer communication eliminates this entire category of risk.

The Account Tax

Cloud-dependent devices require cloud accounts. Each vendor wants you to create an account, verify your email, accept terms of service, provide payment information, and configure authentication. As one frustrated home automation user put it: "30 minutes logging into somebody else's website per device."

For a home with 20 smart devices from 5 vendors, that is 5 accounts to create, 5 apps to install, 5 password resets when you forget them, and 5 separate interfaces to manage your own devices. This is not a user experience problem. It is an ownership problem. You bought the hardware, but the software belongs to someone else.

Getting Started With Pilot Protocol

Pilot Protocol is a peer-to-peer overlay network. Agents prefer direct encrypted UDP tunnels; the network handles discovery, NAT traversal, and trust, with encrypted relay fallback when a direct path cannot be established.

Here is how to get started. This takes approximately five minutes.

Step 1: Install

# Install Pilot Protocol
curl -fsSL https://pilotprotocol.network/install.sh | sh

That is the entire install. One command. No Docker, Kubernetes, or Terraform. Prebuilt packages currently target supported Linux and macOS environments; see Compatibility for the current matrix.

Step 2: Connect Agents

# Agent 1: install and start
$ pilotctl init --hostname sensor-1
$ pilotctl daemon start --email sensor-1@example.com
Registered as sensor-1 (1:0001.0000.0001)

# Agent 2: same network
$ pilotctl init --hostname controller
$ pilotctl daemon start --email controller@example.com
Registered as controller (1:0001.0000.0002)

# Agents can now discover and connect to each other
$ pilotctl find sensor-1
sensor-1  1:0001.0000.0001  public  192.168.1.50:4000

No accounts. No API keys. No terms of service. Agents register on the network, discover each other, and communicate directly through encrypted tunnels.

Agent Enrollment Without Third-Party Accounts

In cloud-dependent systems, enrolling a new device means creating a vendor account, registering the device serial number, generating API credentials, and configuring the device with those credentials. In Pilot Protocol, enrollment is a single command.

# New agent enrollment -- no accounts, no credentials to manage
$ pilotctl init --hostname new-sensor
Identity created: ~/.pilot/identity.json
Public key: 7a2c...f819 (Ed25519)
Virtual address: 1:0001.0000.0005

$ pilotctl daemon start --email new-sensor@example.com
Registered as new-sensor (1:0001.0000.0005)

The agent generates its own Ed25519 key pair locally. No certificate authority, no credential server, no enrollment API. The private key never leaves the device. The public key is registered on the network alongside the agent's virtual address.

Authentication is cryptographic: the agent proves its identity by signing messages with its private key. Other agents verify the signature with the registered public key. There is no password to rotate, no token to refresh, and no OAuth flow to debug.

For fleet provisioning, you can script the enrollment process:

# Provision 50 sensors from a deployment script
for i in $(seq 1 50); do
  ssh sensor-$i "pilotctl init --hostname sensor-$i && \
    pilotctl daemon start --email sensor-\$i@example.com"
done

Each sensor gets its own cryptographic identity, its own virtual address, and its own hostname. No shared credentials, no master key, no single secret that compromises the entire fleet if leaked.

What Happens When the Network Has an Outage

This is the question that exposes the critical difference between cloud-dependent and peer-to-peer architectures: what breaks when the discovery service is unavailable?

In a cloud-dependent system, the answer is "everything." Devices cannot authenticate, cannot discover peers, cannot send commands, and cannot receive updates. The entire deployment is dead.

In Pilot Protocol, established direct paths can continue, while new discovery, new NAT coordination, and relayed paths depend on the configured registry and beacon.

• Established direct paths can continue -- agents with a working direct UDP path can keep communicating while the coordination service is unavailable. Relayed connections do not have this independence.
• Trusted relationships persist -- trust state is stored locally on each agent in ~/.pilot/. That relationship survives an outage, although reconnecting may still require endpoint resolution or NAT coordination.
• New discovery fails -- agents cannot look up new peers by hostname until the configured registry recovers.
• NAT traversal degrades -- new connections behind NAT may not be established until the network recovers. Existing connections continue working because the NAT mappings are maintained by keepalive probes.
• Recovery is automatic -- when the network recovers, agents reconnect and re-register automatically. No manual intervention required.

Compare this to what happened when Insteon's cloud went down: devices could not execute local automation rules, could not be controlled via the app, and could not even be reset to work with a different platform. The cloud was not just the discovery layer -- it was the control plane, the data plane, and the authentication layer, all in one.

Comparison: Pilot vs. MQTT Broker vs. Cloud IoT Platforms

MQTT is a strong alternative for IoT deployments. Mosquitto is mature and widely used, but MQTT brokers remain in the data path for every message. Pilot separates coordination from direct traffic where possible and uses its beacon as a ciphertext relay when a direct path cannot be established.

MQTT also does not provide peer-to-peer NAT traversal. If devices are behind different NATs, you typically use a reachable broker or a separate network layer. Pilot attempts STUN-assisted hole-punching and falls back to its relay when a direct path is unavailable. For the technical details, see Connect AI Agents Behind NAT Without a VPN.

Migration Guide: Cloud-Dependent to Cloud-Independent

If you are currently running devices on a cloud IoT platform and want to migrate to Pilot Protocol, here is the process.

Step 1: Install Pilot on Each Device

Pilot publishes static binaries for supported Linux and macOS targets. For supported embedded Linux devices, cross-compile from your development machine:

# Cross-compile for ARM (Raspberry Pi, IoT devices)
$ GOOS=linux GOARCH=arm64 go build -o pilotctl ./cmd/pilotctl
$ scp pilotctl sensor-device:/usr/local/bin/

Step 2: Initialize and Connect Each Device

# On each device
$ pilotctl init --hostname device-name
$ pilotctl daemon start --email device@example.com

Step 3: Establish Trust Between Devices

Devices that need to communicate establish trust through the handshake protocol. For fleet deployments, script the handshakes (or enable the daemon's -trust-auto-approve flag in a trusted environment):

# On the controller: auto-approve devices on the same network
$ pilotctl handshake sensor-1 "Fleet enrollment"
$ pilotctl handshake sensor-2 "Fleet enrollment"

# Or script it for the entire fleet
for sensor in $(pilotctl --json peers --search "sensor" | jq -r '.[].hostname'); do
  pilotctl handshake "$sensor" "Automated fleet enrollment"
done

Step 4: Decommission the Cloud Service

Once all devices are communicating over Pilot, you can retire the previous cloud path after validating direct, relay, and recovery behavior. Pilot encrypts tunnel traffic end to end and prefers direct paths. A registry and beacon are still needed for discovery, NAT coordination, and relay fallback; self-host those services when third-party independence is a requirement.

The Ownership Principle

The devices you buy should work for as long as the hardware functions. Not for as long as the vendor stays in business. Not for as long as the vendor's cloud service runs. Not for as long as the vendor's terms of service allow.

Running Pilot Protocol with a self-hosted registry and beacon reduces reliance on a third-party service. The software is open source (AGPL-3.0), direct paths are preferred, and encrypted relay fallback remains available when network conditions require it.

Insteon's customers learned this lesson the hard way. Wemo's customers are learning it now. The next cloud shutdown -- and there will be a next one -- does not have to affect you.

For a complete deployment guide with trust policies and fleet management, see Building a Private Agent Network for Your Company. For the security model, see How to Secure AI Agent Communication With Zero Trust. For a step-by-step quickstart, see Build a Multi-Agent Network in 5 Minutes.