Guides·Guide
Ephemeral sandboxes that run a task and disappear, or persistent, general-purpose agents that stay available and act on their own. When to use which.
TL;DR
Two ways to run agents: short-running (ephemeral sandboxes like E2B, BrowserUse or Modal that spin up, do a task, tear down) and long-running (persistent agents like OpenClaw and Hermes that stay available and act on their own).
A short-running agent is a task: it spins up, runs, and tears down, with memory scoped per session that it rehydrates each time. A long-running agent is a runtime: the agent lives continuously, holds its sessions and persists across them, and can act on its own. Same goal, very different shape. Both can keep state, the real distinction is session memory versus a runtime the agent actually lives in.
Short-running: sandboxes and workflows (E2B, BrowserUse, Modal)
Stateless. Re-hydrates state, re-auths and reconnects every time. Great for code execution, scraping and batch tasks.
Long-running: persistent agents (OpenClaw, Hermes)
Persistent. An agent that lives, remembers and takes initiative. The only catch is idle cost, which over-provisioning or your own always-on infrastructure removes.
Do not dismiss short-running, it is the right tool for a lot of work: executing code in a sandbox (E2B), driving a browser to use a service with no API (BrowserUse), scraping, and batch jobs. Anything that runs and finishes is a clean fit. If your need is ephemeral compute, short-running is simpler and cheaper.
Memory is not it, a short-running agent can persist and rehydrate state. What a long-running, general-purpose agent like OpenClaw gives you is four things, plus the initiative that comes with being always-on:
The advantage is thinner than it sounds. A well-architected short-running stack (external state store, schedulers, session manager) can approximate a lot of what a long-running agent does. The real difference is two-fold: who builds and maintains that state, session and scheduling layer and keeps it from breaking, and the flexibility, ecosystem and community you get with a general-purpose runtime like OpenClaw. Long-running gives both by default; a short-running stack makes the plumbing your engineering project, and still is not general-purpose.
The one genuine downside of long-running is paying for idle time. Two things remove it. Over-provisioning: many agents share premium capacity safely, so you pay for agents, not idle machines. And your own infrastructure: if you already run servers 24/7, a long-running agent costs nothing extra to keep alive. Either way, long-running stops being the expensive option.
The long-running agents people actually run today are OpenClaw and Hermes. The key idea: OpenClaw is not just an agent, it is a runtime. It reasons at each step and acts on a browser, a terminal and files, instead of following a workflow scripted in advance that breaks when a tool changes. Being honest about the moat: the browser, reaching tools that have no API, is the most copyable part, any team can bolt it on in a couple of weeks. What does not bolt on is a runtime that reasons without a script, plus a community catalog of thousands of skills that grows without your team. That community, which OpenClaw and Hermes both have a large one of, is the real edge. The hard part is keeping a fleet of them alive, recovering and integrated at scale, and that is what Molted does, managed or on your own infrastructure.
One agent
Easy to babysit.
A fleet, by hand
Q.01
Neither is better in the abstract, they are different tools. Short-running is great for ephemeral compute (code, scraping, batch). Long-running is for a general-purpose agent that must be always available. The honest difference is that a long-running agent like OpenClaw is a runtime, not a script: flexibility, the ecosystem and community around OpenClaw and Hermes, and who maintains the state and scheduling layer. Memory is not it, both can keep state.
Q.02
It means OpenClaw decides what to do during the task instead of following a workflow scripted in advance. It observes, reasons, acts, and re-reasons at each step, adapting when a tool or UI changes, and it keeps state across sessions rather than only within a single thread.
Q.03
No. A short-running agent has memory scoped to a session and can rehydrate it, so memory is not the dividing line. The difference is a runtime the agent lives in continuously: it reasons each step, reaches tools with no API, holds state across sessions, and rides the OpenClaw and Hermes ecosystem and community.
Q.04
Mostly, yes, if you build the external state store, schedulers and session management yourself and keep them working. Long-running gives you that by default, which is the real trade-off, alongside being a general-purpose runtime rather than a sandbox that runs the code you hand it.
Q.05
The only real cost is idle time, and it disappears two ways: over-provisioning, where agents share capacity so you pay for agents not idle boxes, and your own always-on infrastructure, where there is no marginal cost to keep an agent alive.
Q.06
The two most popular open-source long-running agent runtimes, each with a large, active community: persistent agents you run that reason and act across your tools, with an open ecosystem of community-built skills and integrations. Molted hosts them at scale, managed or on-premise.
Keep reading