AOS-0 #

Architecture Handoff for a Zero-Context Planning & Design Agent

Agent-native operating system • machine-model exploration • self-hosting vertical slice

Mission: turn the ideas in this handoff into a coherent, internally consistent source of truth for an operating system whose native computational inhabitants are autonomous actors—not human users and not POSIX applications.

Document role	Context transfer and architecture brief
Audience	Planning / architecture agent starting from zero
Expected next output	Design docs, normative specs, ADRs, prototype plan, and acceptance tests
Project stage	Pre-implementation / architecture formulation
Working name	AOS-0 (placeholder; do not treat the name as a requirement)

---

1. Instructions to the Receiving Architecture Agent #

You are not being asked to decorate Linux with agents. You are being asked to formalize a different computational ontology and to identify the smallest trustworthy substrate that can support it.

Treat this document as an architectural brief, not as a finished specification. Some concepts below are deliberately provisional. Your job is to preserve the project thesis while making the model precise enough to implement and test.

1.1 Your responsibilities #

• Produce a canonical system model: define objects, identities, state transitions, authority, lifecycle, failure semantics, and cross-node semantics precisely.
• Separate normative requirements from implementation suggestions. AOS-0 should be able to change implementations without changing the machine model.
• Challenge contradictions and unnecessary abstractions. Do not preserve an idea merely because it appears in this handoff.
• When a conventional OS concept appears (file, PID, UID, socket, process, hostname, application, login, shell), require an explicit justification before admitting it into the native model.
• Keep probabilistic reasoning out of the trusted enforcement boundary. Models can propose; deterministic mechanisms enforce authority, budgets, isolation, world boundaries, and promotion policy.
• Design for a staged bootstrap: first prove the ontology in a hosted environment, then progressively replace host scaffolding with native services.
• Optimize for machine-readable specifications and automated validation. Humans are readers and principals, but not the primary operational interface.

1.2 What you must not assume #

• Do not assume POSIX is the native ABI.
• Do not assume one OS instance equals one physical computer.
• Do not assume a running process is the durable identity of an autonomous actor.
• Do not assume persistent state is organized as named files and directories.
• Do not assume network location is identity.
• Do not assume human login/session semantics exist.
• Do not assume LLM inference is always available or required for boot.
• Do not assume the current ten-object / twenty-syscall sketch is final.

2. Executive Summary #

AOS-0 explores what an operating system would look like if autonomous software actors were its expected inhabitants and humans were merely one class of external principal. The design deliberately starts below the usual “agent framework” layer. The intended result is not an agent daemon, model router, or orchestration framework on Linux; it is a machine model in which durable actors, delegated authority, commitments, speculative worlds, causal state, resource budgets, and explicit external effects are native concepts.

The strongest working thesis is:

The native computational object is a durable actor operating within a branchable world under delegated authority and finite resources. Execution, inference, storage, networking, and even legacy operating systems are resources that actors temporarily acquire in pursuit of commitments.

A second thesis constrains the trusted core:

The kernel should understand authority and causality, not language. Natural-language goals, model selection, planning, embeddings, confidence, and semantic reasoning belong above the trusted enforcement boundary.

The proposed first proof is a recursive vertical slice called Bootstrap-1: a resident Maintainer Actor modifies the OS source state, builds a successor image, boots and tests it in an isolated candidate world, produces verification evidence, prepares a promotion effect, and—if deterministic policy permits—promotes the successor. The successor must then repeat the loop to create another generation.

3. Problem Statement #

Conventional operating systems encode assumptions accumulated around interactive human computing: user accounts, sessions, applications, processes, files, paths, sockets, hostnames, terminals, windows, and explicit human command sequences. Agent frameworks generally inherit those assumptions and add a higher-level orchestration layer. AOS-0 asks whether those inherited abstractions are still the right foundational ontology when the expected inhabitants are autonomous, persistent, delegating actors that routinely speculate, coordinate, migrate, checkpoint, consume model compute, and act on external systems.

3.1 Litmus test #

If every LLM were replaced with a deterministic state machine and every GUI removed, would the OS still look fundamentally agent-shaped? If it collapses to Linux plus RPCs, it failed.

3.2 Native-program test #

A truly native actor should be able to live its entire lifecycle without needing to know what any of the following are:

PID UID file path directory shell socket hostname
login session application window REST endpoint API key

Compatibility components may expose these concepts to legacy software. They are not presumed to be native truths.

4. Settled Design Premises #

