Search ARuntime.com

Find runtime definitions and implementation guidance

Search page titles, summaries, headings, glossary terms, use cases, and runtime-directory entries.

Enter at least two characters.

ARuntime Reference

Persistent Agent Operating Systems

The operating-system metaphor is useful when an agent runtime genuinely owns state, capabilities, isolation, scheduling, checkpoints, and lifecycle. It is misleading when it only wraps prompts.

Audience: Technical readers Reading time: 2 minutes Status: Emerging proposal Last reviewed:

“Persistent agent operating system” is an emerging metaphor for a runtime that manages long-lived agent state, memory, tool capabilities, waits, checkpoints, and recovery. The useful part of the metaphor is lifecycle and resource ownership; it should not imply a conventional kernel.

Key takeaways

  • Agent memory and durable workflow state are separate concerns.
  • Execution workers should be disposable while checkpoints, approvals, and idempotency remain durable.
  • Capability-based tools and explicit authority are more reliable than permissions embedded in prompts.

Definition

A persistent agent runtime treats an agent task as a long-lived process that may outlive a model call, worker, or user session. It provides a stable task identity, durable state, timers, tool registry, approval waits, cancellation, and evidence. The model remains a replaceable reasoning component.

Memory models

Working context supports the current step. Conversation history supports reconstruction. Project or user memory retains approved facts and preferences. Archival stores retain source material. The runtime should decide promotion, correction, expiry, export, and deletion independently of whether the model remembered to invoke a “save” tool.

Durable execution

Durability records completed steps and their results so a restarted task can resume without repeating expensive inference or non-idempotent actions. LangGraph documents checkpoint-based persistence, while general workflow systems such as Temporal provide durable timers and activity semantics. [ar_cite id=”langgraph-persistence” label=”LangGraph”] [ar_cite id=”temporal” label=”Temporal”]

Capabilities and tools

Each task receives an explicit set of tool capabilities scoped by actor, tenant, resource, action, and expiry. Credentials are resolved at execution time and are not copied into model context. Tool contracts classify read-only, reversible write, irreversible, financial, external communication, code execution, and administrative effects.

Human waits

A task awaiting review should release expensive compute while preserving state and an approval package. The approval identifies the exact proposed action, evidence, authority, expiry, and change since the request. Resume must validate that the context and external state are still compatible.

Replay and recovery

Deterministic workflow replay can reconstruct orchestration decisions, but model calls and external tools are not inherently deterministic. Persist their results or stable references and mark which steps may be safely re-executed. A replayable trace is not a promise that a new model invocation will produce the same text.

Limits of the operating-system metaphor

Agent runtimes normally depend on real operating systems, containers, processes, networks, and storage. They do not replace kernel scheduling, memory protection, or device drivers. Use the metaphor only to communicate persistent processes, capabilities, resource budgets, and lifecycle; retain precise component names in architecture and security reviews.

Maintenance record

Found an error, outdated capability, or unclear category boundary? Submit a correction with a supporting source.