Agent Runtime — The Execution Layer Nobody Is Building

What the runtime includes

The agent runtime is the union of six components:

Compute substrate — container, microVM, or full VM
Filesystem with snapshot and rollback semantics
Tools — shell, code interpreter, browser, MCP servers — exposed as callable interfaces
Network boundary defining reachability
State model governing persistence across turns, episodes, and users
Lifecycle controller handling start, suspend, snapshot, resume, teardown

This maps to the H (harness) and S (state) components in the RL environments taxonomy. In production, the runtime determines latency, isolation, and security posture.

Why it matters

The agent is not the model. The agent is the harness plus the model, running inside the runtime. Sculley et al. showed in 2015 that ML model code is the smallest box in a real ML system. The same pattern holds for agents: the model call is the small box, the runtime is the large one driving spend and shaping architecture.

Teams that pick a runtime as a quick integration decision at prototype time accumulate runtime debt — the agent’s behavior entangles with that runtime’s quirks. A year later, switching runtimes becomes a six-month migration because nobody can predict which behaviors will break.

The experimentation/production split compounds this. Training rollouts want 200ms cold starts, thirty-second lifetimes, and frozen-world snapshots. Production sessions want two-second starts, forty-minute lifetimes, live internet access, and persistence across async gaps (CI waits, review cycles, multi-day workflows). Optimizing the same runtime for both produces something too slow for training and too brittle for production.

Source: Hidden Technical Debt of AI Systems: Agent Runtime — Lee Hanchung, April 2026

2026-09 Update — A Candidate Primitive for the Filesystem Component

The six-component list above names “filesystem with snapshot and rollback semantics” without a candidate primitive behind it. AWS S3 Files is the first one worth naming.

What it does: mounts any S3 bucket as a native NFS filesystem on a container or Lambda, at roughly 1ms latency, with EFS underneath. Data stays durable in S3 with automatic bidirectional sync.

Why it matters for the runtime specifically:

It collapses the object/file split. Agents currently copy data into a sandbox, work on it, and copy results out. Each copy is a step that can fail, a cost, and a window where the sandbox holds the only current version. Mounting removes the bridge between object and file abstractions entirely.
Long-term and short-term storage become the same thing. The state model component stops needing a separate persistence path for anything that outlives a session.
Multiple agents can share one mount, with close-to-open consistency — a defined and checkable guarantee rather than an undefined free-for-all. That matters for the agent-teams pattern, where several agents work the same task list against shared files.
Bootstrap and teardown get cheap. The lifecycle controller’s start and teardown steps stop involving a data transfer, which is where most of their latency lives.

Snapshot and rollback are still not addressed by this. Close-to-open consistency across concurrent mounts is a coordination guarantee, not a versioning one, and the note’s original requirement was a filesystem you can roll back after an agent does something wrong.

Source is a single X post reading the AWS launch, not AWS documentation. The 1ms figure and the consistency claim are as stated there and should be checked against the service documentation before anything is designed on them.

Sources added 2026-09-07

AWS S3 Files

Typed Handoff Envelopes Turn Agent Context into Restartable Workflow State — specifies the durable phase record whose isolation, persistence, and resume semantics the runtime must enforce.
Agent Harnesses — the orchestration layer the runtime hosts; harness handles tool execution and context, runtime handles compute and isolation
AI Infrastructure Investment Thesis - Mid-Post Training Layer — RL environments and eval stacks as the upstream investment thesis; agent runtimes are the serving-side complement
Claws - Persistent Looping Agents as App Replacement — persistent agent loops depend on runtime lifecycle management for long-running sessions
Hidden Technical Debt of AI Systems - Agent Runtime — source clipping
Local Inference Stack for Personal Agents — what the execution layer looks like when inference is local rather than an API call
Hermes Agent Master Class Part 5 - Tools and Toolsets — concrete comparison of local, container, remote, HPC, and serverless execution backends
Channel Failures Should Degrade Locally, Not Globally — applies runtime fault containment to messaging adapters and their recovery lifecycle
Hermes Agent Master Class Part 9 - Browser and Computer Use — compares isolated browser sessions with native desktop control as runtime action surfaces
Hermes Agent Master Class Part 11 - The Admin Layer — distinguishes profile-managed agent state from the host execution boundary beneath it
Runtime Isolation Does Not Imply Tool-Execution Isolation — explains why state separation does not guarantee filesystem, process, network, or credential isolation
How to Build a Custom Agent Harness — clarifies the boundary between middleware that governs environment access and the runtime that supplies execution and isolation guarantees