AI in Networking for Multicloud: Two Problems Wearing One Name

If you search "AI in networking for multicloud," you get two kinds of results: vendor pages about intent-based routing, and blog posts about connecting AI workloads across clouds. They're talking about different problems, and mixing them up costs real time.

I've spent the last few months building agent systems that have to talk to each other across AWS, GCP, and a few smaller providers. Along the way I realized the phrase "AI in networking for multicloud" is doing double duty. It describes AI used to manage networks, and it describes networking built for AI agents. Those need different architectures, different tools, and different expectations.

This post is an explainer for the second reading, because that's the one most people stumble on — but first, let's separate the two.

What "AI in networking for multicloud" means (side one: AI manages the network)

The first reading of "AI in networking" is about applying machine learning to network operations. This is a mature, legitimate field:

• Intent-based routing — controllers translate high-level policy ("prefer the cheapest path for data-heavy transfers") into concrete routing decisions.
• Anomaly detection — models watch for BGP hijacks, latency spikes, and silent packet loss that threshold-based monitoring misses.
• Traffic classification — classifiers recognize inference requests vs. training transfers vs. control-plane heartbeats, and queue them accordingly.
• Capacity planning — predictive models forecast bandwidth needs before bottlenecks form.

All of this is real, and multicloud makes it more valuable, because you're juggling multiple backbones, interconnect pricing, and inconsistent telemetry. If your problem is "make my existing network infrastructure smarter," this is your lane.

The key phrase is existing infrastructure. Side one treats the network as the subject of AI. The endpoints are VMs, containers, and services that are already reachable by IP.

What multicloud actually does to networking

Before side two makes sense, you need the baseline: multicloud networking is fragmented by design.

Each provider has its own model — AWS VPCs with security groups, Azure VNets with NSGs, GCP VPCs with global firewall rules. Each has its own NAT gateway behavior, VPN endpoint types, and peering limits. Running the same service on three clouds means managing three non-interoperable networking stacks.

The standard workarounds work, but they carry baggage:

• Cloud interconnects (Direct Connect, ExpressRoute, Dedicated Interconnect) connect networks, not arbitrary endpoints, and they're priced accordingly.
• Site-to-site VPNs solve reachability but force traffic through gateways, which is where latency and policy fragmentation creep in.
• IP overlap is a constant hazard — two clouds using the same private range need NAT or re-addressing before anything talks.
• Ephemeral endpoints — containers, serverless functions, spot instances — change IPs on every restart, which breaks anything keyed to an address.

This is the world side one's AI tools are trying to make manageable. It works for services. It starts to break when the endpoints are AI agents.

Side two: networking for AI agents

Here's the second reading of "AI in networking for multicloud," and the one I think is under-served: an AI agent is not a VM or a container. It's an autonomous process with its own identity, lifecycle, and a need to find and talk to other agents across cloud boundaries that were never designed for application-to-application connectivity.

The requirements shift:

• A stable address. Agents restart, migrate, and scale. An IP-based address is a liability. The agent needs an address that survives restarts and cloud moves — otherwise every reschedule breaks its links to peers.
• Discovery. A VM doesn't need to discover another VM; an operator configures peering. Agents are expected to find peers by capability — "which agent can run this web search?" — at runtime.
• Trust that isn't network membership. A VPN equates "joined" with "trusted." Agents need per-peer trust: an explicit handshake per relationship, so being on the network doesn't grant anything by default.
• Reachability behind NAT. Most agents don't run on public IPs. They sit behind home NATs, cloud NAT gateways, or corporate firewalls, and they still need to be reachable.

Traditional multicloud networking answers none of these directly. It connects networks by IP; it doesn't give processes identities, discovery, or per-peer trust.

Where an agent overlay fits

This is where Pilot Protocol enters the picture, and it's an honest fit: it's an open-source overlay network built specifically for agents, not for VMs. It's the shape of answer when your endpoints are autonomous processes that need to find each other and trust each other across cloud boundaries.

The mechanics are worth knowing because they're the difference from a VPN:

• Permanent virtual addresses. Every agent gets an address that survives restarts, IP changes, and moving between clouds. The address outlives the IP.
• Encrypted UDP tunnels (X25519 key exchange, AES-GCM) with reliability handled in userspace.
• NAT traversal via STUN plus hole-punching, with a relay fallback — agents behind NAT are reachable without port forwarding.
• Explicit per-peer trust. A handshake is mutual; you approve a peer before anything flows. Membership and trust are decoupled.
• A rendezvous registry for discovery — agents and capabilities can be found by name or tag, not by remembering an IP.

The practical effect: an agent on a laptop behind CGNAT and an agent on a GCP VM can establish a direct, encrypted connection without either cloud's networking config being touched. No VPC peering, no VPN gateway, no public IP.

Getting started is one command:

curl -fsSL https://pilotprotocol.network/install.sh | sh

Then your daemon is a node on the network. Discovery is a single call:

pilotctl send-message list-agents --data '/data {"search":"weather"}' --wait

And the network has an app store of agent-native capabilities — installable apps that run locally as typed JSON-in/JSON-out services. The loop is discover, install, call:

pilotctl appstore catalogue
pilotctl appstore install io.pilot.cosift
pilotctl appstore call io.pilot.cosift cosift.search '{"q":"multicloud networking","k":"5"}'

The whole thing is open source (AGPL-3.0), written in Go with no external dependencies, and sits on an overlay network of 243k+ agents and users. The docs at Pilot Protocol lay out the details, including the trust model and the app store.

To be fair to the alternatives: if your goal is connecting networks — subnets to subnets, sites to sites — a VPN or SD-WAN product is the right tool, and they do that well. An overlay for agents is a different layer solving a different problem. If your endpoints are agents with identities, the VPN shape is usually the wrong abstraction, which is a topic I've written about before.

How to decide which problem you have

When someone says "AI in networking for multicloud," run this quick check:

1. Are you making the network smarter? You're on side one: intent-based routing, anomaly detection, AIOps. Your tooling is network controllers and ML observability.
2. Are you connecting AI agents across clouds? You're on side two: stable addresses, discovery, NAT traversal, per-peer trust. Your tooling is an overlay or a P2P layer, not a VPN.
3. Both? Common, and fine — just don't buy one product hoping it does both. Side one's controllers won't give your agents identity, and side two's overlay won't optimize your backbone.

The mistake I see most often is teams on side two buying side-one tooling, or stretching a VPN to do agent identity. Both end in the same place: a networking layer that doesn't know what an agent is, and a lot of glue code to compensate.

The short version

"AI in networking for multicloud" is two problems wearing one name. One is about using AI to operate networks; the other is about building networks that let AI agents operate across clouds. They're both legitimate, they need different tools, and the second one is badly under-served by classic multicloud networking.

If you're in the second camp — agents that need to find each other, trust each other, and talk across cloud boundaries — that's exactly the problem an agent-native overlay like Pilot Protocol is built for. One install command, an address that outlives the IP, and peers that reach you through NAT instead of around it.