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
- How should agent, workload, run, and tool-invocation identity be layered?
- Can cross-session resource conflicts be declared and detected before scheduling?
- How should Handoff Contracts connect to agent protocols?
- Which versions and external preconditions belong in a long-running checkpoint?
- 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.
Chronicle
- Recorded source
- Workshop and case records cited in the article: Collaboration workshop ()
- Source date
- First published on ADPS