autogenic.transductive.scienceRESEARCH OBJECT · 2026-08-08
A realized architecture for AI + operating systems

THE OS SHOULD GROW.

AI should not sit on top of the operating system pretending to be a user. It should be able to propose, test, install, replace and repair software beneath the interface—while a smaller trusted layer keeps identity, scope and rollback intact.

Three 2026 systems papers make the practical pieces unusually concrete: source-level agent mutation, intent-bound execution, and replayable proof of what actually happened. Older work on live update, recovery and transactional operating systems shows that the replacement mechanics themselves have a long history. The new move is joining those mechanics to conversational reasoning.

Abstract plate: an immutable governor around a blue capability aperture Abstract plate: a continuous generate, probe and return loop Abstract plate: state carried from one software generation into another
01Generate02Probe03Stage04Swap05Reload06Resume
01 / CLAIM
AI integration beyond the assistant

Stop giving the machine a mouse.

A model that can write software and inspect execution should not always have to manipulate a finished interface as though its hands were tied behind its back.

Recent self-improving agent work has already crossed an important boundary: the thing being changed can be executable code, not only a prompt or memory file. MOSS pushes that argument directly into a production harness and checks candidate rewrites inside temporary trial workers before swapping the running container.

The Autogenic Operating System takes the same move toward the personal computer. A conversation becomes an engineering control surface. The model produces a candidate capability; the machine tests it under bounded conditions; a resident process promotes or rejects it; successful software becomes part of the environment that the next turn can use.

02 / REALIZED
Browser layer

The loop is already smaller than an operating system.

The first useful AOS does not rewrite its kernel. It keeps a tiny resident governor fixed and lets the software around it mutate.

That split follows a practical pattern seen repeatedly elsewhere: preserve the component that owns recovery authority while replacing the component that is supposed to evolve. MOSS places its host daemon outside the container it may replace. Crash-only and microreboot work similarly make restart boundaries cheap. Kitsune makes version-to-version state transformation explicit.

01Generate→
02Compile / probe→
03Stage→
04Mutate→
05Reload→
06Resume→
03 / THREE PAPERS
Reverse integrated

Three papers supply three different missing muscles.

PAPER 01 · 2026
Three isolated trial-worker chambers

MOSS gives the body permission to change.

MOSS argues that structural failures live in code: routing, hooks, dispatch and state invariants are outside the reach of prompt-only evolution. It rewrites source, replays failure evidence in ephemeral workers, then swaps the container only after a health check.

AOS borrowing: mutable application substrate + supervisor outside the thing being replaced + last-known-good rollback.
OPEN PAPER ↗
PAPER 02 · 2026
Immutable governor plate

OpenKedge gives mutation a contract.

OpenKedge turns a requested state change into a declarative intent, derives current context, evaluates policy, and compiles an approved proposal into a bounded execution contract with short-lived authority.

AOS borrowing: “AI may change the machine” becomes a scoped execution capability, not a permanent blank cheque.
OPEN PAPER ↗
PAPER 03 · 2026
Linked execution evidence blocks

Proof of Execution gives the change a memory.

Proof of Execution binds a contract, an execution-event stream and replay context. It separates planning, enforcement, effect and recording, then validates whether the recorded trajectory satisfies its runtime invariants.

AOS borrowing: every accepted mutation leaves a trajectory that can be checked instead of a reassuring terminal transcript.
OPEN PAPER ↗
SOURCE-LEVEL EVOLUTION+EXECUTION-BOUND AUTHORITY+REPLAYABLE EVIDENCE=A PRACTICAL AUTOGENIC LOOP
IMPORTANT DISTINCTION

The papers do not jointly prescribe an immutable Go daemon. That is this project’s engineering synthesis. MOSS supplies unusually direct support for an out-of-container host supervisor. OpenKedge and Proof of Execution supply governance and trace ideas. Go is simply a compact implementation choice for a resident that should be boring, portable and difficult to accidentally replace.
04 / BOUNDARY
Keep one thing boring

Immutable governor. Mutable organism.

THE RESIDENT DOES NOT EVOLVE.

It owns the authority that evolving code must not silently inherit.

  • local machine identity and keys
  • intent / contract validation
  • sandbox launch
  • artifact staging and atomic replacement
  • last-known-good state
  • health confirmation and rollback
