Every time an AI agent restarts, it loses its address. Spin it up on a different cloud — different address. Move it behind a NAT, put it on a Kubernetes pod that reschedules — different address each time. That's not a minor inconvenience, it's a structural problem for any agent that needs to talk to another agent.
DNS usually fixes this for web services. But an agent isn't a web service. An agent is a peer — it initiates conversations and accepts them, sends messages while offline and retrieves them later, moves between environments without re-registering with everyone it knows. A container IP or a DNS name attached to a specific host won't give you that.
The three things an agent address has to survive
Restarts. When an agent goes down and comes back up, everything that knew how to reach it should still work. With a container IP, you lose this. Docker gives the container a new IP on every restart unless you pin it (and even then, the subnet can shift). DNS records get updated eventually — if you have a TTL under 60 seconds and a dynamic DNS agent on the box — but by the time the A record propagates, any peer that tried to reconnect got a timeout.
IP changes. An agent shouldn't be tied to a single IP address. Developers build agents on laptops, test them on staging VMs, and deploy to production clusters — three different networks, three different IPs. Every environment change means every peer has to be re-notified of the new address, which means either a central registry phone-home or manual reconfiguration. Neither scales when you have dozens of agents.
Moving between clouds. This is the one that keeps infrastructure engineers up at night. An agent that starts on AWS and moves to GCP or Hetzner needs to bring its identity with it. A DNS name on some-agent.mycompany.com stops working when the new cloud provider's subnet doesn't match the DNS team's last update. And if you're running agents across multiple clouds for redundancy, a static IP per agent is expensive and brittle.
DNS works for web apps, not for agents
DNS is the obvious first answer. It's how every web service solves the addressing problem. A service gets a hostname, clients look it up, done. But DNS assumes the addressable thing is a server that stays up and accepts connections.
An agent is different:
- It might be behind NAT (your laptop, a home server, a corporate VPN) — DNS can't help because there's no publicly reachable address to put in the record.
- It might be ephemeral — agents created for a single task and destroyed when done.
- It needs to send messages that arrive even if the agent was offline when sent.
- It needs to establish trust with peers directly, not through DNS as an intermediary.
DNS was designed for a world where servers sit in datacenters with stable IPs. Agents live on laptops, edge devices, containers, and serverless runtimes — none of which fit that model.
What the container crowd gets wrong
"Put it in a pod with a Service and a ClusterIP" sounds like a solution until your agent needs to talk to an agent outside the cluster. Then you're solving NAT traversal, DNS resolution across clusters, and mTLS certificate management — you've reimplemented a full mesh networking layer by accident.
I've seen teams build elaborate setups with Consul or etcd for service discovery, Linkerd for mTLS, nginx ingress controllers for external access, and a custom keepalive system for state sharing. That's four separate tools doing what a single addressing layer should handle. And it still breaks when an agent moves between clusters.
What a permanent address actually looks like
A permanent address for an agent has three properties:
It doesn't change. The address survives restarts, IP changes, and cloud migrations. It's a stable handle other agents use to reach it, regardless of where the agent is running at any given moment.
It's reachable from anywhere. Behind NAT, on a cloud VM, running on a laptop on a train — other agents can still deliver messages to it. The addressing layer handles the network traversal, not the agent.
It carries identity. The address isn't just a locator — it's bound to the agent's cryptographic key. Trust is built into the addressing, not bolted on with a separate certificate authority.
This is the shape of a virtual address. An agent registers once, gets a stable identifier, and can move across any network — the transport layer follows it. Other agents don't need to know where it is right now; they just send to the address and the network figures out the delivery.
Why this matters today
Single-agent projects don't hit this wall. You run one agent, it talks to an API, nobody cares about its address. The moment you have two agents that need to talk to each other — or an agent that needs to hand off work to another — you need a stable way to reach them.
That's where multi-agent systems stall. I've seen otherwise well-designed agent architectures fall apart because the networking layer wasn't thought through. Teams end up bolting on webhook endpoints, polling databases for new messages, or routing everything through a central relay that becomes a bottleneck and a single point of failure.
A permanent address for each agent turns this into a solved problem. Agents discover each other once, exchange addresses, and communicate directly — no polling, no central relay, no DNS TTL race conditions.
A practical test
Next time you're designing a multi-agent system, ask one question: if an agent restarts on a different machine at a different IP, do all its peers still know how to reach it?
If the answer involves "we update a config file" or "we have a health check that propagates" or "the orchestration layer handles it," you haven't solved the addressing problem. You've just moved it around.
The best outcome is an address that outlives the machine, the cloud provider, and the deployment model. Not pinned, not re-registered on every boot — permanent.
Pilot Protocol is an open-source overlay network that gives AI agents permanent virtual addresses and encrypted peer-to-peer communication — no DNS, no static IPs, no central relay. Docs →
Top comments (0)