The Runtime Beneath the Agents

Werner Vogels put the underlying discipline in five words nearly two decades ago, talking about distributed systems at Amazon: "Everything fails, all the time." It's easy to nod along to that as database wisdom and forget it applies equally to the process running your coding agent. Agents crash mid-task. Sandboxes get killed for resource limits. Network calls to a model provider time out. A laptop goes to sleep. None of that is exotic - it's Tuesday. The question a runtime answers is not "how do we prevent failure" but "what happens the instant after it."

The Agent Is a Process, Not a Product

Treat a coding agent as a single long-lived process and you inherit every problem long-lived processes have always had: no persisted state across restarts, no way to tell "still working" from "silently dead," and no isolation between one agent's changes and another's. These aren't new problems. Distributed systems engineering solved versions of them decades ago - the Erlang runtime's supervision trees, built specifically so that a crashed process could be restarted into a known-good state by a supervisor that never itself crashes, are the direct ancestor of what a modern agent runtime needs to do for coding agents today.

The shift worth naming is that this is now happening at the harness level rather than in bespoke framework code. Checkpoint-and-resume, session state that survives a restart, sandboxes with persistent filesystems, isolation boundaries that get hardened as platforms rather than patched per-project - these have been migrating out of individual agent frameworks and into the runtimes underneath them. That migration is the tell. When a capability moves from "something each team builds for itself" to "something the platform provides by default," it has been recognized as infrastructure, not a feature.

Four Jobs, None of Them Glamorous

Strip away the branding and a durable agent runtime is doing four unglamorous jobs:

• Restart recovery - when a process dies mid-task, something else notices, and the agent resumes from its last known state instead of starting over or, worse, silently vanishing
• Scheduling - deciding what runs now, what waits, and how much of the system's capacity a given task is allowed to consume, so twelve agents don't contend for the same resource at once
• Worktree isolation - giving each unit of work its own checkout, its own branch, its own files on disk, so parallel agents can't corrupt each other's changes
• Liveness - a continuous answer to "is this thing actually working," distinct from "is this thing still running a process," because those two questions diverge more often than teams expect

None of these are research problems. They're operations problems, and operations problems are solved by building an operating layer, not by prompting harder. A model that reasons brilliantly about a codebase still needs somewhere to persist that reasoning across a restart it didn't choose.

We've Built This Layer Before

This is a familiar shape in the history of computing: a new kind of workload arrives, gets run directly on whatever's available, and then matures into demanding its own operating layer once the ad hoc version starts failing at scale. Virtual machines got a hypervisor. Containers got an orchestrator. Web services got a process supervisor and a load balancer before anyone called it "infrastructure." Coding agents are running through the same arc, compressed into a couple of years instead of a couple of decades, because the economic pressure to run them unattended arrived immediately rather than gradually.

The Erlang world named the philosophy plainly: "let it crash." Not because crashing is good, but because a system designed to recover cleanly from failure is more robust than one that tries to prevent every failure and inevitably misses one. Coding agent runtimes are converging on the same insight from a different starting point. You cannot build a model good enough to never fail. You can build a runtime good enough that failure is routine, boring, and survivable.

Judging the Runtime, Not the Model Alone

For teams evaluating agentic tooling, this reframes the diligence question. "Which model does it use" is worth two minutes of a conversation that should mostly be spent elsewhere: What happens when a task dies at hour six of an eight-hour run? Can two agents work the same repository without stepping on each other's files? Is there a real distinction between "still running" and "still working," and does anything watch for the difference? Those questions have nothing to do with model intelligence and everything to do with whether the system is safe to leave alone.

The coding model is the part everyone can see and benchmark. The runtime is the part that determines whether you'd trust the model to work while you're not watching. As agentic development moves from supervised pair-programming to genuinely unattended execution, that second question stops being an implementation detail and becomes the whole point.