Premise	Meaning	Status
Actors are durable; executions are disposable.	An actor may survive process loss, model replacement, reboot, architecture migration, and movement between physical nodes.	Preserve unless contradiction found
No ambient authority.	An actor can affect an object/resource/effect only through an explicit authority path rooted in a capability it possesses.	Preserve unless contradiction found
Delegation attenuates authority.	A child/delegate cannot acquire rights merely because its parent had them; any expansion requires a separate grant from an authorized principal.	Preserve unless contradiction found
Work is explicit.	Meaningful autonomous work is represented by commitments rather than inferred from the existence of a thread or process.	Preserve unless contradiction found
Resources are budgeted.	Compute, inference, memory, network, storage, power, external API spend, and similar scarce quantities must be accountable and composable.	Preserve unless contradiction found
Persistent state is versioned.	Native state should favor immutable revisions and lineage over destructive overwrite.	Preserve unless contradiction found
Speculation is ordinary.	Agents should be able to branch state, act within candidate worlds, compare outcomes, and merge/discard candidates.	Preserve unless contradiction found
External effects are special.	Actions that cross a rollback boundary—messages, purchases, pushes, actuators, public publication, remote API disclosure—must have explicit effect semantics.	Preserve unless contradiction found
Causality is structural.	Persistent state and consequential effects should carry machine-readable causal ancestry; provenance is not merely a log.	Preserve unless contradiction found
Trusted enforcement is deterministic.	LLMs do not decide whether authority exists. Probabilistic components may recommend or plan, but the substrate enforces mechanically checkable rules.	Preserve unless contradiction found
AI is a resource, not a boot prerequisite.	The system must boot and recover its durable state with no network, no model provider, and no human present.	Preserve unless contradiction found
Physical nodes are substrate, not necessarily the OS boundary.	The model should leave room for durable actors and objects to span or migrate between machines.	Preserve unless contradiction found

5. Candidate Native Ontology #

The current working model contains ten native object classes. These are candidates, not sacred. The architecture agent should attempt to reduce, merge, or split them where that produces a cleaner invariant set. Any replacement must preserve the capabilities the project is trying to express.

Object	Purpose	Required semantics	Key warning
Actor	Durable autonomous identity/state holder	Outlives individual executions; owns/receives commitments; addressable while dormant.	Not a process; should not contain CPU register state.
Execution	Temporary physical incarnation of an Actor	Binds code and resources to a CPU/GPU/remote execution environment to make progress on a commitment.	Disposable; failure must not destroy Actor identity.
Capability	Unforgeable authority over an object/resource/action	Carries rights and constraints; can be attenuated/delegated/revoked.	No UID/root shortcut; no ambient fallback.
Resource	Scarce/bindable compute or hardware resource	CPU time, memory extent, GPU queue, accelerator, storage extent, network path, device capability, inference service.	Resource class is broader than Unix device/file descriptors.
Channel	Asynchronous causal communication primitive	Delivers object references, events, and delegated capabilities; supports dormant actors waiting without a resident process.	Prefer durable/event semantics over byte-stream semantics.
Object	Immutable persistent state revision	Content identity, schema/type, predecessor/lineage, references, creator, commitment, causal inputs.	File names/directories are compatibility views, not native identity.
World	Branchable view of system-visible state	Supports speculative alternatives, diff/merge/discard, candidate OS generations, and isolated testing.	Must define exactly what state is branchable and what cannot be virtualized.
Commitment	Kernel/runtime-visible accounted unit of work	Links actor, objective reference, authority, budget, dependencies, world, status, deadline/priority.	Objective content is opaque to trusted kernel.
Budget	Hierarchical resource allowance	Conserved delegation of scarce quantities; supports accounting and policy.	Need formal model for divisible vs peak vs rate-limited resources.
Effect	Prepared/committed irreversible external interaction	Represents semantic crossing of rollback boundary, with authority, arguments, idempotency, settlement state, causality.	Do not model every network packet as an effect; model meaningful external transactions.

5.1 Provisional structural sketches #

Actor {
id, principal_ref, durable_state_ref, inbox_ref,
authority_root, created_by, last_commitment
}

Execution {
actor_ref, commitment_ref, world_ref, budget_ref,
architecture_state, mappings[], resource_bindings[], status
}

Commitment {
actor_ref, parent_ref?, objective_object_ref, world_ref,
budget_ref, authority_caps[], dependencies[],
deadline?, priority, state
}

Effect {
actor_ref, commitment_ref, world_ref, kind, args_object_ref,
authority_cap, idempotency_key, state
}

