LLMs are breaking 20-year-old system design

The cloud-native architecture of the last decade rests on a 20-year-old assumption: state lives in the database, compute is stateless. Scale the database vertically, scale application servers horizontally, any request can hit any server. Zknill's argument is that LLM agents quietly violate this in three ways and we don't yet have the right routing primitive to fix it.

The three violations

1. Long-running work — a 10-minute agent task isn't a request, it's an async process.
2. Stateful compute — multi-turn conversations, tool calls, accumulated context. That's the agent's memory, not database state.
3. Bi-directional interaction — the user wants to watch the agent think, interrupt, redirect. That's a conversation with a process, not a query.

Durable execution solves part of it

Temporal, Inngest, Restate make the execution durable and resilient. But the execution layer still pretends stateless underneath. The moment a client needs to talk to a specific running process, HTTP + load balancer + stateless server can't route to it. So everyone falls back on polling.

Polling treats the database as a message bus, which is what people did before message buses existed. It's a workaround for a routing problem: latency tradeoffs in how often to poll, database load, wasted requests, terrible streaming UX. It's not actually solving the problem.

The missing routing primitive

Zknill names it: a routable transport name that isn't a server. You want to say "deliver this message to whoever is producing output for workflow X" without knowing which box, replica, or process. HTTP and load balancers cannot express this.

WebSockets look like a candidate — long-running, bi-directional, transport-level — but they're a connection, not an address. If the WebSocket drops, the "address" is lost. You can't reconnect to the same process because there's no name to route to.

Pub/sub channels invert the ownership

Neither the server nor the client is addressable. The transport is. Both ends connect to the channel by name and get bi-directional, stateful, resumable communication. The channel is durable; if either side disconnects, both reconnect to the same name without losing the ability to route to the same process.

For durable execution, a workflow activity connects to a channel named after the workflow ID. The client connects to the same channel for updates, interrupts, steering messages. No threading data through a database, no polling, no addressing problem for the durable process actually doing the work.

This isn't really about LLMs

LLMs make the problem visible because their responses are non-deterministic and expensive. Before, if a connection dropped, retry was cheap and you'd usually get the same response back. With LLMs you don't want to pay tokens twice because the client went into a train tunnel, and you don't want to thread every token through your database just to be resilient. The stateless web isn't wrong — it's just a bad design for agentic applications.

What the architecture looks like

Three pieces, each doing one job:

• Durable execution for the workflow.
• Pub/sub for the addressable transport.
• Stateless HTTP for everything else.

The piece sits next to agents-vs-daemons (human-initiated vs self-initiated AI), microvm-2026 (the sandboxing layer below the agent), and the Crawshaw piece in agent-principal-agent-problem (which observes the same shift from a code-review angle). Where Crawshaw frames the breakdown as a contributor/reviewer signal problem, zknill frames it as a transport-layer problem. Both are seeing the same thing from different sides.