What is a cloud agent runtime?
One agent, one computer, any harness. A cloud agent runtime keeps the Spinup Agent durable above a real environment with files, packages, browsers, tools, secrets, and state, while the harness running inside can be swapped without rebuilding the setup. The active machine is replaceable capacity; the agent is the part that lasts, with an owner, a lifecycle, and a recorded history of every run.
Why It Exists
Agent workloads stopped fitting inside a single API call
Once an agent needs browser automation, filesystem access, package installs, long-running jobs, or persistent state, the infrastructure question changes. Teams no longer choose a model endpoint alone; they choose how the agent runs.
Inference is not the whole workload
Model APIs are essential, but they do not handle browser sessions, package installs, temporary files, or runtime state.
Lightweight compute breaks down
Serverless functions are too constrained for long-lived, stateful, or tool-heavy runs.
Raw infrastructure shifts the burden
DIY sandboxes and worker fleets can work, but they push isolation, drift, lifecycle, and orchestration onto the product team.
The abstraction needs to move up
The runtime category emerges when agents behave like small computers, not prompts.
What It Owns
A runtime owns the environment semantics around the agent
The mental model is simple: the agent is not instructions plus a model. It is a runtime object with an identity, an environment, run controls, and repeatable behavior.
Agent ownership
A durable, workspace-owned principal. The Spinup Agent has an ID, a slug, an owner, and a lifecycle that survives runtime replacement and harness changes.
Environment
An isolated space where the agent accesses a filesystem, shell, packages, browsers, and tools.
Runs
A stable run surface that receives runs, returns artifacts, and preserves runtime state.
Configuration
A control layer for harnesses, secrets, skills, and network policy.
Lifecycle
A repeatable way to operate the agent without rebuilding the stack for each run. Files, packages, and harness config persist between runs.
Operating history
Every run recorded against the agent: which harness, which model, what happened. One durable history per identity.
In Practice
What separates a cloud agent runtime from raw infrastructure
Most teams building with AI agents start with an inference API and a thin execution wrapper. That works until the agent needs to install a Python package, open a browser session, write files to disk, or hold state between runs. At that point, the team is no longer choosing a model. They are choosing a runtime environment.
A cloud agent runtime sits at that boundary. It gives each agent its own isolated, machine-like environment with a filesystem, shell, package managers, browser tooling, and controlled network access. It owns the lifecycle: how the environment is created, how files and package installs persist between runs, how secrets are projected, and how the setup carries forward instead of rebuilding from scratch every time.
The difference from a raw sandbox is scope. A sandbox runs code in isolation. A runtime adds persistence, controls, agent identity, and harness portability on top of that isolation. When your team swaps one harness for another, or compares two harnesses side by side, the runtime keeps the environment, secrets, and configuration stable across the change.
This matters because agent workloads keep getting heavier. Browser automation, data pipelines, media processing, and multi-step research tasks are not prompt-and-response interactions. They behave like small computers. The infrastructure question changes when the workload behaves like a computer. The cloud agent runtime category exists to answer it.
FAQ
Common questions about cloud agent runtimes
How is a cloud agent runtime different from a container or VM?+
Containers and VMs are infrastructure primitives. A cloud agent runtime sits above them, adding agent identity, persistent environments, secrets management, and harness portability. You may use a container or microVM underneath, but the runtime defines the environment semantics around the agent.
What does Spinup mean by "agent identity"?+
An agent identity is the durable, workspace-owned principal behind an agent: a stable ID, an owner, a lifecycle, the canonical configuration, and the recorded history of every run. The active machine, the harness, and the model can all change. The agent identity is the part that lasts. Today this is private to your workspace. Public agent identity (discoverable names, signed agent traffic, agent cards) is where the category is going, not what Spinup ships now.
Do I need a cloud agent runtime if I only use one harness?+
Even with a single harness, the runtime gives you persistent environments, controlled secrets projection, and a stable API surface. Files, installed packages, generated artifacts, and harness configuration carry between runs instead of rebuilding from scratch. These properties matter regardless of how many harnesses you run. When you later add a second harness, the runtime prevents you from rebuilding the setup.
What kinds of agent workloads benefit from a runtime?+
Workloads that go beyond a single model call: browser automation, data pipelines with file I/O, code generation requiring package installs, media processing, and multi-step research tasks. If the agent needs a filesystem, shell access, or persistent state, a runtime gives it a stable place to operate.
How does Spinup handle isolation between agents?+
Each agent gets its own isolated environment. Files, packages, browser sessions, and mutable state are scoped to that environment. Network access and secrets are projected per agent through the control plane, not shared across a generic worker pool.
Cloud Agent Runtime Architecture
How Spinup fits above the sandbox primitive
Sandbox infrastructure is part of the picture, but Spinup's bet is the layer above: the runtime and control plane for persistent agent environments. The goal is not only to run arbitrary code safely; it is to operate portable agents with cleaner environment semantics.
Early access
Start at the runtime layer, not just the sandbox primitive.
Request access if this is the runtime shape your team has been missing.