6. Invariants the Architecture Should Make Explicit #

These are stronger than implementation preferences. The architecture agent should restate them formally, identify which component enforces each, and design tests/proofs around them.

Authority monotonicity: rights(derived_cap) ⊆ rights(parent_cap), except where a separately authorized grant is explicitly joined.

No ambient authority: Every state/effect transition that touches protected state has a capability authorization path.

Execution independence: Destroying all Executions for Actor A does not destroy A or its durable state.

World confinement: Mutation in candidate world Wi cannot alter canonical world W0 except through an explicit merge/promotion transition.

Effect confinement: No irreversible external effect occurs without a committed Effect authorized for that semantic action.

Budget conservation: Delegated/spent resource accounting cannot exceed the parent allocation under the resource-specific conservation rule.

Causal attribution: Every persistent revision and committed effect identifies the responsible Actor and Commitment, plus enough causal references to reconstruct why it occurred.

Recovery determinism: After crash/reboot, the substrate can distinguish prepared, committed, settled, and uncertain effects without blindly repeating irreversible actions.

Promotion separation: The actor that proposes an OS successor cannot unconditionally install it; promotion is gated by an independent deterministic authority/policy.

Model independence: Unavailability or corruption of inference providers does not prevent boot/recovery or override capability enforcement.

7. Candidate Minimal Native ABI #

The current exercise intentionally restricts the ABI to approximately twenty operations to force clarity. This is not a promise that the final ABI has exactly twenty syscalls. The architecture agent should produce a rationale for every primitive and demonstrate that higher-level behavior composes from it.

/* AUTHORITY */
1 cap_derive(cap, rights, constraints) -> cap
2 cap_revoke(cap, mode) -> status

/* ACTORS + EXECUTION */
3 actor_create(identity_obj, state_obj, inbox_cap) -> actor_cap
4 actor_activate(actor_cap, commitment_cap, code_obj, bindings[]) -> execution_cap

/* RESOURCES */
5 resource_bind(execution_cap, resource_cap, specification) -> binding
6 resource_release(binding) -> status

/* COMMUNICATION */
7 channel_create(policy_obj) -> channel_cap
8 channel_send(channel_cap, payload_obj, attached_caps[]) -> event_id
9 channel_wait(channel_caps[], predicate_obj?, deadline?) -> envelope

/* STATE */
10 object_put(world_cap, predecessor?, schema, payload_region, refs[]) -> object_cap
11 object_map(object_cap, execution_cap, flags) -> memory_binding

/* WORLDS */
12 world_branch(world_cap) -> world_cap
13 world_diff(world_a, world_b) -> object_cap
14 world_merge(source, destination, merge_spec?) -> status
15 world_discard(world_cap) -> status

/* WORK */
16 commitment_create(actor_cap, objective_obj, world_cap, budget_cap, authority_caps[]) -> commitment_cap
17 commitment_delegate(parent_cap, actor_cap, objective_obj, budget_slice, authority_subset) -> commitment_cap
18 commitment_finish(commitment_cap, result_obj?, status) -> status

/* EXTERNAL REALITY */
19 effect_prepare(commitment_cap, effect_type, arguments_obj, authority_cap) -> effect_cap
20 effect_commit(effect_cap) -> status

7.1 Questions the ABI specification must answer #

• What operations are true syscalls versus protected user-space service protocols?
• Does Actor creation belong in the trusted kernel at all, or can Actor identity be represented entirely by protected objects plus a scheduler service?
• Does Object identity/lineage need kernel enforcement, or can a content-addressed object service provide it while the kernel only enforces capabilities?
• What is the minimal primitive for cross-address-space capability transfer?
• How are revocation, revocation propagation, and in-flight references handled?
• What does world_merge mean under concurrent writes and conflicting lineages?
• How does an Execution exit/yield/fault without adding a dedicated syscall?
• How are timers, interrupts, and asynchronous device completion expressed?
• Which semantics must remain local to one node and which must be network-transparent?

8. Scheduling and Runtime Model #

AOS-0 distinguishes semantic work scheduling from physical execution scheduling. The trusted substrate need not contain a “smart” scheduler; it must expose enough state and enforcement for policy services to schedule safely.

Commitment
│ "worth making progress"
▼
Actor
│ "needs an incarnation"
▼
Execution
│ "bind resources"
▼
CPU / GPU / NPU / remote node / inference provider

8.1 Commitment scheduler #

