What is Autonomic about WunderOS

Kendall Clark · Pentad Labs · 27 July 2026 · PLRN-021

The function of freedom is to free someone else.

— Toni Morrison, Barnard College commencement speech (1979)

Abstract

We call WunderOS an autonomic, agentic OS. What does that really mean?

In short, WunderOS is an operating system for agents that senses, schedules, heals, scales, reloads, protects, and improves the conditions under which the agents act.

WunderOS is autonomic because its services are closed control loops over agents, substrate, workload, policy, and recovery. The word does not mean that the system acts without people in every case. It means that every ordinary management function has the form plant, sensor, controller, actuator, and knowledge, and that the loop acts on the system itself. The agent remains the worker.

Autonomic is, therefore, an architectural claim; it’s not a synonym for automation. Automation executes a known step without a person. Autonomy chooses within a bounded space. An autonomic operating system manages that bounded space, changes it when the evidence warrants change, and leaves a record that can be replayed.

WunderOS is autonomic just where its management loops close over themselves:

This note states what those loops are and what the claim of autonomy excludes.

1. Autonomic is not automatic

An automatic system performs an action when its condition is met. A cron job is automatic. A retry loop is automatic. A static autoscaling rule is automatic. These are useful but not yet autonomic.

An autonomic system is a managed system whose management is itself a running part of the system. It observes the plant it controls. It compares what it sees with a specification, objective, or policy. It acts on the plant. It remembers what it saw and what it did, so that later control actions are informed by earlier ones. This is the classic shape of autonomic design, which is called “MAPE-K”:

WunderOS is committed architecturally, with respect to its use of LLMs and other models in its control plane, in the older and more exact language of supervisory control: plant, sensor, controller, actuator.

The modern computing use of “autonomic” comes through IBM’s autonomic computing program: self-configuring, self-healing, self-optimizing, self-protecting systems organized around MAPE-K. WunderOS adopts that vocabulary and system-design shape deliberately.

The difference is the plant. IBM’s frame was directed chiefly at managing computing infrastructure. WunderOS applies the same control requirement to agents and to the operating-system substrate that hosts them: memory, policy, execution, recovery, replay, and harness improvement.

The point is not the name of the diagram. The point is closure. If the system cannot sense itself, it cannot govern itself. If it can sense itself but cannot act, it is a dashboard. If it can act but cannot remember why, it is an unaccountable script. If it can remember but not replay, it is a diary, not a control system.

The system begins to be autonomic only when the whole path exists.

This matters especially for agents because the thing being controlled is not a single process with a fixed meaning. An enterprise agent is a userland program with external tools, memory, policy, budgets, tenants, and liability. Its mistakes are not merely wrong return values. They are writes, messages, approvals, disclosures, costs, and missed deadlines. A harness that helps one agent call one model is too small a thing to manage that surface. The control loop has to sit around the agent and the substrate that hosts the agent.

That is why the right claim is OS-shaped. An operating system hosts and mediates programs. An autonomic operating system also manages the conditions of hosting. It allocates resources, records state, enforces policy, recovers from failure, and improves its own management surfaces. The agent does the work. The OS manages the agent doing the work.

2. The invariant that makes the difference

The invariant is simple. Every WunderOS subsystem that touches memory, agents, policy, retrieval, or execution must decompose as a plant, a sensor, a controller, and an actuator.

The plant may include an LLM, a customer agent, a memory tier, a scheduler queue, a microVM pool, or a release handler. The sensor must produce a sound account of what the plant did. The controller must decide from replayable state. The actuator must change the plant or block a change to it. The knowledge component is the accumulated trace, policy, config, score, and history against which later decisions are made.

The phrase “closed-loop by construction” is not a flourish. It is a design test. If a proposed feature has no sensor, it cannot be trusted as a control feature. If it has no controller, it is telemetry. If it has no actuator, it is advice. If it has no durable knowledge, it forgets facts by which it would have improved.

LLMs sit inside this invariant as opaque plants. WunderOS does not inspect a model’s weights, attention, gradients, or private chain of thought. It observes the model at the boundary: prompt, output, tool proposal, memory write, latency, cost, trace. This is not a limitation introduced by prudence. It is the correct classification. The model emits events that cannot be forced from inside the OS. The OS controls the events it can control: tool dispatch, memory commit, network egress, policy admission, retry, rollback, and promotion.

