Operating System Thinking for Agents That Must Survive Sleep, Restart, and Scale to Hundreds of Overnight Jobs

Persistent and scheduled autonomous agents at scale need a runtime that owns task identity, durable state, checkpoint-and-resume, scheduling, and capability-based isolation. These are operating-system engineering problems. Reliable overnight work depends on deliberately rebuilding those primitives for the agent layer, so that sleep, worker restarts, and hundreds of concurrent jobs do not erase progress or outrun control.

Why the classical OS already solved the problems agents keep reinventing

A long-running task crashes halfway through execution, a context window overflows, or an overnight fan-out loop runs uncontrolled. General-purpose cloud tooling does not, by itself, tell an agent what finished, what it still owns, or whether it may act again. Those are runtime responsibilities. Classical operating systems addressed the same class of problems through process identity, state management, scheduling, isolation, and recovery. The agent layer needs equivalents suited to work that crosses model calls, tools, and external systems.

The Always-On Agents survey treats these agents as persistent-state systems, whose state includes task ledgers, permissions, credentials, commitments, trigger conditions, and audit records. Memory retrieval is only part of that surface. A runtime must govern the whole task lifecycle because an agent’s next action depends on more than remembered text. This is where the OS comparison earns its place. It describes responsibilities being re-derived for agents, and it stops being useful when the supposed runtime only wraps prompts.

Process identity: why every agent task needs a stable, durable handle that survives restarts

If a worker disappears, how does its replacement know which task it is continuing? The answer must exist outside the worker. A stable task handle anchors recovery, cancellation, and audit across changes in the model call, user session, or execution process. A session ID or correlation header is not enough unless it serves that durable task-level role. Identity must be minted before the first step executes and outlast every component that touches the task.

Quine realizes agents as native POSIX processes, using the PID for identity and fork/exec/exit for lifecycle. AgentLibOS instead represents each long-running agent as an AgentProcess with process identity, parent-child lineage, lifecycle state, and explicit runtime records. These models place identity at different layers. For overnight work, the decisive question is whether the logical task remains addressable after its worker dies, rather than whether a process identifier exists while it runs. When a parent spawns dozens of children, it can still track, cancel, and audit each child after a restart only if each logical task remains addressable.

Durable state: separating what the agent knows from where it is running

Suppose a container restarts after the agent has made progress but before the task finishes. If progress lived only in that container’s memory, the replacement starts without it. Scaling to zero creates the same problem. A durable runtime therefore keeps state apart from the work being run and provides the saved context when that work resumes. A state dictionary passed between workflow nodes can express that design, but an in-memory dictionary alone cannot provide restart durability.

The survey includes workflow and task-ledger state, policy and permission state, provenance, shared memory, triggers, credentials, and external commitments. Each can change what the agent should do next. A remembered plan is not sufficient if the permission to execute it has expired or the external action has already happened. Agent state needs to be schematized from day one, as carefully as database migrations, and its lifecycle assigned to the runtime.

That lifecycle extends beyond collecting useful context. The survey distinguishes the forward arc of writing, validating, organizing, retrieving, and acting from the return arc of updating, forgetting, auditing, and rolling back. Both belong in the design from the start. Otherwise, persistence preserves the agent’s past without giving the system adequate control over how that past shapes its future.

Checkpoint and resume: how a durable runtime lets an agent survive a crash without replaying the world

Durable state tells the system what survived, but recovery also needs to know what is safe to run again. A runtime needs records of the steps that finished and their results, including external effects that have already been committed. Agent checkpointing must keep track of which work is finished and which is pending so that a restart does not repeat costly inference or non-idempotent actions. It often works at the level of a workflow step, while a classical process checkpoint saves machine execution state.

Non-determinism makes recovery difficult. Replaying workflow control is different from invoking the model again, because a new model call need not produce the same text. External tools are not inherently deterministic either. Their recorded results must be available where replay would otherwise repeat a decision or action. A replayable trace is therefore not a promise of repeatable inference, and the runtime must mark which steps can run again and which must use saved results.

Human review makes this distinction especially clear. A held-open connection or polling loop does not provide a durable pause across a deployment or restart. The task should release expensive compute while preserving its state and approval package, then validate context and external-state compatibility before proceeding. AWS Lambda’s Durable Execution SDK provides a concrete example. It supports suspension at a defined workflow point for up to a year with zero idle compute cost.

The scheduler: giving agents a trigger layer so they act on time, not just on prompts

An agent that only acts when someone sends a message is running on a button. After a checkpoint, what causes it to run again? A trigger layer starts it again through a schedule, webhook, condition, or the completion of a dependency. It also determines the resource budget and order of execution.

Hundreds of concurrent overnight jobs make scheduling an immediate engineering concern. The scheduler must assign work, enforce concurrency limits, detect runaway tasks, and requeue failed work. More compute does not supply those controls. The scheduler must also account for API quotas and model-token budgets when it lets work run, even if a worker is free. The task’s durable identity lets these decisions remain attached to the work across changes in the temporary process.

Uncontrolled multi-agent fan-out resembles a fork bomb. Without circuit breakers and concurrency limits, a loop can consume infrastructure faster than the service’s economics allow. That failure belongs to the scheduler’s responsibility domain. Trigger state therefore needs to survive sleep and restart just as task progress does, or a durable agent may remember everything it needs but have no reliable way to wake.

