Topics/Agent OS

ADPS Topic Study

Agent OS · From analogy to engineering checklist

Use operating-system responsibilities to inspect a multi-agent runtime while keeping the limits of the analogy visible.

A multi-agent runtime increasingly resembles a small operating system. It schedules execution units, isolates resources, carries messages, stores state, handles failures, and lets people pause, take over, and resume. The analogy is useful as a completeness check.

Eight responsibilities

OS view Question for an agent runtime
Scheduling Which agent runs, with what priority, budget, and cancellation?
Isolation Are context, tools, credentials, workspace, and failure separated?
Communication Do messages, events, artifacts, and hand-offs have schemas and versions?
Storage How are checkpoints, memory, workspace, and external facts separated?
Identity How does human delegation reach agents, runs, tools, and resources?
Observation How do causal trace, component versions, state deltas, and outcomes connect?
Reclamation When are temporary credentials, locks, queues, tasks, and sandboxes released?
Failure handling How do timeout, retry, compensation, circuit breaking, and takeover combine?

Where the analogy helps

Operating systems separate the ability to execute from the ability to manage execution over time. A model that calls tools has not necessarily solved fairness, isolation, resource leaks, or failure propagation. The analogy forces those responsibilities into the architecture.

Consider two coding agents changing a client and a service. Scheduling must detect whether both alter the same API contract. Isolation supplies separate worktrees and short-lived credentials. Communication uses a versioned Handoff Contract. Storage retains checkpoints. Cancelling one task must also release its sandbox, leases, and queued callbacks. “Start two agents at once” answers none of those responsibilities.

Where it distorts

Agent intent and output are probabilistic in ways ordinary processes are not. Agent memory includes selection, trust, forgetting, and versioning rather than only storage. Human-in-the-loop is a business-control and organizational-responsibility problem, not just interrupt handling.

Agent OS is therefore an engineering checklist and research agenda, not a settled product category.

Minimal runtime surface

submit(task, principal, constraints)
spawn(role, task_packet, authority_scope)
handoff(contract)
observe(run_id)
checkpoint(run_id)
cancel(run_id, reason)
reclaim(run_id)

Names may change; responsibilities remain. Central orchestration, distributed events, and hybrid architectures all need answers.

Research questions

  1. How should agent, workload, run, and tool-invocation identity be layered?
  2. Can cross-session resource conflicts be declared and detected before scheduling?
  3. How should Handoff Contracts connect to agent protocols?
  4. Which versions and external preconditions belong in a long-running checkpoint?
  5. How does reclamation cover trial shutdown, owner departure, and retirement?

Source

This topic grew from cross-layer discussion in the Collaboration and Governance workshops and connects C5 Sub-Agent Isolation, C6 Choreography, X1 Observability, and X3 Security & Identity.

Suggested citation: ADPS, Agent OS · From analogy to engineering checklist, ADPS Topic Study, 26 August 2026.

Topic index · Collaboration workshop · CC BY 4.0

Chronicle

Recorded source
Workshop and case records cited in the article: Collaboration workshop ()
Source date
First published on ADPS

View in the ADPS Chronicle