What long-running changes about the architecture
A short-running agent is a request: it runs and finishes, so the architecture is simple. A long-running agent stays alive for hours or days, which means it has to survive crashes, hold state, act on its own, and share hardware with many others. That is a different, harder architecture.
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 per-agent pricing or your own always-on infrastructure removes.
Durable execution and queues
If an agent crashes mid-task, the work should resume, not restart from zero. That is durable execution.
- Durable execution: persist each step so a restart resumes where it stopped, instead of losing progress.
- Queues and scheduling: trigger agents on events or a heartbeat, and absorb bursts without dropping work.
- Idempotency: re-running a step after a crash must not double-charge or double-send.
State, persistence and recovery
Long-running agents accumulate state, and that state has to be durable and recoverable. In practice that means a versioned filesystem with point-in-time restore, plus a recovery loop: detect the crash, restart the process, recreate the instance if needed, restore a known-good state and alert only when automation cannot fix it.
01
In-place repair
A daemon restarts OpenClaw the instant it dies.
02
Clean recreation
If the instance fails, it is recreated with state intact.
03
Known-good restore
Config auto-repair and a versioned restore.
04
Critical alert
Only if all else fails, with a full post-mortem.
Autoscaling and resource limits
Agents mostly wait, so running many on shared capacity is how the economics work, but it is also how one machine runs out of memory and takes everything down. Running many agents safely needs a throttle on startups, real-time memory monitoring and selective shutdown by priority before the machine is overwhelmed. Autoscaling alone does not give you that, the protection has to be agent-aware.
One agent
Easy to babysit.
A fleet, by hand
Build it, or run on a runtime that ships it
You can assemble this yourself: a durable execution engine, queues, an autoscaler, a recovery system, a versioned store, an integration layer. That is a platform, and it is months of work plus permanent on-call. The alternative is a runtime that ships the whole architecture. Molted is that runtime for long-running agents (OpenClaw today, Hermes on request): 4-tier self-healing, per-agent resource limits, a versioned filesystem with point-in-time restore and 1,500+ integrations, managed.