Reason over runnable/waiting/active commitments, dependencies, deadlines, priorities, budgets, and resource availability. Higher-level policies may incorporate utility or model-based decisions, but cannot manufacture authority or budget.

8.2 Execution scheduler #

Perform conventional low-level dispatch over runnable executions, cores, timers, preemption, and resource constraints. It should be intentionally boring.

9. Worlds: Core Differentiator #

World is likely the strongest differentiator from “microkernel with agents.” Agents are inherently speculative. Instead of implementing Git branches, VM snapshots, overlay filesystems, database transactions, dry-run modes, and configuration sandboxes as unrelated mechanisms, AOS-0 asks whether a common branchable-world abstraction can unify enough of them to be foundational.

W0 (canonical)
┌─────┼─────┐
▼ ▼ ▼
W1 W2 W3
idea A idea B idea C
│ │ │
└─────┼─────┘
▼
evaluate
│
merge winner

9.1 World specification must define #

• Exactly which state is world-relative: object revision maps, actor durable state, service configuration, pending commitments, capability derivations, resource bindings, effect frontier, etc.
• Whether actor identity is global while actor state is world-relative.
• How capabilities reference world-relative versus world-global targets.
• How conflicts are detected and represented during merge.
• How external observations enter candidate worlds without accidentally causing external side effects.
• How nested worlds and garbage collection work.
• Whether “world” is a kernel primitive, a protected object-store transaction abstraction, or a composition of lower primitives.

10. Effects: The Boundary Between Computation and Reality #

The architecture distinguishes reversible internal state manipulation from semantic operations whose consequences cannot be reliably undone. Effect should capture the latter at the level of intent that matters for safety/recovery, not at the level of packets or syscalls.

speculation / computation / candidate worlds
│
│ reversible
▼
──────────────── EFFECT COMMIT BOUNDARY ────────────────
│
│ externally consequential
▼
mail • purchase • publish • push
actuator • remote disclosure • production deploy

10.1 Required effect lifecycle questions #

• States: PREPARED, COMMITTED, DISPATCHED, SETTLED, FAILED, UNKNOWN? Define them precisely.
• Which state transition is the irreversible commitment point?
• How are idempotency keys generated and scoped?
• How does recovery resolve a committed-but-uncertain transaction?
• How does an Effect carry data-disclosure policy (for example, remote inference sends an Object outside the trust domain)?
• How are compound effects represented when several external systems must be coordinated?
• What operations are too low-level to deserve Effect status (for example, ordinary network retransmissions)?

11. Networking and the Distributed Machine #

Do not replace established lower-layer mechanisms merely because they predate agents. 802.11, Ethernet, IP forwarding, modern cryptography, TLS primitives, and QUIC can remain implementation substrates where appropriate. The native abstraction should change where conventional networking begins to expose human/Web-era identities and application semantics.

11.1 Native networking goal #

A native Actor should send an Object/event/capability/commitment to another Actor without knowing whether the receiver is in the same address space, on another core, on another local node, or across the Internet.

Actor A
│ channel_send(Object, capabilities, causal context)
▼
Native channel / actor fabric
▼
secure transport substrate (possibly QUIC/TLS-derived)
▼
IP / link layer / radio
▼
Actor B

11.2 Keep below the native interface #

• 802.11 / Ethernet mechanics
• IP routing
• packet retransmission
• congestion control
• TLS/cryptographic primitives where suitable
• QUIC or similar secure multiplexed transport
• legacy DNS/HTTPS gateways for external services

11.3 Do not expose natively unless justified #

• URLs as object identity
• DNS hostname as actor identity
• bearer API keys
• REST resources/methods
• HTTP request/response as the actor IPC model
• local-vs-remote send APIs
• raw cloud-model API conventions

11.4 Candidate distributed protocol vocabulary #

EVENT
OBJECT_OFFER / OBJECT_REQUEST
CAP_DELEGATE / CAP_REVOKE
COMMITMENT_DELEGATE / COMMITMENT_RESULT
EFFECT_STATUS
RESOURCE_OFFER / RESOURCE_BIND
WORLD_REF

The architecture agent should decide whether this is a network protocol, a serialization of kernel/runtime object operations, or merely an illustrative vocabulary.

12. Inference and Agent Runtime #

Inference is intentionally modeled as a resource/provider rather than as a kernel primitive that understands prompts. Actors may request a capability-bound inference class subject to privacy, cost, latency, and budget constraints. The provider may satisfy it with a local model, accelerator, remote API, cached computation, symbolic engine, or future mechanism.

