On Durable Objects, Orleans, and prior art for the agentic web

Zak Knill wrote a sharp post this week arguing that LLMs are exposing a gap in our standard cloud-native architecture.

The thesis runs like this. HTTP, load balancers, stateless servers, and a central database work fine for request/response, and they fall over when you want to talk to a long-running, stateful process. Polling becomes the duct tape, and durable execution frameworks like Temporal solve the workflow side, but the interaction itself still routes through the database. The fix is a named pub/sub channel as the missing routing primitive, so clients can address a process by name rather than by server location.

I read it twice and the friction described in the post is real, the kind I see every day in the orchestration layer I work on. Agents running for minutes at a stretch, clients wanting to watch and steer, token streams you really do not want to thread through Postgres. The diagnosis is honest engineering and "address the process, not the server" is a clean way to phrase it.

And here is where I want to push back gently, because the primitive the post claims to be missing has been shipping in production for years. Cloudflare Durable Objects give you a globally addressable, single-instance, durable process keyed by name. Microsoft Orleans has offered virtual actors since 2014, Akka Cluster has location-transparent actor references, and Phoenix Channels in Elixir give you named, reconnectable pub/sub on top of WebSockets and have done since 2015. Temporal itself supports signals, queries and updates addressed to a specific workflow ID, so "HTTP can only route to a database" is too strong as a flat claim.

The streaming case is genuinely harder, and that is where the post's pub/sub argument has more teeth. Temporal queries are point-in-time reads, not subscriptions, so if you want token-by-token output from a long-running workflow you do reach for polling or for an external transport. I think this is the sharper version of the argument made in the post.

What is actually happening here is more interesting than "the primitive is missing". The Node and Python web stack that most teams reach for lacks first-class support for this pattern, and that is the real gap. The pattern exists but the mainstream toolchain lacks it, and those are two different statements that lead to different conclusions.

None of this takes away from the value of the original piece, which surfaces a problem most teams have not named, and naming it is half the work. I just think the next move is to point at the systems that already solved it, ask why they have not become the default, and go from there.

The point I would land on is this. The routing primitive is not missing, it is just not in the default web stack most teams reach for, and the interesting question is why. Operational complexity of stateful boxes? Cost models that punish them? Cultural muscle memory around twelve-factor apps? Lack of vendor pressure until LLMs made the friction obvious? Those are the questions I keep coming back to.