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 communicate directly through encrypted UDP tunnels. The network handles discovery, NAT traversal, and trust -- but application data flows directly between agents, never through a central server.

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

Step 1: Install

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

That is the entire install. One command. No Docker, no Kubernetes, no Terraform. The binary runs on Linux, macOS, and Windows.

Step 2: Connect Agents

# Agent 1: install and start
$ pilotctl init --hostname sensor-1
$ pilotctl daemon start
Registered as sensor-1 (1:0001.0000.0001)

# Agent 2: same network
$ pilotctl init --hostname controller
$ pilotctl daemon start
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.key
Public key: 7a2c...f819 (Ed25519)
Virtual address: 1:0001.0000.0005

$ pilotctl daemon start
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"
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, the answer is "new discovery stops, but everything else keeps working."

• Active connections continue -- agents that have already discovered each other and established tunnels continue communicating. The tunnel is a direct UDP connection between agents. The network is not in the data path.
• Trusted relationships persist -- trust state is stored locally on each agent in ~/.pilot/. It does not depend on the network. If discovery is down, agents can still communicate with all of their previously trusted peers.
• New discovery fails -- agents cannot look up new peers by hostname. This is the only thing that breaks.
• 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 excellent, battle-tested, and widely used. But MQTT brokers are always in the data path -- every message flows through the broker, making it a bottleneck and a single point of failure. Pilot's network handles only discovery; actual communication is peer-to-peer.

MQTT also does not provide NAT traversal. If your devices are behind different NATs, you need a publicly reachable broker (which reintroduces cloud dependency) or a VPN (which reintroduces configuration complexity). Pilot's automatic NAT traversal works behind any NAT type without additional infrastructure. 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 compiles to a static binary for Linux (amd64, arm64, arm), macOS, and Windows. For embedded 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

Step 4: Establish Trust Between Devices

Devices that need to communicate establish trust through the handshake protocol. For fleet deployments, use auto-approval rules to automate this:

# 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 5: Decommission the Cloud Service

Once all devices are communicating over Pilot, disable the cloud service. Your devices are now independent. The communication is peer-to-peer, encrypted end-to-end, and there is no vendor dependency and no risk of service shutdown.

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 your agent network on Pilot Protocol means you own your data and your connections. The software is open source (MIT license). The communication is peer-to-peer. There is no vendor that can shut down your deployment by shutting down their servers.

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.