Actor
│ request reasoning-class resource
▼
Inference provider
├─ local small model
├─ local accelerator
├─ remote model gateway
└─ other reasoning substrate

Remote inference may additionally require an Effect because it can disclose private object content and consume external paid quota.

13. Legacy Compatibility Model #

POSIX should be treated as a personality/compatibility environment rather than the native ontology. A legacy environment can project native state into familiar abstractions.

Native	Possible POSIX projection	Caveat
Actor	process/service	Mapping is lossy; Actor persists without a process.
Execution	thread/process	Only the temporary incarnation maps cleanly.
Object	inode/file	Path is a view, not identity.
Channel	pipe/socket/signal	Native channel should carry causality/capabilities.
Capability	FD/handle/ACL	ACLs are weaker conceptual fits.
Resource	device/FD/quota	Native Resource is broader.
World	namespace/snapshot/VM	No single POSIX equivalent.
Commitment	none	Intent/accounted work is absent in POSIX.
Effect	none	Explicit irreversible semantic transaction is absent.
Budget	rlimit/cgroup/quota	Native budget is compositional and delegated.

14. Bootstrap-1: Autonomous Self-Development Vertical Slice #

The first philosophically significant milestone is not “an agent runs on AOS.” It is “AOS can autonomously produce, verify, and promote its own successor generation under constrained authority.”

14.1 Required end-to-end loop #

1. Boot AOS-0 in a controlled hosted/QEMU environment.
2. Restore a resident Maintainer Actor and its durable state.
3. Present a deliberately failing OS behavior or test as a Commitment.
4. Maintainer inspects source/evidence Objects and may delegate sub-commitments.
5. Actors create successor source Objects in a branch/candidate World.
6. A Build service produces a bootable candidate image Object.
7. A verifier boots the candidate in an isolated test world/VM and runs deterministic tests/invariants.
8. Test results become evidence Objects causally linked to the candidate build.
9. Maintainer prepares an OS-Promotion Effect but does not possess unconditional promotion authority.
10. An independent deterministic Promotion service validates the evidence and policy.
11. If permitted, the candidate becomes the next generation / boot slot.
12. Reboot or handoff into AOS-1.
13. Query causal state to explain why AOS-1 exists and which commitment/source/build/tests/promotion produced it.
14. Introduce a second defect and require AOS-1 to produce AOS-2 through the same loop.

AOS-N
│ observe defect / receive commitment
▼
branch candidate World
▼
modify source Objects
▼
build successor image
▼
boot isolated candidate
▼
deterministic tests + invariants
├─ FAIL → discard / learn / retry
└─ PASS → prepare Promotion Effect
▼
deterministic gate
▼
AOS-N+1

15. Recommended Implementation Strategy #

Do not begin by writing a bare-metal kernel plus Wi-Fi/TCP/TLS stack. Prove the machine model first in a hosted substrate, then let the system progressively replace the scaffolding.

15.1 Phase H0 — Hosted semantic prototype #

• Linux host supplies processes, storage, networking, compiler, QEMU, and model API access.
• AOS runtime exposes only native Actor/Capability/Object/World/Commitment/Effect/Channel abstractions to resident agents.
• Legacy host mechanisms are deliberately hidden behind resource providers/bridges.
• Close AOS-0 → AOS-1 → AOS-2 recursive loop before pursuing hardware breadth.

15.2 Phase H1 — Bootable target substrate #

• Move enforcement-sensitive primitives onto a minimal microkernel/exokernel-like substrate or custom kernel.
• Use QEMU virtio devices initially.
• Retain host bridge for inference/build where necessary, but preserve the native interface.

15.3 Phase H2+ — Eat the scaffolding #

host compiler → native Build service
host object store → native persistent Object service
host networking → native network/path service
host model gateway → native inference provider/gateway
host VM manager → native candidate-world execution service
legacy boot tooling → generational A/B promotion + recovery root

16. Trusted Computing Base and Promotion Safety #

AOS may evolve aggressively, but it should not be able to erase the last mechanism capable of rejecting or rolling back a bad generation. Prefer generational replacement over self-modifying the currently executing trusted core.

Immutable / separately governed Recovery Root
├─ signature / image verification
├─ boot slot selection
├─ watchdog / rollback
├─ minimal promotion policy root
└─ hardware bootstrap
│
▼
AOS-N
│ proposes + proves
▼
AOS-N+1

16.1 Important separation of powers #