The result is not an omniscient agent manager. It is a maximally explicit one. WunderOS controls what is controllable and records what is not.

3. Self-sensing

Autonomic control begins with sensing. WunderOS has a system-wide observation bus, i.e., a sensorium, because agent and substrate events are not left as incidental logs. They are structured observations.

The observation bus gives the read side of that sensorium. It accepts application-layer events from the derivation pipeline, assigns a monotonic sequence, preserves tenant scope, filters subscribers, feeds dashboards, feeds agent observers, and exports boundary telemetry without contaminating the internal algebra. It is not merely a logging sink. It is the surface by which controllers see the plant.

But the sensorium is not merely a bus. Its evidentiary core is a cryptographically-managed observation spine that records what happened in a form later control and later audit can trust.

A sensor that can be edited after the fact is not a sensor in the sense an autonomic system requires. It is a report. WunderOS’s sensorium gives the report teeth: observations enter a trace-WAL, are chained by hash, closed into Merkle structure, and sealed so that a later verifier can detect omission, insertion, reordering, and tampering.

The Merkle-DAG aspect is essential because agent work is not a straight line. A decision has parents: facts read, rules fired, tools called, policies applied, messages received, and compensations registered. The proof of a decision is therefore a graph proof, not merely an entry in a chronological log. Each derived fact or control decision can carry a root into the trace-WAL; walking that root gives the antecedent slice. Recomputing the hashes gives the integrity check. The controller can use the trace as knowledge because the auditor can later verify that it is the same trace.

Attribution rides the same discipline. Agent and system-agent writes are sealed under cryptographic identity, with ULID-rooted Ed25519 keys providing the which-agent-sealed proof over the Merkle forest. This does not prove that the agent was right. It proves which agent, or which system agent, made the recorded move, under which recorded authority, and against which recorded antecedents. That distinction is the difference between observability and accountability.

Several details matter.

  1. Observations are ordered and sealed. A control loop that cannot distinguish before from after cannot diagnose; a control loop whose past can be rewritten cannot be audited.
  2. Observations are filterable. An optimization observer, a dashboard, an OTLP exporter, and a tenant-facing stream do not read the same view, and they should not.
  3. System events are distinguished from tenant-facing events, so control-plane noise does not become tenant fact by accident.
  4. The subscriber position is explicit. A controller can recover from a disconnect by asking for observations since a sequence number rather than by guessing from wall-clock time.

This is what self-sensing requires in an agentic OS. It is not enough that logs exist. The OS must expose observations in the form controllers can consume, and it must preserve them in the form auditors can verify. The sensorium is therefore both operational and cryptographic: live enough to control the plant, sealed enough to prove what the control loop saw.

4. Self-configuring

Self-configuration is not the same as letting an operator set more knobs. A system is self-configuring when

  1. the knobs are part of a typed control surface,
  2. changes to them are bounded by the type system and policy,
  3. they can be applied live, and
  4. evidence decides whether the change is accepted.

WunderOS puts this surface in configuration actors and closed patch vocabularies. Memory tiers, decay, eviction, retention guards, ingest patterns, scheduler weights, reserved floors, and related runtime policy are not loose environment variables. They are structured values. An adaptive loop may tune a half-life, a capacity, a threshold, or a weight. It may not invent a new physics. Mode-1 ledger state cannot acquire decay because a patch asked for it. A shared policy can change only through a patch form the system knows how to validate.

This gives configuration the shape required for autonomy. The plant is the running memory, scheduler, or policy surface. The sensor is the scoreboard, trace, observation, or workload signal. The controller proposes a bounded patch. The actuator applies it through the owning actor or rejects it. The knowledge is the current versioned config plus the evidence that justified the change.

Self-configuration therefore precedes self-optimization. The system can only optimize what it can mutate safely.

5. Self-optimizing

WunderOS’s central self-optimization loop is CARL, the continuous autoresearch loop. CARL optimizes the symbolic harness around a frozen model. It does not train the model. It does not silently mutate substrate physics. It proposes bounded changes to the policies and harness surfaces that decide what the model sees, which tools are selected, how context is assembled, and how memory is read.

