Agents aren't software. A conversation with Jeff Dean helped me see why. — RUNTA

Start free trial

All Blog 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...