• Maintainer Actor may inspect and modify candidate source state.
• Maintainer may build and test candidates.
• Maintainer may prepare a promotion request/effect.
• Maintainer must not have unconditional authority to install its own candidate.
• Promotion gate should be deterministic and separately protected.
• Recovery root should be small enough to audit/formally reason about and should retain a last-known-good path.

17. Native Development Representation #

For the final model, source code should not conceptually be “files edited by an agent.” It should be versioned source Objects with lineage and causal metadata. A POSIX checkout may be an implementation projection used by legacy compilers during bootstrap.

Source Object S193
schema: source.rust.module
logical_identity: kernel.capability
predecessor: S187
created_by: Maintainer Actor
commitment: C71

S193 → S204 → S219 (lineage)

Build products should likewise be causal artifacts: source root + compiler identity + build graph + configuration + reproducibility evidence → image Object.

18. Required Source-of-Truth Deliverables #

The receiving architecture agent should produce a coherent document set. Prefer normative, cross-linked Markdown or another machine-readable text format suitable for both agents and humans. The following files are recommended.

Artifact	Required content
00-VISION.md	Problem statement, thesis, principles, non-goals, litmus tests.
01-MACHINE-MODEL.md	Canonical definition of Actor, Execution, Object, World, Capability, Channel, Commitment, Budget, Resource, Effect; identity and lifecycle.
02-TRUST-AND-AUTHORITY.md	Capability model, delegation, attenuation, revocation, principals, trust roots, threat model, invariants.
03-STATE-AND-WORLDS.md	Persistent state model, object lineage, world branching/diff/merge/conflicts/GC, canonical world semantics.
04-COMMITMENTS-AND-SCHEDULING.md	Commitment lifecycle, dependencies, deadlines, scheduling interfaces, failure/cancellation/delegation.
05-EFFECTS.md	Effect taxonomy and state machine, idempotency, recovery, settlement, disclosure, compound effects.
06-ABI.md	Normative native syscall/protocol surface with preconditions, postconditions, errors, rights required, concurrency rules.
07-IPC-AND-NETWORK.md	Local/remote channel semantics, capability transfer, actor resolution, wire protocol, transport substrate, legacy gateways.
08-RESOURCE-MODEL.md	CPU/memory/device/inference/network/storage/power resources; binding and budget semantics.
09-BOOT-RECOVERY-PROMOTION.md	Boot state restoration, recovery root, generational upgrades, A/B slots, rollback, promotion gate.
10-SELF-HOSTING.md	Bootstrap-1 vertical slice, source/build/test representation, agent maintenance loop, required evidence.
11-COMPATIBILITY.md	POSIX/Linux personality, filesystem projection, legacy networking/HTTPS/model gateways.
12-THREAT-MODEL.md	Adversaries, confused-deputy risks, prompt/model compromise, capability leakage, malicious candidate OS, supply chain.
13-TEST-STRATEGY.md	Executable invariants, fault injection, fuzzing, crash recovery, determinism, model-independent tests.
14-PROTOTYPE-PLAN.md	Hosted prototype → bootable target → scaffolding removal milestones; dependencies and acceptance criteria.
GLOSSARY.md	Exact terminology. Ban synonyms that blur Actor/Execution/Commitment/Effect distinctions.
ADR/	Architecture Decision Records for every major fork, including rejected alternatives and reasons.
SCHEMAS/	Machine-readable schemas/state machines/interfaces where possible.

19. Open Architecture Decisions #

These are explicitly unresolved. The architecture agent should not guess silently; it should decide them through ADRs, experiments, or mark them as deferred with a clear dependency.

Kernel boundary: Which of the ten candidate objects are true kernel objects versus protected user-space services? How small can the trusted core remain?

Substrate choice: Hosted runtime first is recommended. For the native target, seL4/Microkit, another capability microkernel, exokernel-like design, or custom kernel?

Actor identity: Globally stable cryptographic identity? Object identity? How are aliases and principal relationships represented?

Actor concurrency: May one Actor have multiple concurrent Executions? If yes, what synchronizes durable state updates?

Capability algebra: Rights, constraints, delegation, revocation, expiry, joins, derivation graphs, cross-node representation.

World semantics: Kernel primitive or object-store transaction? Scope of state; merge algorithm; conflict handling; resource/effect relationship.

Object model: Content-addressed immutable blobs plus metadata? Typed schemas? Logical lineage identity separate from revision identity?

Commitment semantics: What must be kernel-visible? Are priorities/deadlines trusted data? How is cancellation propagated?

Budget algebra: How to model consumables, reservations, peak resources, rates, money, battery, shared allocations, refunds.

