Cloud Agent Runtimes Need Their Own Layer

Your agent loses its files when the run ends. The runtime layer underneath is the part that should have kept them.

For short-lived tasks, a raw sandbox call works fine. Run some code. Return output. Tear it down. That model holds when the agent is stateless and narrowly scoped.

The moment an agent needs to install packages, hold files, manage credentials, or remember what happened last run, the requirements change shape.

Agents accumulate state

A coding agent installs dependencies, writes intermediate files, and stores test results it needs later. A browser agent logs into a service and expects that session to survive between steps. A data pipeline agent checkpoints progress so it can resume after failure.

These are not exotic requirements. They are table stakes for any workflow longer than a single function call. And they all point to the same need: an environment that persists across runs.

You are no longer asking for compute. You are asking for a system that holds context (files, packages, credentials, browser sessions) and presents it consistently every time the agent wakes up.

The harness is not the whole product

Agent infrastructure discussions tend to center on whichever harness is popular at the moment (Claude Code, Codex CLI, or the next one). The harness is the engine the agent uses to think and act. But collapsing everything into the harness obscures a real architectural gap.

The harness defines what the agent can do. The runtime defines where it does it.

When the runtime is thin, the harness inherits every gap:

• packages installed in one run disappear in the next
• isolation boundaries are implicit or absent
• persistence requires duct-taping external storage
• there is no central place to observe, pause, or kill a running agent

A runtime layer does not replace the harness. It gives the harness a stable, observable, persistent environment to run inside.

What belongs in the runtime layer

If the harness is the brain, the runtime is the body. It should own at least these concerns:

• Isolation: each agent gets its own environment with defined network policy and resource limits
• Persistence: files, packages, and state survive between runs without external wiring
• Snapshots: the ability to checkpoint an environment and restore it later
• Observability: logs, resource usage, and lifecycle events visible from a control plane
• Portability: swap the harness without rebuilding the environment

The Spinup Agent is the durable object above all of this. The active machine underneath is replaceable.

None of these are novel ideas in isolation. Containers and VMs have solved variants of each for decades. What is new is applying them as a coherent layer purpose-built for agent workloads, where the work is long-running, stateful, and not fully predictable.

What comes next

This is the first in a series of posts exploring the cloud agent runtime category. Upcoming topics:

• microVMs versus containers: tradeoffs for agent isolation
• persistent environments for multi-step agents
• runtime portability across harnesses
• what to evaluate when choosing agent infrastructure

Spinup is pre-launch. The direction is clear enough to write about with confidence, even as the implementation continues to take shape.

If you are building agents that need a durable home above a real cloud computer, with a harness you can swap, join early access. Or follow along here as we publish what we learn.

The first step toward agent identity.