This distinction is decisive. CARL optimizes neither the model nor its tenant (i.e., customers’) agentic workloads. If the optimization surface were the model itself, the loop would inherit the opacity of the model. Credit assignment would become stochastic, replay would weaken, and promotion would look like drift. If it were the Customer Agents (CAs), that would be a practical and intellectual property nightmare.

CARL instead optimizes WunderOS itself, that is, the deterministic management surface around the model, from accumulated execution traces and reward signals. It replays the environment, re-infers where re-inference is necessary, compares candidate harnesses under a fixed evaluation discipline, and promotes only through an audited gate. And this replayability is why WunderOS is carefully crafted to be deterministic.

The word “continuous” also requires care. CARL may run continuously. Promotion does not therefore become silent. A candidate can be generated by a loop, scored by a loop, and still require a human-gated policy edit before it reaches production. This is not a compromise with autonomy; it is the condition that makes autonomy usable in a regulated setting. The system may lower the cost of operator validation. It may not abolish the need for accountable promotion where managing the scope of conceivable damage requires it.

This is why CARL is a more grounded example of autonomic behavior than a generic “agent improves itself” slogan. It names the plant, the sensor, the controller, the actuator, the knowledge store, the permitted mutation surface, and the promotion boundary. That is a self-optimization loop rather than an ambitious wish.

6. Self-scaling across strictly isolated multi-tenant workloads

Workload management is another autonomic surface. Agents do not arrive in steady beats. They burst by tenant, by task, by deadline, and by external dependency. A system that hosts them has to decide which admitted work runs next, how finite execution slots are shared, what counts as fairness, when idle capacity can be lent, and when capacity has to be restored or expanded.

Fine-grained Local Scheduling of Contention

At the local execution seam, WunderOS scheduler supplies the fair-share controller. Autonomy requires economy in the following ways.

WunderOS arbitrates among already-admitted customer agents at the Brass Loom worker pool. The resource is a logical turn, not wall-clock time, because turns are recorded and replayable.

Credits are tenant-keyed, because fairness among tenants is the business invariant and fairness among a tenant’s own agents is secondary.

Reserved capacity and weighted shared capacity are separate. A tenant with a paid floor receives the floor; above the floor, tenants compete by weight.

Idle capacity is lent rather than wasted, but the loan is bounded.

Coarse-grained Cloud Scheduling of Capacity

At the deployment seam, WunderOS’s cloud-prem architecture gives the coarser scaling surface. In v1, a customer VPC runs a single tenant node with an Auto Scaling Group replacing failed instances, EBS holding the durable write-ahead log, S3 holding snapshots to bound restore time, and an outbound private management connection to the Pentad control plane.

In v2, execution scales out across a fleet, while memory first scales up and only then gross-shards by tier or tenancy boundary. The point is not that AWS APIs themselves are autonomic. They are actuators. The autonomic claim belongs to the controller that uses them from policy, telemetry, contract, and replayable state.

Self-scaling therefore has two layers.

  1. The local scheduler decides the next turn under contention.
  2. The deployment plane changes or restores the capacity envelope.

Both are control loops over finite resources, and both must remain deterministic where the decision affects replay.

7. Self-healing

WunderOS Self-healing is recovery to a named state under a named failure model. It is not the absence of failure. It is also not a best-effort restart followed by an optimistic health check.

The availability contract states the claim precisely.

After a single-process or single-host crash, every component recovers to its pre-crash logical state within the Recovery Time Objective (RTO) target, losing at most its stated Recovery Point Objective (RPO) window.

This is autonomic because the recovery path is part of the system contract. A supervisor respawn is not an explanation. The explanation is the durable state from which the process reconstructs its logical position, the idempotency key that prevents a completed external effect from being repeated, the completion record that lets replay skip what is done, and the halt condition when the log is corrupt or the actuator cannot promise idempotency.

The honest parts matter as much as the successful path. A non-idempotent external effect still leaves a correctness ambiguity if the crash lands between actuation and completion. A cold microVM can breach the desired recovery time without a warm pool. Naming these gaps is not a weakening of the autonomic claim. It is the claim made correctly. A control system that does not name its residual error is not more autonomous. It is merely less candid.