Effect taxonomy: What qualifies as external/irreversible? Network send vs semantic API transaction; file on removable media; physical actuator; disclosure.

Networking identity: How are Actors/Resources discovered and authenticated across nodes? What remains location-independent?

Transport: QUIC/TLS-derived transport versus new secure channel protocol; mapping of capabilities and causal envelopes to wire representation.

Persistence: Crash-consistent store and recovery protocol for Actors/Objects/Worlds/Effects; garbage collection and compaction.

Promotion root: What is immutable or separately governed? Can the promotion policy itself evolve, and under what meta-policy?

Compiler trust: Reproducible builds, diverse compilation, Trusting Trust mitigations, signed toolchain Objects.

Remote inference: When is it a Resource binding versus an Effect due to disclosure/cost? How are privacy constraints mechanically enforced?

Human principal: How does a human authenticate/grant authority without reintroducing login/session semantics into the native model?

Distributed world: Can a World span nodes? What consistency model is required? Which references survive partition/migration?

Garbage collection: When can dormant Actors, old Object revisions, discarded Worlds, stale capabilities, and causal history be collected?

Compatibility: How much Linux/POSIX should be guest VM versus personality/server versus external tool bridge?

20. Explicit Non-Goals for Bootstrap-1 #

• A general-purpose desktop OS.
• A graphical user interface or human-first shell.
• Broad hardware support.
• Native Wi-Fi, USB, GPU, NVMe, browser, audio, or full TCP/IP stacks before the ontology is proven.
• Perfect distributed consensus or Internet-scale federation.
• Eliminating all legacy host infrastructure in the first prototype.
• Putting an LLM in ring 0 or letting language-model output directly authorize privileged actions.
• Autonomously patching the currently executing trusted kernel in place.
• Claiming autonomous “self-improvement” merely because an agent can edit code. The recursive build/test/promotion loop must close.

21. Bootstrap-1 Acceptance Criteria #

A demo counts only if all required conditions are observable and machine-verifiable. Suggested pass criteria:

• AOS-0 boots reproducibly in the designated test environment.
• A resident Actor exists independently of any single Execution and can be restored after restart.
• Capabilities gate source modification, build/test access, and promotion separately.
• Source state is represented through versioned native Objects or a faithful prototype of that model.
• A candidate World can diverge from canonical state without mutating canonical state.
• A Maintainer Actor can diagnose a seeded failure and create a successor source revision without human edits.
• A build service produces a bootable successor image with machine-readable build provenance.
• The successor boots in an isolated test environment and produces deterministic evidence.
• Promotion fails if required evidence is missing or invalid, even if the Maintainer requests it.
• Promotion succeeds when policy requirements are met.
• After promotion, AOS-1 boots and exposes the causal chain from original commitment through source/build/test/promotion.
• AOS-1 repeats the same autonomous loop to produce AOS-2 after a second seeded defect.
• A model outage cannot bypass promotion or corrupt authority; it only stalls model-dependent work.
• A crash during an Effect/promotion transition recovers to an unambiguous safe state or explicitly UNKNOWN state requiring resolution; it does not silently repeat irreversible work.

22. Suggested Repository Shape for Agent-First Development #

/spec
00-VISION.md
01-MACHINE-MODEL.md
...
ADR/
SCHEMAS/

/prototype
runtime/
object-store/
worlds/
capabilities/
effects/
agent-harness/
build-bridge/
qemu-harness/
verifier/

/tests
invariants/
state-machines/
fault-injection/
boot/
recursive-self-host/

/tools
spec-lint/
trace-inspect/
image-build/

AGENTS.md
ARCHITECTURE.md
ROADMAP.md

22.1 Repository design rule #

The repository must be legible to autonomous coding agents: every architectural invariant should map to an executable test or check where practical, and every subsystem should expose machine-readable success/failure rather than require visual inspection.

23. Ready-to-Use Planning-Agent Mission #

The following can be copied into the planning/architecture agent as its top-level assignment after attaching this document:

Design AOS-0 from this brief. First produce the canonical source-of-truth architecture and resolve contradictions before implementation. Preserve the project thesis: autonomous Actors, not humans or POSIX processes, are the native inhabitants; the trusted substrate enforces authority, causal state, branchable worlds, budgets, commitments, and irreversible effects without probabilistic reasoning. Produce the document set in Section 18, a decision log for unresolved issues, machine-readable state machines/interfaces where useful, and a staged Bootstrap-1 implementation plan whose first conclusive milestone is autonomous AOS-0 → AOS-1 → AOS-2 generation under deterministic promotion policy. Treat legacy Linux/POSIX/Web mechanisms as bootstrap/compatibility substrate unless you can justify them as native abstractions.

