When Persistence and Scheduling Are Runtime Primitives Not Bolt-Ons

To run persistent and scheduled autonomous agents at scale, a runtime needs to own durable state, scheduled execution, recovery, and resource authority together. Cron, queues, and serialized context can connect separate runs, but they do not provide those guarantees by themselves. The distinction between runtime primitives and bolt-ons is structural, because autonomy depends on what survives between actions and what governs the next one.

Why "just add cron" is not persistence — the structural mismatch between stateless infrastructure and stateful agents

A team with agents in production already has a scheduler, even if it lives implicitly in queue logic. That logic decides which agent runs next, which waits, and which gets to try again. A cron job may start a fresh process, a Postgres table may hold serialized state, and webhooks may supply event triggers. Each component has a clear local job. Trouble starts when an agent’s work moves from one of these components to another.

Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents defines always-on agents as systems whose future behavior depends on durable state accumulated across earlier interactions. This is different from handling a short, stateless request whose inputs describe the work to do. The agent must remember work it has yet to finish, choices it made earlier, and effects already committed outside the process. A schedule alone cannot preserve that continuity. Rehydrating state on every invocation therefore exposes an architectural contradiction.

The separate components do offer useful visibility. A cron job has a schedule and logs, while a queue message has a payload. But that visibility does not establish what happened across a boundary when execution failed. The infrastructure treats each invocation as replaceable, while the agent’s next action depends on the history connecting them.

What breaks at each seam when bolt-on state meets a long-running agent

Scheduling unfairness appears when queue order substitutes for a policy about shared resources. A research agent taking tens of seconds per turn and a triage agent taking milliseconds need different treatment, yet a naive first-come-first-served queue cannot distinguish them. The slow agent can monopolize the model endpoint. Without priority- and deadline-aware scheduling, tail latency dominates fleet performance.

When ten agents share a model endpoint, their calls interleave at the API layer, making latency unpredictable. At the same time, long-running agents can lose earlier context they still need to truncation. These are separate problems with a common boundary. Neither the queue nor the endpoint owns the obligation to preserve each agent’s working continuity, leaving context management stranded between components.

Isolation gaps arise when agents share writable resources without protection. Two agents writing to the same scratchpad, file system, or database can corrupt each other’s state. Tool I/O introduces another seam. Each integration brings its own authentication, retry semantics, and error model, so every agent must reproduce defensive logic unless a common layer normalizes those differences.

Recovery exposes the cost of these fragmented responsibilities. A data-reconciliation agent that fails mid-run needs to resume from a checkpoint, while an email agent waiting for a report needs dependency management. A failure log supplies neither guarantee. The Always-On survey finds that the literature concentrates on accumulating and retrieving state much more than governing, recovering, or relinquishing it. The weakest connection is often the one between a failed action and a safe next step.

What the agent's state actually is — and why the context window is not a substitute for a memory architecture

Saving the context records what text the model was using. The survey distinguishes memory from control-relevant state. Memory includes episodic traces of earlier sessions, semantic facts, preferences, and procedural skills. These serve different purposes over different spans of time. A record of what happened is not interchangeable with a stable constraint or a reusable learned behavior.

Control-relevant state includes more than what is usually called memory. It includes task ledgers, permissions, credentials, provenance, shared state, trigger conditions, and external commitments. An unfinished task and an email already sent impose different obligations on the next run. Their persistence requirements differ from their mutability and authority requirements. Putting them into one serialized context does not erase those distinctions.

Rolling summaries reduce tokens, checkpoint snapshots preserve exact state, and episodic memory retains reusable prior outcomes. Fact extraction keeps stable constraints, while selective retrieval brings earlier steps back into view only when the current task needs them. None removes the need to govern the state that moves between them.

How to consolidate accumulated information remains unresolved, however. Agents can accumulate enough important information that searching memory becomes slower than processing the full context. Choosing what to retain is therefore not just a retrieval problem, because forgetting can affect obligations and evidence as well as usefulness. The complexity is unavoidable once past interactions shape future actions. A runtime substrate exists to absorb that complexity rather than leave every agent process to manage it independently.

What a purpose-built runtime substrate actually owns — the primitives that bolt-ons cannot provide

A runtime primitive enforces an invariant where an agent cannot bypass it. The survey maps the persistent-state lifecycle onto operating-system abstractions for this reason. Process isolation does not depend on a process choosing to respect its neighbors. State governance needs a base like this below the agents. A wrapper above the resource boundary cannot give the same guarantee if there is another execution path around it.

Scheduling becomes a primitive when the runtime knows an agent’s priority, deadline, and queue depth before it assigns the next model call. Its decisions concern the fleet. Cron provides a wake-up time. The distinction is between initiating work and controlling execution under shared constraints. Durable execution then has to preserve those constraints when work fails.

