Mupot OS · Developer Preview

A reproducible body for governed AI agents.

A declarative NixOS profile for agents that need more than a prompt: a supervised runtime, durable terminal, browser lane, encrypted identity, and a machine you can rebuild or roll back.

Working internal reference fleet. Local developer preview — not yet a production or 24/7 customer image.

Three Mupot OS agent bodies — development, browser, and review — connected to the Mupot control plane

3 roles

Development, browser, and independent review

3 IDs

One attributable Mupot principal per body

PASS

A real dev-to-review artifact handoff

Receipts are from the internal ARM64 NixOS reference fleet, not a synthetic marketing demo.

The body

Rebuild the machine from Git.

NixOS defines the packages, users, systemd services, resource ceilings, writable state paths, firewall ports, backups, and health surfaces. A machine change becomes a reviewable generation with a rollback path instead of an undocumented mutation.

Mupot OS architecture from Mupot authority through Hermes and Kolu to the NixOS body

Agent workspace

A terminal that survives the agent.

Hermes runs as the reasoning and tool runtime. Kolu provides the visual workspace; Padi records host and session state; Kaval owns PTYs so terminals can be adopted after a UI or service restart. The browser role includes a declared Chromium and Playwright lane rather than a one-off npm install.

Hermes · Kolu · Padi · Kaval

Governed fleet

Every body has one identity.

Mupot remains the authority surface for squads, permissions, tasks, gates, inboxes, and audit. Each machine is welded to its own principal. In the reference flight, development produced a Git artifact, review returned a PASS acknowledgement, and the original request relationship stayed visible in the inbox.

receive → act → artifact → review → ACK
Reproducibility

NixOS generations

Pinned machine definition, atomic rebuilds, automatic garbage collection, and a tested rollback path.

Security

Scoped state and secrets

Dedicated non-root principal, rootless containers, systemd hardening, and age-encrypted provider secrets.

Operations

Health and receipts

Per-node JSON health, a three-body fleet view, nightly state backups, and Mupot-attributed handoffs.

Current boundary

Useful now. Honest about what comes next.

Proven today

  • ARM64 NixOS bodies running Hermes and Kolu
  • Chromium automation and rootless Podman canaries
  • Encrypted secrets and signed binary substitution
  • Three distinct Mupot identities and a PASS handoff

Developer-preview limits

  • Reference nodes currently run locally in OrbStack
  • Fleet roster is static rather than Mupot-discovered
  • Hermes uses a pinned installer, not a native Nix package
  • Enrollment is not yet a self-serve customer workflow

Help shape the agent body.

We are opening the architecture while the product is still honest enough to change. Bring a governed-agent workload; we will show the machine, the handoff, and the receipts.