Every real-time web comparison you've read puts the same three options side by side: long polling, WebSockets, and Server-Sent Events (SSE). The trade-offs are established — latency, overhead, browser support, unidirectional vs bidirectional. But those articles assume a human in a browser tab. When the client is an AI agent — something that crashes, restarts, runs behind NAT, and processes events on its own schedule — the three options look different. The classic three-way comparison doesn't hold up the way most docs present it.
Here's the re-examination for the case that matters to agent builders: your client keeps disappearing, and you don't control the network it runs on.
The classic comparison (and why it's not wrong, just incomplete)
If you've seen one comparison of long polling vs WebSockets vs Server-Sent Events, you know the shape:
| Mechanism | Direction | Latency | Reconnect burden |
|---|---|---|---|
| Long polling | Client pull | High (min RTT) | Client re-polls on error |
| WebSocket | Bidirectional | Low (persistent) | Client must reconnect, server must tolerate gap |
| SSE | Server push | Low (persistent) | Browser auto-reconnects by Last-Event-ID
|
These trade-offs were drawn for a web browser that keeps a stable TCP connection, maintains session state in memory, and has a public IP or at least outbound-only connectivity. An AI agent loop violates every one of those assumptions.
What changes when the client is an agent loop
An autonomous agent doesn't sit in a browser. It runs in a container that gets recycled, a serverless function with a cold-start latency problem, or a machine behind a corporate firewall. Three things break the assumptions:
1. The client restarts — often. Every crash, deployment, or cloud-migration destroys in-memory connection state. There is no "reconnect gracefully" when the previous PID is gone. The new instance must re-establish everything from scratch. Long polling handles this naturally (every poll is a fresh connection anyway), but WebSocket and SSE recovery means the agent carries resume state somewhere persistent — which most agent loops don't do.
2. No public address to listen on. WebSocket and SSE both require the server to push data to a reachable endpoint. If the agent is behind NAT, CGNAT, or a corporate firewall with no open ports, the server cannot initiate a connection. The agent can only connect out. This is the fundamental asymmetry: your agent's environment may make bidirectional push impossible, and long polling is the only option in the classic three that actually works from an outbound-only position.
3. The payloads are JSON, not DOM events. SSE was designed for text streams a browser renders incrementally. Agents process structured JSON — the incremental-stream advantage is wasted when the agent needs to deserialize a complete payload before acting on it. And WebSocket's framing isn't meaningfully better than HTTP response boundaries for the message sizes agents typically handle (a few KB).
Why long polling is actually worse for agents than you think
Long polling works from any network, which makes it tempting. But in an agent loop every empty poll costs compute. The agent wakes up, makes an HTTP request, gets a 200 with no data, and has to decide what to do next. Each decision cycle burns tokens, latency, and context-window budget on a no-op. With real-time server-push options hitting 5–50ms latency, long polling at a 5-second interval introduces a forced 5-second delay on every event — and at a shorter interval, the wasted-poll cost compounds.
Worse: the agent cannot distinguish "no events yet" from "server is gone" without a timeout, which means it adds error-handling branches to a path that should just be "wait for next event."
WebSocket for agents: the reconnection tax
WebSocket gives you low-latency push, but the agent must manage reconnection itself. That means:
- Persistent state somewhere (a file, a DB row, a flag in the agent's mind) to know a WebSocket was expected.
- Re-auth on reconnect. Every new WebSocket upgrade is a fresh authentication handshake. If the auth server is down, the reconnecting agent hangs.
- The server must know where the agent is. WebSocket servers hold per-client connection state. When the agent restarts on a new IP or behind a fresh NAT mapping, the server still holds the old connection stale — and the old mapping is dead. Until the agent reaches the server, the server can't push.
The result: WebSocket works great for agents that never restart and live on a stable network. For the rest, it's a maintenance burden that outweighs the latency advantage.
SSE for agents: the directionality problem
SSE's auto-reconnect via Last-Event-ID is genuinely nice — the browser does it for you. But SSE is server-to-client only. If your agent needs to also send data back (acknowledge a job, update its status), you need a second channel — another HTTP endpoint or a separate POST. Two channels means two stacks to manage, two timeouts, two sets of error states.
It also inherits WebSocket's reachability problem: the server pushes to the agent's endpoint. If that endpoint isn't reachable, SSE doesn't help.
What actually works: a persistent virtual address with tunnel-based push
None of the classic three solve the core problem: the agent's address is ephemeral. Every time it restarts or moves, its IP and NAT mapping change. The server has no way to reach it unless the agent connects first and that connection survives.
The alternative that changes the shape of the problem: give the agent a permanent virtual address that doesn't change when the machine restarts, the container is recycled, or the cloud region switches. The agent runs a small userspace tunnel daemon that maintains an encrypted UDP association to the overlay network. The server pushes messages to that address, not to an IP:port that expires on the next NAT timeout.
Under this model:
- The agent still connects outbound (no open ports needed), but the tunnel stays alive across restarts because the address is tied to a keypair, not a TCP socket.
- The server doesn't track ephemeral connections. It sends to the agent's address; the overlay delivers it.
- The agent receives push without managing a WebSocket state machine or wasting cycles on empty polls.
- Reconnection isn't an event the agent handles — the tunnel daemon handles it transparently, and the address stays the same on the other side.
This is not a browser pattern; it's a networking pattern borrowed from overlay networks and adapted for agent lifetimes. The trade-off is that it requires infrastructure — a tunnel daemon and a registry — that the classic three don't ask for. But if your agent loop already needs reliable messaging, state persistence, and cross-cloud mobility, that infrastructure pays for itself in eliminated polling costs and dropped-connection bugs.
Summary
| Mechanism | Works from agent behind NAT? | Survives agent restart? | Token-efficient (no waste)? |
|---|---|---|---|
| Long polling | Yes | Yes (stateless) | No — every empty poll burns compute |
| WebSocket | No (needs server push target) | No (reconnection logic required) | Yes |
| SSE | No (needs server push target) | Partial (auto-reconnect, but direction-limited) | Yes |
| Tunnel + persistent address | Yes (outbound-only) | Yes (address survives) | Yes |
The classic comparison of long polling vs WebSockets vs Server-Sent Events is correct for browsers. For agent loops, the constraints are different enough that the defaults change. If your agent is always reachable and never restarts, WebSocket is fine. If your agent runs where you can't promise either of those, a persistent virtual address changes the problem from "how do I keep a connection alive" to "how do I receive a message" — and that's a much simpler question.
Pilot Protocol is an open-source overlay network that gives each agent a permanent virtual address with encrypted UDP tunnels and outbound-only NAT traversal — no open ports needed. If you're building an agent loop that needs to receive messages reliably across restarts and network changes, see the docs or grab the daemon:
curl -fsSL https://pilotprotocol.network/install.sh | sh
Top comments (0)