8. Self-maintaining

An autonomic OS must be capable of change while running. For ordinary programs this is difficult. For an agentic OS it is harder, because live sessions, replay, and substrate code all meet at the upgrade boundary.

Hot-code reload in WunderOS is therefore a continuity model, not a deployment trick. The stable piece differs by layer. In the control plane, the stable thing is the supervised process and its state, with explicit state migration. In the data plane, the stable thing is the control plane-visible resource whose identity is stable, with bounded kernels and a drain protocol. In deterministic replay, the stable thing is the chain head and the code-version-stamped trace, with a discontinuity marker when the running code changes.

This gives self-maintenance its proper boundary. A reload is allowed to change code. It is not allowed to pretend that replay across a code boundary is the same simulation. It is not allowed to drop session state because an internal component changed. It is not allowed to emit side effects while migrating process state. The system may maintain itself, but it must state the discontinuity it creates.

The lesson is general. Self-maintenance is not achieved by hiding change. It is achieved by making change explicit enough that live operation and later replay both remain well-defined.

9. Self-protecting

Protection is also a loop. In WunderOS, the plant proposes an action. The sensor reads the proposal and the current session state. The controller applies policy. The actuator allows, warns, redirects, defers, or blocks the action. The knowledge component is the policy bundle, capability state, trace, and resulting Pentad emission.

WunderOS Interceptor is the composed supervisor at the agent-turn boundary. It orders evaluators by surface: tool call, memory write, egress, prompt, receipt. Vaccines, capability mediators, tool validators, and egress gates become a single decision pipeline. The decision alphabet is closed. The order is replay-deterministic. The result is emitted into the record.

This differs from a firewall around an agent. A firewall treats the agent as a network source. The Interceptor treats the agent as a userland program whose privileged events must be mediated by the OS. The same action can be blocked before dispatch, rejected after result, redirected to a safer substitute, or deferred to a human operator. The control surface is the agent lifecycle, not a socket.

Tenant isolation and capability boundaries extend the same principle downward. The OS does not rely on an agent remembering what it may do. Permission is a property of the substrate surface through which the action must pass. That is what self-protection means in an operating system for agents.

10. What the claim excludes

The WunderOS autonomic claim excludes three common exaggerations.

First, it excludes unrestricted self-modification. WunderOS does not let a loop rewrite substrate physics because a metric improved. Physics is not a candidate surface. Policy and harness surfaces may be candidates under gate. The invariant is changed by design, not by drift.

Second, it excludes LLM control in the hot management path. A model may be a plant. It may also propose a candidate for a bounded surface. It is not the authority by which the OS decides that the candidate is true, safe, cheap, or deployable. Those decisions must reduce to recorded state, deterministic scoring, policy, and human approval where the blast radius demands it.

Third, it excludes the fantasy of zero human involvement. Autonomic is not HOOTL everywhere. A mature system moves human attention to the places where it has value: promotion, exception, liability, policy, and residual gaps. The system should handle the ordinary case. It should not launder extraordinary authority through the word “autonomic.”

These exclusions are part of the definition. A system that cannot say what it will not automate cannot be trusted with what it says it will.

11. The claim restated plainly

WunderOS is autonomic because it treats management of agents as an operating system problem and implements that management as closed loops over replayable state. It senses through structured observations. It configures through typed patch surfaces. It optimizes through CARL. It scales through schedulers and deployment actuators. It heals through durable logs, replay, idempotency, and bounded recovery contracts. It maintains itself through layer-specific continuity. It protects through composed supervisors at the privileged action boundary.

The unity of these mechanisms is the point. Any one of them alone is an ordinary system feature. Together they make a system whose object of management is itself.

That is what is autonomic about WunderOS.

Appendix. What BEAM/OTP helps us do easier than anything else could

Being built on Erlang’s legendary BEAM/OTP does not make WunderOS autonomic by itself. The cryptographic ledger, the write-ahead log, the Merkle sealing, the Zig data plane, the replay contract, and the policy language are not gifts from BEAM. They are WunderOS architecture.

BEAM/OTP matters because using it makes several of the required control properties ordinary rather than exotic.