24. Prior Art and Research Anchors #

These references are not specifications for AOS-0. They are anchors the architecture agent should study, contrast, and cite where relevant. Their value is in mechanisms and lessons, not in copying their ontologies.

seL4 capabilities: Capability-based authority; unforgeable tokens and explicit rights over kernel objects/resources. Source

Exokernel: Separation of secure resource protection from application-level policy and abstractions. Source

Orleans virtual actors: Logical actor identity that conceptually persists independently of the server currently executing it. Source

SPIFFE / SVIDs: Workload identity and cryptographic authentication not centered on human user accounts. Source

QUIC (RFC 9000): Secure multiplexed transport substrate with streams and connection migration; useful beneath an actor-native protocol. Source

Jordan Hubbard agentOS: Adjacent 2026 project: seL4-based bare-metal OS explicitly designed for agents, with capability-gated services and a self-redesign goal. Useful comparison point; AOS-0 should clearly articulate where its Actor/World/Commitment/Effect ontology goes further or differs. Source

24.1 Important competitive/adjacent-project note #

As of August 2026, the public agentOS repository describes itself as a seL4-based operating system for agents rather than humans, with capability-gated agent identity, model/tool/storage/network services, and an intended self-redesign/hot-swap layer. Its own documentation states that many higher-level services remain host-tested scaffolding rather than boot-proven target behavior. AOS-0 should not compete by merely reproducing that service stack. The differentiating research question should remain the deeper machine model: durable Actor versus Execution, branchable World, explicit Commitment, causal Object lineage, hierarchical Budget, and irreversible Effect semantics.

25. Glossary Seed #

Term	Working definition
Actor	Durable autonomous identity/state entity. Never use as a synonym for process or model invocation.
Execution	Temporary physical computation on behalf of an Actor and Commitment.
Principal	Entity on whose authority actions ultimately rest (human, organization, device, actor collective). May be represented by ordinary identity Objects rather than a dedicated kernel class.
Capability	Unforgeable authority token with explicit target, rights, constraints, derivation, and revocation semantics.
Commitment	Explicit unit of autonomous work and accounting; objective content can be opaque to the kernel.
World	Branchable system-state context in which speculative actions can occur without mutating canonical reality.
Canonical world	The promoted/authoritative world whose persistent state represents current system reality.
Object	Immutable persistent state revision with identity/lineage/causal metadata.
Resource	Scarce compute, hardware, service, or external capacity that can be bound/allocated under authority and budget.
Budget	Hierarchical accountable allowance over one or more resource dimensions.
Effect	Explicit semantic operation crossing the rollback boundary into externally consequential reality.
Promotion	Deterministically authorized transition that makes a candidate world/image/generation canonical.
Native	Expressed in the AOS machine model without relying on POSIX/Web concepts at the Actor-facing interface.
Compatibility personality	Environment that projects AOS-native objects into legacy abstractions such as POSIX files/processes/sockets.
Bootstrap bridge	Temporary host implementation behind a native interface; acceptable while proving the architecture.

26. Architecture-Agent Completion Checklist #

• The source-of-truth docs have one unambiguous definition for every native object.
• Every state machine identifies valid transitions, required capabilities, error behavior, and recovery semantics.
• Every invariant states which component enforces it and how it is tested.
• The kernel/TCB boundary is justified rather than inherited from the initial sketch.
• World scope and merge semantics are precise enough to implement.
• Effect semantics are precise enough to survive crash/retry without accidental duplicate actions.
• Capability delegation/revocation is precise enough to prevent confused-deputy privilege amplification.
• Local and remote Actor interaction share one conceptual API.
• Inference is replaceable and non-essential to boot/recovery.
• POSIX/Web concepts appear only in compatibility/bridge documents unless an ADR explicitly admits one natively.
• Bootstrap-1 can be implemented without broad hardware support.
• AOS-0 → AOS-1 → AOS-2 acceptance tests are specified before coding begins.
• The project can explain in one page why it is not “Linux with an agent runtime” and why it is distinct from adjacent agent-OS projects.

If the architecture becomes easier to explain by saying “it is basically Linux/seL4 plus an agent daemon,” stop and revisit the ontology. The project succeeds only if the abstractions are independently useful for autonomous computation even when the implementations underneath remain conventional during bootstrap.