In the practical v1 design, this is a tiny Go binary. Its replacement is an explicit maintenance event outside the self-mutation loop.

EVERYTHING ABOVE IT MAY CHANGE.

That is where the system earns the word “autogenic.”

  • MV3 extension and userscripts
  • site adapters and agent harnesses
  • local CLI tools and workers
  • containers and service images
  • eventually packages and selected OS components
The trusted root should stay smaller than the space it governs. Work on seL4, SPIN, gVisor and microVMs shows several different ways of shrinking or isolating the part that must remain trustworthy.
05 / THREE LAYERS
Expansion by evidence

Grow downward only after the layer above survives.

Layer 1 · browser · project-verified

Replace a live extension, then continue.

Autogenic loop plate

The browser is the first mutation surface because failure is cheap and restart is bounded.

  1. generate a candidate worker
  2. compile and probe in MV3 sandbox
  3. stage source beside known-good bytes
  4. atomically replace unpacked extension files
  5. reload extension generation
  6. resume durable plan and report evidence
Layer 2 · container · immediate target

Replace the service, preserve the user state.

Trial workers plate

This is where MOSS is directly informative. Candidate images can be tested against held-out failures in disposable workers before a resident swaps the service.

  1. capture failure batch
  2. rewrite source
  3. build candidate image
  4. replay held-out regression set
  5. health-probe promoted image
  6. rollback on failed confirmation
Layer 3 · OS substrate · research target

Change the operating system without gambling the machine.

Operating system root and branching mutable layers

Here AOS stops being mainly an agent problem and meets decades of dynamic-update and transactional-update engineering.

  1. prepare candidate in clone or inactive deployment
  2. reproduce exact failure
  3. verify replacement and state migration
  4. activate through livepatch or bootable generation
  5. retain a bootable rollback path
06 / LINEAGE
This did not begin with LLMs

The pieces existed. The conversational join is new.

SPIN: safe extensibility inside the OS.

Protected extensions challenged the assumption that an operating-system kernel had to be functionally frozen.

Autonomic computing: monitor, analyze, plan, execute.

IBM’s programme framed self-configuration, self-healing, self-optimization and self-protection as explicit system goals.

Recovery-oriented and crash-only systems.

The system boundary changes when restart becomes cheap, local and expected rather than exceptional.

Dynamic software update becomes practical machinery.

K42, Ksplice and Kitsune explore live code replacement, persistent state and version transitions.

Transactional software makes rollback ordinary.

A/B system slots, OSTree, RAUC and Guix make “old or new, never half-updated” an achievable update property.

Cheap isolation shrinks the cost of trying.

MicroVMs and stronger container sandboxes create disposable execution surfaces for untrusted candidates.

The generator begins editing the generator.

Self-improving coding agents, open-ended agent evolution, harness search and MOSS turn source code itself into the adaptation medium.

07 / INERTIA
Useful work while absent

Idle time becomes a safe experimental budget.

A self-extending computer should not stop thinking the instant the keyboard goes quiet.

While the user is away, the resident can spend bounded idle cycles on non-destructive work: reproduce failures in clones, fuzz candidate code, pre-build likely variants, fetch documentation already requested, or compress the day’s execution evidence into a better next prompt.

The governance lesson from current agent-safety work is not “ask for confirmation every minute.” It is to bind authority to the actual effect. Read-only and disposable experiments can run under a standing low-risk capability; durable mutations cross a harder gate and leave evidence.

08 / STATUS
Say exactly what exists

Browser proof now. OS proof later.

resident.spawn_child
        ↓
extension.self_modify(session_worker.js)
        ↓
MV3 candidate compile
        ↓
bounded probe: PASS
        ↓
resident backup + atomic replace
        ↓
generation 1 → 2
        ↓
chrome.runtime.reload()
        ↓
new worker heartbeat
        ↓
durable plan resumes
        ↓
{"echo":"after-reload","generation":2}
Project verifiedExtension source can cross a compile/probe → atomic replace → reload → resume boundary in the existing project record.
Paper verifiedMOSS demonstrates source-level agent-harness rewriting and trial-worker validation before a container swap.[1]
Research-backedDynamic OS updates, live kernel patching, A/B updates and transactional deployments establish multiple replacement and rollback mechanisms.[21][25][27]
Still openGeneral, autonomous Debian-package / driver / kernel mutation with automatic fault reproduction, safe state migration and dependable rollback.
09 / VISUAL METHOD
Image-first pipeline test

