The missing routing primitive isn't missing from tech, it's missing from web developers

May 14, 2026

Zak Knill argues in a recent post that LLMs and agents are breaking the 20-year-old stateless web, and that we're missing a routing primitive to address running processes. The diagnosis is right. The primitive isn't missing from technology, it's missing from the average web developer's toolbox.

HTTP, load balancers, and stateless servers can route to a database, but not to a specific running process. Agents are long-running, stateful, and want bi-directional interaction. So everyone falls back to polling the database, which is just abusing it as a message bus.

Polling is what you do when you can't figure out how to address the thing you want to talk to. It's a work around for a routing problem.

Knill's fix is a named pub/sub channel that both client and process connect to by name. The diagnosis is correct. The framing that the primitive is missing from our tools isn't. It's missing from the people building on top of them.

The tools have been here for decades

Erlang/OTP solved addressable processes, supervision, and message passing in the 1980s. Akka brought the actor model to the JVM. Elixir's Phoenix Channels is literally the pub/sub-by-name pattern, shipped a decade ago. Go gives you goroutines and channels, and exposing internal state over NATS, Redis streams, or a websocket is a weekend's work.

None of this is missing from computing. It's missing from the working knowledge of the median web developer, who has spent a career inside the stateless HTTP plus Postgres stack and never had to reach for anything else. That stack won because it's cheap to scale and easy to hire for, not because the alternatives stopped existing.

Two things, not one

The original post also conflates two concerns that the industry has solved separately for years:

Addressing a running process. Actors solve this. Pick your stack.

Durable, reconnectable transport. Pub/sub with persistence solves this. NATS, Redis streams, RabbitMQ, Kafka, Phoenix Channels, SignalR.

You need both. They exist. Pick one.

What's actually new

LLM workloads make the polling workaround painful enough that the median Node developer now has to care. Non-deterministic, expensive, slow responses don't survive the "just retry" reflex that hid the architecture's limits for years.

That's a cultural shift, not an architectural discovery. The tools have been on the shelf the whole time. The gap is in who knows to walk over and pick them up.