Managed agents without model lock-in
Managed agents are long-running AI agents with a runtime around them: tools, files, secrets, memory, sessions, and execution infrastructure. Spinup takes that idea one layer higher. One Spinup Agent, one real cloud computer, any harness, model choices that can change over time.
What's Inside a Managed Agent
The runtime is most of the work
The model call is the visible part of a managed agent. The runtime around it is what makes the agent useful in production: state that survives, tools that are installed, secrets that are scoped, and a stable place to operate.
Agent definition
Who the agent is, what it does, which tools and skills it has, which model it talks to. A durable object the workspace owns, not a prompt copied between scripts.
Environment
Files, packages, browser state, and installed binaries that last between runs. The same environment the agent leaves at the end of one run is the one it opens for the next.
Secrets
API keys, OAuth tokens, and credentials projected into the run with the right scope. Not baked into a container image. Not pasted into a system prompt.
Memory and history
Memory of past runs, decisions, and learned facts. Operating history recorded against the agent itself, not scattered across logs.
Run surface
A stable endpoint that accepts runs, returns artifacts, and reports status. The same surface for your product, your CI, your dashboards.
Lifecycle controls
An owner, a lifecycle, and a kill switch. The agent can be paused, revoked, and audited like any other production object.
Why The Category Exists
Managed agents are how AI agents leave the prompt era
A model API call is bounded to text. A managed agent is a small computer with a job. Once the workload behaves like a computer, you need the boundary, the lifecycle, and the controls that come with one.
For a year, the standard pattern was: model API plus a thin orchestration script. That works for short, stateless tasks. It stops working as soon as the agent installs a package, opens a browser, writes a file someone else needs, holds a secret, or has to remember anything between runs.
The fix is not a smarter prompt. It is a runtime. The runtime is what gives the agent a real computer to run on, with files, packages, browsers, secrets, and state scoped to that one agent and nothing else. The model call still happens. It just stops being the only thing the platform manages.
That is what people mean now when they say managed agents. The runtime, the agent definition, the tools, the memory, and the lifecycle are the product. The model is one piece of work inside it.
Lock-In, Concretely
What a model-native managed agent binds to one provider
Lock-in is not a vague risk. It is a list of specific things that stop being yours when the agent, the memory, and the tools all live inside one provider's stack.
Agent definition
The canonical agent record, what it does, what it knows about, which tools and skills it has, lives in the provider's database. Move providers and the agent does not come with you.
Sessions and run history
Sessions, conversations, and run history bind to one vendor's schema. Replaying a run elsewhere means rebuilding the history from logs.
Memory semantics
Memory semantics are provider-shaped. A different vendor's memory object is not a drop-in replacement, even when the use case is the same.
Tool permissions
Tool definitions, permission shapes, and approval flows are vendor-specific. The same agent on a different stack means rewriting the tool layer.
Model choice
Switching the model means switching the agent. The agent definition does not survive a model change because the agent is provider-native.
Harness lifecycle
The harness inside the environment is fixed. Swapping to a different agent framework means leaving the platform.
Spinup's Answer
Swappable harness. Swappable LLM. Canonical agent state.
The agent is the durable object. The harness inside its environment is swappable. The model the harness talks to can change. The environment, skills, secrets, and history stay attached to the agent across every change underneath.
The agent stays workspace-owned
A workspace-owned Spinup Agent: stable ID, owner, lifecycle, configuration, and recorded run history. The agent is the part that lasts.
A real computer per agent
Each agent gets its own isolated cloud computer. Files, packages, browsers, secrets, and state persist between runs. The active machine is replaceable substrate.
Harnesses are swappable
Pick OpenClaw or Hermes today. Switch the harness when a better one lands. The environment, skills, secrets, and history stay attached to the same agent.
Model choice can change
Model choice lives inside the harness. As the model landscape moves, the agent definition does not have to move with it.
What Runs Today
OpenClaw and Hermes already run on this model
Spinup is not a thought experiment. Two harnesses already run inside the runtime today. OpenClaw runs on the local backend inside an isolated microVM, with projected secrets, managed configuration, persistent state, and durable run records. Hermes runs through `/exec` on the same model, with a persistent Python environment and the rest of the same plumbing.
More harnesses are on the way: Claude Code, Codex CLI, OpenCode, PI, Deep Agents, NanoClaw. Each one slots in as another harness inside the same agent runtime. The Spinup Agent, the environment, the skills, the secrets, and the run history stay the same.
FAQ
Common questions about managed agents
What are managed agents?+
A managed agent is a long-running AI agent with a runtime around it: a definition, tools, secrets, files, memory of past runs, and a place to actually execute. The model call is one part. The agent's environment, state, and lifecycle are the rest. Without the runtime, an agent is a prompt with nothing behind it.
How are managed agents different from model API calls?+
A model API call is stateless and bounded to text in, text out. A managed agent holds files between runs, installs packages, drives a browser, projects secrets, remembers what it did last time, and exposes a stable endpoint your product can call. The model is one piece of work inside the run. Everything around the run is what the runtime owns.
Do managed agents need a sandbox or cloud computer?+
Yes. Once the agent installs a package, writes a file, opens a browser session, or holds state between runs, a model endpoint alone is not enough. The agent needs a real computer with a filesystem, packages, browsers, tools, and controlled network access. The runtime is what makes that computer durable, scoped to the agent, and safe to operate.
Can a managed agent switch models?+
On Spinup, the agent definition sits above the harness and the model. The harness inside the environment is swappable. Model choice lives inside the harness and can change as better options appear. The agent itself, its skills, secrets, environment, and run history, stays the same. On platforms where the agent object is provider-native, switching models means switching agents.
Why use Spinup instead of a model-vendor managed agent?+
A model-vendor managed agent is the fastest path when you want a provider-native agent and that provider is enough. Spinup is for teams who want the managed-agent shape without binding the agent definition, memory, tools, harness, and model choice to one vendor's stack. The agent stays workspace-owned. The runtime is the part you can keep.
Related
Where managed agents fit in the runtime story
Start with the runtime category, then look at the open frame and the Claude-native alternative.
Early access
Managed agents that stay yours.
One Spinup Agent above harnesses, models, environments, skills, secrets, and state. Join early access and create your first managed agent.