The page was assembled from a cut-board before it was styled.

One extracted plate from the deterministic image cut-board

This run exercised the production method using a deterministic surrogate image because the ChatGPT Image 2.0 generation tool was not exposed to this session. The downstream path is real: one raster board, pure-magenta structural rails, coordinate detection, ImageMagick crops, six separate PNG elements, then Chromium layout verification.

INTERNAL VM
Debian 13
Chromium 144
ImageMagick 7.1.2

BOARD
1800 × 1200
2 × 3 cells
8 px #FF00FF rails

PIPELINE
source board
→ rail detection
→ crop geometry
→ ImageMagick slicing
→ six PNG plates
→ semantic HTML/CSS
→ Chromium desktop + mobile
→ fit assertions

RESULT WRITTEN BY VERIFY SCRIPT
10 / REFERENCES
Reverse reference integration

The bibliography came first. Then it was wired upward into the story.

Select a reference to highlight the story passages that currently depend on it. This makes citation coverage visible as a relation, not a decoration at the bottom of the page.

  1. [01]
    2026
    MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent SystemsQianshu Cai et al. · arXiv
    Source-level self-rewriting, trial workers, host-resident supervisor, health-gated container swap and rollback.
    SOURCE ↗
  2. [02]
    2026
    OpenKedge: Governing Agentic Mutation with Execution-Bound Safety and Evidence ChainsJun He, Deying Yu · arXiv
    Declarative intent, execution contracts, ephemeral task identities and intent-to-execution evidence chains.
    SOURCE ↗
  3. [03]
    2026
    Proof of Execution: Runtime Verification for Governed AI Agent ActionsJames Rhodes, George Kang · arXiv
    Contract-bound execution traces, authority-plane separation, replay and validator-checkable attestation.
    SOURCE ↗
  4. [04]
    2026
    Self-Harness: Harnesses That Improve ThemselvesHangfan Zhang et al. · arXiv
    Models improve their operating harness from traces; candidate edits survive regression tests.
    SOURCE ↗
  5. [05]
    2025
    Darwin Gödel Machine: Open-Ended Evolution of Self-Improving AgentsJenny Zhang et al. · arXiv
    Open-ended code self-modification with empirical benchmark validation and an archive of descendants.
    SOURCE ↗
  6. [06]
    2025
    A Self-Improving Coding AgentMaxime Robeyns, Martin Szummer, Laurence Aitchison · arXiv
    A coding agent edits its own implementation and validates gains on coding benchmarks.
    SOURCE ↗
  7. [07]
    2025
    GEPA: Reflective Prompt Evolution Can Outperform Reinforcement LearningLakshya A. Agrawal et al. · arXiv
    Evolutionary reflection over execution trajectories; useful contrast with source-level mutation.
    SOURCE ↗
  8. [08]
    2025
    Automated Design of Agentic SystemsShengran Hu et al. · ICLR 2025
    Meta Agent Search explores agent designs in executable code space.
    SOURCE ↗
  9. [09]
    2025
    MetaAgent: Automatically Constructing Multi-Agent Systems Based on Finite State MachinesYaolun Zhang, Xiaogeng Liu, Chaowei Xiao · ICML 2025
    Automatic generation of multi-agent structures rather than fixed human orchestration.
    SOURCE ↗
  10. [10]
    2026
    Runtime Compliance Verification for AI AgentsNafiseh Kahani, Masoud Barati, Diana Addae · arXiv
    Runtime interception of tool use against formal policy predicates.
    SOURCE ↗
  11. [11]
    2024
    AIOS: LLM Agent Operating SystemKai Mei et al. · arXiv
    An operating-system-style kernel for scheduling, context, memory, storage and access control for agents.
    SOURCE ↗
  12. [12]
    2024
    OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer EnvironmentsTianbao Xie et al. · arXiv
    Execution-based benchmark for GUI-operating agents; a useful contrast with source-integrated adaptation.
    SOURCE ↗
  13. [13]
    2026
    OSWorld2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World TasksMengqi Yuan et al. · arXiv
    Long-horizon computer-use workflows expose state-tracking and verification failures.
    SOURCE ↗
  14. [14]
    2025
    OSWorld-MCP: Benchmarking MCP Tool Invocation In Computer-Use AgentsHongrui Jia et al. · arXiv
    Measures tool invocation alongside GUI control.
    SOURCE ↗
  15. [15]
    2003
    The Vision of Autonomic ComputingJeffrey O. Kephart, David M. Chess · IEEE Computer
    Classic statement of self-managing computing under high-level human objectives.
    SOURCE ↗
  16. [16]
    2004
    An Architectural Approach to Autonomic ComputingSteve R. White et al. · ICAC 2004
    Self-configuration, self-optimization, self-healing and self-protection as architectural properties.
    SOURCE ↗
  17. [17]
    2005
    Self-managing systems: A control theory foundationYixin Diao et al. · IEEE ECS 2005
    Control-theoretic foundation for self-management.
    SOURCE ↗
  18. [18]
    2003
    Crash-Only SoftwareGeorge Candea, Armando Fox · HotOS IX
    Designing components to stop and recover cleanly makes replacement and restart cheaper.
    SOURCE ↗
  19. [19]
    2002
    Recovery Oriented Computing: Motivation, Definition, Techniques, and Case StudiesDavid Patterson et al. · UC Berkeley Technical Report
    Treat recovery speed and maintainability as first-class system metrics.
    SOURCE ↗
  20. [20]
    2004
    Microreboot—A Technique for Cheap RecoveryGeorge Candea et al. · OSDI 2004
    Fine-grained restart recovers components without rebooting the entire application.
    SOURCE ↗
  21. [21]
    2005
    Providing Dynamic Update in an Operating SystemAndrew Baumann et al. · USENIX ATC
    K42 applies code and data-structure updates to a running OS.
    SOURCE ↗
  22. [22]
    2007
    Reboots Are for Hardware: Challenges and Solutions to Updating an Operating System on the FlyAndrew Baumann et al. · USENIX ATC
    Explores interface and state challenges in live OS update.
    SOURCE ↗
  23. [23]
    2012
    Kitsune: Efficient, General-purpose Dynamic Software Updating for CChristopher M. Hayden et al. · OOPSLA
    Whole-program replacement with explicit state transformation from old version to new.
    SOURCE ↗
  24. [24]
    2009
    Ksplice: Automatic Rebootless Kernel UpdatesJeff Arnold, M. Frans Kaashoek · EuroSys
    Transforms many ordinary kernel security patches into live updates at object-code level.
    SOURCE ↗
  25. [25]
    2026
    Linux Kernel Livepatch DocumentationLinux kernel community · kernel.org
    Kernel runtime patch lifecycle: load, enable, replace, disable and remove.
    SOURCE ↗
  26. [26]
    2026
    Atomic Replace & Cumulative PatchesLinux kernel community · kernel.org
    Cumulative livepatches replace older function implementations in one transition.
    SOURCE ↗
  27. [27]
    2026
    A/B (seamless) system updatesAndroid Open Source Project · AOSP
    Updates inactive slot while current system remains available; boot failure falls back to old slot.
    SOURCE ↗
  28. [28]
    2026
    Atomic UpgradesOSTree project · OSTree Documentation
    Atomic transitions between bootable deployments: after failure you have old or new, not half-updated.
    SOURCE ↗
  29. [29]
    2026
    RAUC BasicsRAUC project · RAUC Documentation
    Signed bundles, verification, robust installation and boot integration for unattended Linux updates.
    SOURCE ↗
  30. [30]
    2024
    GNU Guix Reference ManualGNU Project · GNU Guix
    Transactional package/profile generations with rollback and reproducible provenance.
    SOURCE ↗
  31. [31]
    2026
    seL4 White PaperseL4 Foundation · seL4
    A minimal capability-based microkernel as a high-assurance trusted foundation.
    SOURCE ↗
  32. [32]
    1995
    Extensibility, Safety and Performance in the SPIN Operating SystemBrian Bershad et al. · SOSP 1995
    Protected in-kernel extensibility and dynamic binding without making the entire system static.
    SOURCE ↗
  33. [33]
    2020
    Firecracker: Lightweight Virtualization for Serverless ApplicationsAlexandru Agache et al. · NSDI 2020
    Minimal microVM monitor for high-density isolated trial execution.
    SOURCE ↗
  34. [34]
    2021
    The Endokernel: Fast, Secure, and Programmable Subprocess VirtualizationBumjin Im et al. · arXiv
    An extensible monitor nested inside a process for least-authority sub-process abstractions.
    SOURCE ↗
  35. [35]
    2026
    What is gVisor?gVisor project · gVisor Documentation
    Userspace application kernel that mediates container system calls and reduces host-kernel exposure.
    SOURCE ↗
  36. [36]
    2026
    Kata ContainersKata Containers project · OpenInfra
    Lightweight VM-backed container runtime for stronger isolation.
    SOURCE ↗
  37. [37]
    2019
    in-toto: Providing farm-to-table guarantees for bits and bytesSantiago Torres-Arias et al. · USENIX Security 2019
    Cryptographically verifies the sequence of steps in a software supply chain.
    SOURCE ↗
  38. [38]
    2026
    SLSA: Supply-chain Levels for Software ArtifactsOpenSSF · SLSA
    Provenance and build-integrity framework for software artifacts.
    SOURCE ↗
  39. [39]
    2026
    The Update Framework SpecificationTUF community · TUF
    Signed metadata architecture designed to make software update systems resilient to repository/key compromise.
    SOURCE ↗
  40. [40]
    2026
    Rekor Transparency LogSigstore project · Sigstore
    Immutable, tamper-resistant public ledger for signed software supply-chain metadata.
    SOURCE ↗
  41. [41]
    2013
    PROV-DM: The PROV Data ModelW3C Provenance Working Group · W3C Recommendation
    Standard vocabulary for entities, activities, agents and derivations.
    SOURCE ↗
  42. [42]
    2021
    RFC 9162: Certificate Transparency Version 2.0Ben Laurie, Emilia Messeri, Rob Stradling · IETF
    Auditable append-only Merkle logs; a useful lineage for transparent mutation records.
    SOURCE ↗
  43. [43]
    2009
    Efficient Data Structures for Tamper-Evident LoggingScott A. Crosby, Dan S. Wallach · USENIX Security 2009
    Authenticated data structures for detecting log tampering.
    SOURCE ↗
  44. [44]
    2026
    Open Policy Agent DocumentationOPA project · CNCF
    Separates declarative policy decision-making from enforcement.
    SOURCE ↗
  45. [45]
    2024
    Cedar: A New Language for Expressive, Fast, Safe AuthorizationCedar authors · OSDI 2024
    Policy language designed for analyzable, high-performance authorization.
    SOURCE ↗
  46. [46]
    2009
    A Brief Account of Runtime VerificationMartin Leucker, Christian Schallhart · Journal of Logic and Algebraic Programming
    Foundational survey of checking execution traces against specifications at runtime.
    SOURCE ↗
  47. [47]
    2025
    A Note on Runtime Verification of Concurrent SystemsMartin Leucker · arXiv
    Trace-aware monitoring for concurrent systems.
    SOURCE ↗
  48. [48]
    2019
    Runtime Verification For Timed Event Streams With Partial InformationMartin Leucker et al. · arXiv
    Runtime reasoning even when observed traces contain gaps.
    SOURCE ↗
  49. [49]
    2026
    BPF DocumentationLinux kernel community · kernel.org
    Programmable kernel instrumentation substrate relevant to observation, policy and crash evidence.
    SOURCE ↗
  50. [50]
    2021
    BPF for storage: an exokernel-inspired approachYu Jian Wu et al. · arXiv
    Example of safely injecting programmable logic deep into kernel data paths.
    SOURCE ↗
  51. [51]
    2026
    Autogenic Operating System — Realized Architecturetransductive.science · Project implementation record
    The project-specific synthesis: conversation artifact → live browser probe → immutable resident → atomic swap → reload → resume → evidence return.
    IN THIS OBJECT
  52. [52]
    2026
    Transductive Publishing and Visual Execution Master Guidetransductive.science · Project operating guide
    Cut-board, Chromium acceptance, deterministic build and reversible publication procedure used by this page.
    IN THIS OBJECT
  53. [53]
    2026
    ChatGPT Internal Image Generation 2.0 Master Guidetransductive.science · Project operating guide
    Image-first production contract and Ralph Wiggum visual iteration method; the Image generation tool itself was unavailable in this run.
    IN THIS OBJECT