Agent libOS: A Runtime Substrate for Capability-Controlled Self-Evolving LLM Agents implements Durable Task Run supervision with fail-closed recovery. Its prepare–dispatch–settle protocol records intent, dispatch, and classified outcomes for provider-backed effects. An ambiguous dispatched outcome becomes explicit. This is more than saving a checkpoint. A serialized state record on its own cannot show whether it is safe to retry an external action.

Agent libOS also makes operation admission depend jointly on process identity, the applicable Task Authority ceiling, typed Capabilities, deterministic policy or Human approval, resource budgets, and execution through a concrete primitive. Tool visibility is not permission to act. A separate evidence plane records intent, outcomes, events, audit records, and causal links to explain decisions. This separation prevents an agent’s account of an action from becoming its permission to perform that action.

Where self-evolving agents make the primitive/bolt-on distinction critical for security

A self-evolving agent can change its action surface after deployment by activating skills, generating tools, or forking child processes. Persistence extends the reach of those changes. Scheduling lets the agent act again without a fresh manual invocation, so a mistaken grant of authority can affect later runs.

Agent libOS describes a threat in which a repository file or retrieved page directs an agent to activate a debugging skill, register a generated tool, send context to a remote endpoint, and preserve the result in a reusable image. The file or page looks like ordinary material for the task. The requested actions can nevertheless redirect both execution and future behavior. Prompt defenses and planner–executor separation can reduce exposure, but they cannot replace the check at the resource-touching primitive.

The runtime’s invariant is precise. The model-visible action surface may evolve without implicitly expanding resource authority or permitted information flows. Agent libOS enforces information-flow admission through runtime-maintained labels, immutable source references, and clearance checks against a canonical destination in a Host-owned registry. Conditionally permitted high-sensitivity egress requires an exact one-shot Human release.

A manually re-invoked agent has a human checkpoint at each invocation. An always-on agent depends on the runtime to supply that checkpoint explicitly, making state recovery a security concern as well as a reliability concern. Once corrupted state affects external actions, the system needs ways to revise and audit what follows and to limit its effects. A prompt-level instruction cannot enforce capability scoping on a newly synthesized tool merely because it told the model to behave carefully.

What the full persistent-state lifecycle requires from a runtime — and where current systems fall short

The survey traces a forward arc from observing and writing state through validation, organization, retrieval, and action. On the return arc, the steps are update, forget, audit, and rollback. The distinction reveals an uneven research landscape. Accumulation and retrieval receive much more attention than the obligations that arise after state changes or causes an external effect. Purpose-built systems are not exempt from these gaps.

Validation is the forward arc’s “missing gate”. Most systems write state without checking whether it is correct, whether it is authorized, or whether it is consistent, so injected or hallucinated content can affect later runs. Organization can then weaken the evidence needed to correct it. Summarization may discard provenance, while consolidation can merge episodic traces until individual entries are no longer auditable. Token reduction can therefore come at the expense of governance.

The return arc has different unresolved problems. Updating a record does not establish that the revision has propagated, and hiding an entry from retrieval does not establish that it has been erased. The latter distinction has compliance implications. Audit must account for how state was used, while rollback requires a way to restore earlier state. The survey identifies rollback as the rarest capability in its corpus.

An agent that sent an email on bad state illustrates the limit. An immutable audit record and a restorable checkpoint can establish the state behind the decision, but restoring state cannot unsend the email. Recovery must account for committed effects.

The survey introduces an evaluation protocol as a pilot contract that scores state mutation and recovery obligations. That changes what a successful evaluation asks a system to demonstrate. It also connects agent design to databases, distributed systems, formal methods, capability security, and machine unlearning. The remaining work includes memory consolidation and defensible forgetting policies. The direction is clear even where solutions remain incomplete.

How to run long-running agents reliably — why the agent layer is the right abstraction boundary

The agent layer is where resource authority, state governance, and scheduled execution meet. Treating the model as a CPU and the runtime as an OS helps locate those responsibilities. The runtime loads context, manages executable subtasks, and mediates tools. Its boundary must remain stable when an agent changes its plan or acquires another skill. Otherwise, the guarantees depend on the behavior they are supposed to constrain.

Agent libOS makes this approach concrete through persistent AgentProcess instances, process-local Object Memory namespaces, declarative Skills, and syscall-mediated Deno/TypeScript JIT Tools. Scoped checkpoints, hierarchical resource accounting, and durable supervision support the same boundary. These show how operations specific to an agent can sit above controls that the agent cannot rewrite through its prompt.

A scheduler must govern execution across the fleet, and persistence must extend beyond retrieval to recovery and governance. A single install command and the ability to work across CLI, Slack, and SMS without separate session integrations say something about the architecture only if the control plane is truly channel-agnostic.

Retrofitting can still produce the needed infrastructure, but it does not avoid building a runtime. The team must supply scheduling logic, state management, retry policies, and an audit trail, then place their enforcement below the agents. That is the builder’s choice. Either the substrate owns continuity and authority, or each agent implementation must attempt to reconstruct them at every boundary it crosses.