Every reliable system I’ve worked on shared one property: the code decided what it would do before it ran. Determinism meant reliability could be designed at write time.
Agents break that property. As models move from generating code before deployment to making decisions inside live systems, parts of the execution path become probabilistic, and infrastructure can no longer rely on many of the defaults it inherited from the last generation of systems.
In a recent conversation, Jeff Dean and I were talking about what happens when models move from assisting developers to participating directly in production execution. His point was that once you start using models as tools inside a system (doing speculative work, evaluating branches, generating pieces of a larger task), the whole thing starts to look like a general graph of computation. And the goals for that graph are the same goals infrastructure has always had: low latency, reliability, scale, cost. But the execution unit has changed, and that changes the nature of the problems you have to solve.
It helped me see what I think the real shift is: the deepest impact of agents on infrastructure is a new execution semantics. Bolting agents onto existing stacks won’t be enough. The execution layer beneath them has to be redesigned.
What I keep seeing
Over the past few months, in conversations with startups, enterprises, and frontier AI labs, the same pattern keeps showing up: AI-generated code has moved past assisting development. In more and more places, it shapes, and sometimes dominates, the production process itself. Some teams already use one model to review code written by another. More testing is being handed over to agents. More implementation is being delegated by default.
If you’ve spent years in infrastructure, this should make you uneasy.
At Cloudflare and Kong, most of my work was about keeping systems stable at scale. The attitude toward change management was almost instinctively conservative. I remember a production incident at Cloudflare where a seemingly trivial config change cascaded into a partial outage across multiple data centers. After that, even one-line changes went through multiple rounds of risk review. You learn, painfully, that the thing that breaks production is almost never the thing you were watching.
People who have operated large systems for long enough develop a kind of professional suspicion toward system boundaries. What breaks is usually not the main path but the edge condition nobody modeled carefully, the interface between two systems that each side assumed the other understood, or the default assumption that quietly stopped being true. Every system I built stood at the front door of an application, and could afford to, because the decisions inside were settled before anything ran.
I’ve become almost stubborn about one belief: if a system contains invisible intermediate state, unauditable side effects, or retries with ambiguous semantics, I assume it will eventually fail. And once the executor itself becomes probabilistic, many of the assumptions modern infrastructure was built on come under real pressure.
Reliability may require heavier mechanisms
If the execution unit itself is no longer stable, high reliability can no longer inherit the default tradeoffs of the human-written-code era.
One practical response is redundancy. When generation quality is still unstable, brute-force approaches may turn out to be the most realistic: independent models implementing the same logic, multiple execution paths evaluated side by side, voting across outputs, stronger validation before effects are committed. These are expensive, and they feel like overkill by the standards of the deterministic software era. But if the underlying execution substrate has become probabilistic, some of the old efficiency assumptions no longer hold, and heavy hammers may be what we’ve got.
Over time, the center of gravity for engineering will likely move upward. Less effort spent hand-authoring every implementation detail, more effort spent designing constraints, validators, commit boundaries, and recovery paths.
Computation graphs and resumability
Once models move inside the system, rather than sitting on the edge as one-shot APIs, the shape of the system changes.
A main program calling a model turns into a network of models, tools, filters, evaluators, branches, and fallback paths: a computation graph whose nodes happen to include probabilistic components.
There’s a distinction Jeff made in our conversation that I keep coming back to. ML researchers tend to like synchronous training: the whole system finishes a step, all behavior aligns, then the next step begins. What they actually want, he argued, is not synchrony itself but reproducibility. Synchrony is just one expensive way to get there.
He grounded this in how Google’s training systems evolved: from early asynchronous training that was messy but scaled, to synchronous architectures adopted for the sake of reproducibility. The way I understood his point was that the useful state was not packet-level network state, but causal order at the level of the ML computation itself: which nodes participated in the same all-reduce, how steps were aligned. That state is small, but it’s enough to bring the system back to a well-defined computational state.
This matters deeply for agent systems, because resumability and reproducibility are trying to solve adjacent versions of the same problem: can a system return to a well-defined state and continue forward without losing semantic continuity? If an agent has been running for eight hours and fails in hour eight, can it return to a prior checkpoint and branch from there? Can a human intervene, edit a part of its state, and let it continue? If the answer is no, you can demo autonomy, but you can’t actually support it.
The missing runtime
Much of the mainstream agent stack still feels like a patchwork: a workflow engine with a little memory, tool calling with a little retry logic, checkpointing with a little snapshotting, and the hope that these pieces will somehow add up to a reliable runtime.
This misses the deeper issue. An agent forms intermediate judgments, consumes and mutates external state over time, and leaves the world changed as it acts. When it fails, restarting the process recovers almost nothing. It needs semantic recovery: a return to a meaningful prior state, not just a prior process image.
What replaces the deterministic-era abstractions is a question the industry hasn’t settled. It may end up looking like transaction semantics from databases, workflow recovery from distributed systems, or a genuinely new runtime abstraction.
The unit of fault tolerance has to move from the process to the semantic state of execution.
Semantic scratch space
To make “semantic state” concrete, an analogy from day-to-day engineering might help.
Imagine you are debugging a complex system. Most of the state on your machine is disposable: terminal output, commands you can re-run, notes in an editor, browser tabs. Walk away for an hour and all of it can be reconstructed.
What you might not get back is what you actually knew: which constraints you had verified, which hypotheses you had ruled out, what you were about to try next. Losing partially formed intent is expensive.
Agents face a very similar problem. A long-running agent accumulates a great deal of state. Some of it is genuinely important: it reflects judgments the agent has already formed. But much of it is just scrap from the process of getting there. Snapshot the whole process and it looks like nothing can be lost. Mostly what you’ve saved is noise.
I find the idea of a semantically meaningful working set much more compelling than a blind memory dump. Something like a scratchpad of keys and values, a low-level primitive the agent itself can learn to use. If the agent explicitly writes something into a state store, that act itself is meaningful. It’s saying: this matters, preserve this, I may need to return to it. The checkpointed state becomes smaller, and structurally more useful.
Behind this is an old systems principle that becomes newly important: preserve root state, and avoid persisting derived state when it can be safely recomputed.
Infinite context is not the real answer
There’s a lot of excitement right now around longer context windows. Millions of tokens, perhaps much more over time. That matters. But a bigger window doesn’t tell the system what to keep, what to fetch on demand, or what is just noise; it only makes the mess bigger.
I increasingly think of memory as a reentrant state model, not an infinitely expanding prompt. It should distinguish durable judgments from temporary traces, and make it possible to stop, re-enter, fork, and resume without collapsing continuity. What matters about memory is less how much it can hold than whether the system knows how to organize what it has.
What I believe
Traditional VMs and containers are good at isolating resources. But they don’t understand an agent’s execution progress, the meaning of its state, or the boundaries of its side effects.
What agent-native software needs is a runtime that can place state, side effects, and execution intent into the same recovery model. I think this is becoming one of the central systems problems in agent infrastructure.
It’s also the reason we started building Runta. Runta is our attempt to explore one part of that answer: how to make long-running agent execution resumable, inspectable, and recoverable without forcing every framework to rebuild those mechanisms itself.
The last generation of infrastructure virtualized machines. The next may need to virtualize execution itself. Those capabilities should sit below the application boundary, not be reimplemented badly by every agent framework on top.
For all the tooling that has appeared around agents, one basic question still has no agreed answer: when a long-running agent with real permissions and real external side effects crashes, what exactly does recovery mean?