Isolation: why each agent task needs a capability boundary, not just a sandbox

A sandbox limits where code can execute, but it does not fully determine what that code is authorized to do. An agent may stay inside its compute boundary while using credentials or tools that go beyond what the task is allowed to do. Compute isolation and authority isolation are different guarantees. A durable runtime needs both, particularly when tasks continue long after the interaction that started them.

Capability-based isolation gives each task explicit tool access scoped by actor, tenant, resource, action, and expiry. Credentials should be resolved at execution time, never copied into model context. Prompt instructions cannot enforce that authority boundary alone. The runtime must decide whether an action is permitted, rather than treating the model’s request as permission to proceed. Tool-effect classification adds another distinction, separating actions by their reversibility.

AgentKernel addresses agents ingesting untrusted web and repository content while using privileged state and tools. Its argument concerns a boundary that application-level safeguards may share with the agent itself. The runtime’s controls must work whether or not the model agrees. That requirement connects isolation to governance, because permission changes and revocation need to govern a task throughout its lifetime, including after it wakes.

What the literature has solved and what it has not — the governance and recovery gap

The survey coded hundreds of works and found that some areas are further along than others. Accumulation and retrieval receive more attention than governance, recovery, or relinquishment, with rollback the rarest capability in its lifecycle analysis. Append-only records can serve episodic traces, but they do not resolve changes to credentials, permissions, or commitments that have propagated into external systems. Recovery must account for those effects as well as stored context.

Forgetting exposes a related distinction between retrieval and control. Removing an item from an index does not establish that it has been erased from every substrate holding it. That difference matters both for compliance and for capability revocation. Likewise, restoring an earlier memory snapshot is not enough for a task to recover safely after it sent emails, submitted financial transactions, or changed production data. Provenance and audit records are needed to establish what happened, including where an effect cannot simply be undone.

The survey introduces the Always-On Evaluation Protocol (AOEP-v0) as a pilot contract that scores state mutation and recovery obligations alongside answer quality. It makes the evaluation gap explicit. The survey also connects the work to databases, distributed systems, formal methods, capability security, and machine unlearning. Purpose-built infrastructure can draw on that prior art instead of treating every governance problem as unique to agents.

Which platforms support scheduled, persistent agents, and what tradeoffs do they make?

No single production runtime implements all five primitives equally well. Managed runtimes, workflow frameworks, and durable execution services handle different parts of the work, so a useful comparison spells out what each one does. They are not interchangeable purchases or installations. Comparing identity and isolation, scheduled execution, durable pauses, and how much integration work the developer still has to do is more useful than ranking vendors for everyone.

AWS AgentCore harness reached general availability on June 17, 2026, emphasizing identity, isolation, and enterprise governance. It runs agents in Firecracker microVMs with full session isolation and supports workloads up to eight hours. Its policy controls extend to the gateway perimeter. Bedrock Guardrails within AgentCore Policy can evaluate authorized action outputs and gateway target inputs in real time. The Harness runtime is billed per vCPU-hour and GB-hour, with separate bills for gateway, memory, and model tokens.

Microsoft Agent Framework 1.0 reached general availability on April 3, 2026, combining Semantic Kernel and AutoGen in an MIT-licensed.NET and Python SDK. Both predecessors are in maintenance mode only. The framework emphasizes graph workflows and human-approval pauses, with native Model Context Protocol support and Agent-to-Agent support coming soon. LangGraph 1.0 and Google ADK 2.0 converged on the same broad pattern of graph-based steps with built-in human review. That convergence makes checkpoint-and-resume a shared architectural requirement.

Azure’s Durable Task Scheduler moved to consumption-based, pay-per-use pricing in March 2026, targeting bursty, idle-heavy agent workflows. Like Lambda’s suspension support, it shows how infrastructure can let work wait without keeping compute running. The developer-experience test is whether the chosen stack exposes the required primitives correctly with minimal friction, rather than leaving checkpoint serialization, capability scoping, and scheduler integration for the team to reconstruct.

Building a durable agent runtime from first principles — what to implement before the first overnight job runs

For a team preparing its first overnight workload, the implementation requirements follow directly from these boundaries. Create an immutable task ID before the task runs, keeping it separate from the session, worker, and model call. Schema the state dictionary and use a persistent store. Give the runtime ownership of promotion, expiry, and deletion so that persistence includes a controlled lifecycle that limits record growth.

Next, record completed steps and their outputs, distinguishing idempotent from non-idempotent work. Validate external-state compatibility before resuming a paused task. Make schedules, conditions, and event subscriptions first-class state. Before enabling fan-out, implement concurrency limits and circuit breakers, then scope tool access by actor, tenant, resource, action, and expiry. Classify tool effects by reversibility, keeping authority decisions outside the model’s reasoning.

Governance belongs in the first production run, too. Implement provenance and audit as first-class records, because reconstructing an overnight task becomes harder once its effects have spread. Before launch, answer where state lives and who can read it, which permissions each agent needs, and how its actions and reasons become visible. Treating the agent layer as an OS-class engineering problem makes unsupervised overnight work a system capability and prevents recurring requests for human rescue.