Fault containment

The first property is fault containment. BEAM processes are cheap, isolated, and supervised. A Shadow Agent, a scheduler actor, a config actor, an observation subscriber, or a release coordinator can fail as a process rather than as the whole node. OTP supervision gives the restart relation a first-class home: which process owns which child, what restarts on failure, what is allowed to die, and what state must be reconstructed from durable storage. In a stack without this runtime contract, WunderOS would have to build its own supervisor discipline out of threads, queues, watchdogs, and conventions.

That can be done, but the result is usually less explicit and less tested. It’s always more work.

Controlled state transitions

The second property is controlled state transition. A BEAM gen_server or gen_statem is a serialized state machine with a mailbox and an OTP lifecycle. That is exactly the shape many WunderOS controllers need. The actor owns its state; callers send messages; the actor decides; the transition is local and inspectable. This reduces the amount of shared-memory concurrency that has to be made correct by locks. It also gives natural homes for per-tenant live configuration, per-agent session state, observation lenses, Interceptor coordination, and scheduler arbitration. WunderOS still records the decisions that matter.

BEAM makes the live controller shape simple enough that the record can be the source of truth rather than a repair after chaos.

Long-running concurrency

The third property is long-lived concurrency. Enterprise agents wait. They wait on people, tools, timers, approvals, retries, remote systems, and real-world deadlines. A runtime built around cheap processes, message passing, timers, monitors, links, and hibernation is well matched to that shape. A runtime built chiefly around request handlers is not. WunderOS can model a Shadow Agent, a held approval, a deferred plan step, or a sleeping controller as a resident process or a supervised state machine without treating it as a special distributed workflow each time.

Long-running concurrency matches WunderOS’s unique capability to its targeted compute environment, i.e., regulated enterprise back-office automation directly.

Interruption-less maintenance

The fourth property is live maintenance. BEAM’s code server and OTP upgrade machinery give the control plane a native account of code change while the node is running. code_change/3 is not a complete upgrade strategy, and WunderOS still has to state its discontinuity markers, state migration rules, NIF drain protocol, and replay boundary. But BEAM supplies the right primitive for the WunderOS control plane: code can change while supervised processes keep identity and migrate state deliberately. In systems without hot-code pedigree, live maintenance tends to become process replacement, blue-green deployment, or container restart. Those are valid deployment tools.

They are coarser than the continuity model an agentic OS needs for live sessions.

Operational introspection

The fifth property is operational introspection. OTP systems have an old habit of exposing process state, supervision structure, mailboxes, crashes, and runtime health as things operators can see. WunderOS does not rely on Erlang observer tooling as its audit story, because audit belongs to its sensorium and the sealed ledger. But the OTP habit helps the engineering system: the live control plane is inspectable in the same idiom in which it is built. The runtime’s internal shape does not fight the system’s external claim that management should be observable.

WunderOS observation is first-class and native-born.

Critical infrastructure by pedigree

The sixth property is distribution with a conservative pedigree. Erlang distribution, monitors, links, process identity, and OTP design patterns come from systems built to stay up while changing. WunderOS does not inherit correctness merely by using them. Cluster sealing, tenant partitioning, deterministic replay, and cross-node durability are still WunderOS decisions. But the runtime does not begin from a blank page.

WunderOS starts with a system lineage whose central problem was always concurrent, fault-tolerant, upgradeable service.

The data plane exception

There is also a negative claim. BEAM/OTP is not the data plane.

It is not where WunderOS gets SIMD kernels, bounded allocation in hot paths, Merkle hashing, direct I/O, or the VOPR discipline of the Zig substrate. BEAM/OTP is the control-plane runtime: the place where supervisors, actors, policy actors, release handlers, observation subscribers, and agent twins live. Zig is the place where the substrate pays its byte-level costs. The architecture works because these roles are separated.

This is why BEAM/OTP helps more than a generic application runtime would. It already has the abstractions an autonomic control plane needs: isolated processes, supervision, message passing, hibernation, monitored failure, structured state machines, hot upgrade, and a long operational memory of systems that must keep running. WunderOS still has to make the control loops true.

BEAM/OTP makes them cheaper to build honestly.