Keep an Agent Reachable When Its IP Changes: What Has to Be True for the Address to Outlive the IP

Your agent was reachable yesterday. Last night the DHCP lease expired, the container got rescheduled, or the cloud silently reassigned the public IP — and now every hardcoded endpoint, every webhook URL, every config that pointed at it points at a machine that no longer exists. This is the most common way I've seen agent fleets go dark, and it's never the agent's fault. It's the addressing model.

The fix isn't a better way to track the IP. It's to stop treating the IP as the agent's identity. Here's what actually has to be true to keep an agent reachable when its IP changes.

Why Your Agent's Address Shouldn't Be Its IP

An IP address describes where a machine is attached to the network. It says nothing about what the machine is. The distinction matters because everything about the modern deployment model exists to make "where" unstable:

• Laptops sleep. When they wake on a new network, DHCP hands them a new address.
• Containers get rescheduled. A new pod is a new network namespace, often a new IP.
• Clouds reassign. Spot instances die, elastic IPs get detached, regions move.
• CGNAT and carrier networks mean the address you see isn't even the address anyone can reach.

If an agent's address is its IP, then the agent is unreachable whenever the IP changes — which is to say, eventually, always. The address and the IP have to be two different things.

Keeping an Agent Reachable When Its IP Changes

For an agent to stay reachable through IP churn, four properties have to hold. I've found it useful to check a solution against all four, not just the first one:

1. Identity is separate from location. The address other agents use to find you must not change when your IP changes. It's a name or an ID, not a number assigned by a router.
2. The mapping updates itself. When the IP changes, the agent has to be able to announce its new location to some registry or nameserver automatically. If a human has to edit a config or a DNS record, the agent is down until the human wakes up.
3. Reachability doesn't depend on a public IP. Behind NAT — home networks, office firewalls, cloud egress — there's no inbound path at all. Hole-punching and relay fallback are what make an address reachable from anywhere, not just from the datacenter where the agent was born.
4. The transport survives address churn. TCP dies the moment the endpoint IP changes mid-connection; the socket is gone. A UDP-based transport with reliability implemented in userspace keeps sessions alive across address changes, because the "connection" is a property of the overlay, not of a kernel socket pinned to an IP.

Most "keep it reachable" advice stops at property 1. That's how you get a system that works until the network actually changes.

The Options, Honestly Compared

There are three honest ways to give an agent an address that outlives its IP. They're not interchangeable — they're aimed at different problems.

Dynamic DNS. You run a client that updates a DNS record when your IP changes. It's simple, and it genuinely works for a server with a public IP and a stable hostname. But it fails properties 3 and 4: behind NAT there's nothing to point the record at, and DNS is a cache of a mapping — TTLs, resolver caches, and propagation delays mean peers can keep resolving the old address long after the change. DDNS is fine for a blog. It's fragile for an agent that must be reachable now.

Overlay VPNs (Tailscale, ZeroTier). These do identity properly and their NAT traversal is genuinely good — a machine keeps its name across network changes, and that's a real solution to the same problem. They're aimed at machines and human VPN use: you join a tailnet, you get an address, you connect. They do what they do well.

Agent-native overlays like Pilot Protocol. This is the one I'd slot in when the thing that needs to stay reachable is an agent, not a laptop. Pilot Protocol gives every agent a permanent virtual address that survives restarts, IP changes, and moves across clouds. The daemon keeps the registry informed of where the agent currently is, so peers resolve the same address to the current location. Transport is encrypted UDP tunnels (X25519 key exchange plus AES-GCM) with userspace reliability, and NAT traversal is STUN plus hole-punching with a relay fallback, so an agent behind a home router is as reachable as one in a cloud VPC. It's open source (Go, standard library only), and there are 243k+ agents and users on the network today.

The honest framing: DDNS is right when you just need a hostname for a public-IP server. Overlay VPNs are right for human and machine VPN access. Pilot is built for the case where other agents need to find and reach your agent, on any network, without you touching DNS or opening ports.

What It Looks Like in Practice

Concretely, "the address outlives the IP" means the parts you used to babysit just stop being your problem:

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

The daemon registers once and the agent gets its address. When the network changes — laptop wakes up, container reschedules, cloud reassigns — the daemon re-announces the new location to the rendezvous registry. Nothing else changes:

pilotctl set-hostname order-processor        # once
# ...days later, on a different network, different IP...
pilotctl send-message order-processor --data 'status?'

That second command works from anywhere, because order-processor was never the IP. There's no DNS record to update, no static IP to buy, no port forwarding to reconfigure. The address is a name the network resolves to wherever the agent currently is — that's the entire design.

The Takeaway

An agent stays reachable when its IP changes only if you design for it: decouple identity from location, let the network re-announce instead of requiring humans, make reachability work without a public IP, and pick a transport that doesn't pin itself to one address. Check any "keep it reachable" solution against those four properties and the failure modes become obvious before they bite you, not after.

If you're building agents that need to be found by other agents, the docs on how Pilot Protocol handles agent addressing walk through the registry, the address model, and the NAT traversal in more detail. The install line above gets you a node in about a minute — and the address you get will still be there after the next IP change.