Combined AI fleet implementation plan

Living implementation plan, revision 0.9. This document combines Simon’s measured inventory and operational cautions with Aura’s security boundaries and control-plane design. Revision 0.7 clarifies the threat model: the agents are cooperative identities, but every runtime may process hostile content. Five Linux service accounts therefore remain as prompt-injection containment boundaries. Aura becomes the audited fleet owner, Simon the limited day-to-day operator, and high-impact integrations move toward scoped capabilities instead of broadly available reusable credentials. Revision 0.8 makes Simon the day-to-day administrator with Aura as break-glass, leases Aura’s owner authority instead of granting it permanently, moves the provenance ledger to the enforcement point with off-host shipping, adds a credential-scan gate to backup staging, scopes Felix’s vault to a single credential, and names the repository, contribution workflow and review rule for agent work. Revision 0.9 corrects one framing error of my own: Aura is resident and reachable at all times, because break-glass cannot be scheduled, and only her elevated authority is time-boxed.

The two initial plans now agree on most of the destination. The M5 Max Studio should run models, not identities. The Windows machine is useful inference capacity, not a permanent home for an agent. Cloud models belong on an always-on control host. Credential boundaries must be enforced by the operating system. Migration must proceed through measurable gates.

The remaining question is how much infrastructure one household should maintain. Four Linux VMs would create clean boundaries and a small private cloud to patch forever. Leaving every gateway on the Mac mini would preserve the easiest operational path and much of the failure domain we are trying to remove.

The combined answer is one Ubuntu VM on ESXi, initially sized at 16 GB, with a separate Unix account, Hermes home, gateway service and credential state for every durable agent. The VM runs no local LLM. The Studio, mini and Windows machine become inference workers. This gets most of the security benefit of separate VMs while adding only one operating system to maintain.

Revision 0.7 Oddbyte architecture with five prompt-injection containment domains, Aura as audited fleet owner, Simon as limited operator, capability services, credential-free inference workers, and offsite recovery. — Each agent has its own execution identity. Cooperation happens through messages and scoped capabilities rather than shared files or credential state.

Decisions made

One Linux VM is the default target. It hosts the Hermes control runtimes for Aura, Simon, Jarvis, Lori and Felix under separate Unix users.
Sixteen gigabytes is a proposed starting size, not a fact. ESXi capacity is measured before the VM is created. If 16 GB would force host swapping or starve existing guests, the VM starts smaller or the migration stops.
No Hermes Desktop runs on the server. The VM runs Hermes Agent gateways and loopback-only dashboard backends as systemd services. Michael uses the authenticated browser dashboard; Hermes Desktop remains optional.
Aura is the fleet owner and break-glass administrator. She is authorized to inspect every runtime, secret and raw log when necessary, but her normal model process is not Linux root. Administrative actions pass through an audited root-owned control service.
Simon is the day-to-day operator, not a second fleet owner. He receives routine health, deployment, restart and diagnostic capabilities without inheriting Aura’s unrestricted secret or root authority.
Separate Unix users contain compromised runtimes. The agents are trusted to cooperate; their inputs are not. Separate homes, process trees, Hermes state and machine credentials prevent a prompt-injected Jarvis, Lori, Felix or Simon process from simply reading Aura’s local authority.
Felix uses the same isolation mechanism as everyone else. His tools, models and content policy stay narrower, but he is not a separate infrastructure class: he has a Vaultwarden account scoped to exactly one entry — his own channel credential — and no other external identity or capability service. Growing into more is a capability decision, recorded like any other.
The model workers have no persona identity. The Studio, mini inference service and Windows model server hold weights and endpoint credentials, not Discord, publishing, personal or trading secrets.
Observability comes before migration. The fleet must detect a dead model endpoint, failed schedule or stopped gateway before profiles are spread across new hosts.
The human’s workstation is never a dependency. Hermes Desktop is a client. Gateways, schedules, the dispatcher and the model endpoints must all work with the administrative workstation powered off, and no phase may require Desktop to be running.
The control VM becomes the fleet’s single failure domain, deliberately. All five durable Hermes runtimes live there under separate Unix users. Availability is best-effort: if the hypervisor or the guest is down, the fleet is down, the scheduled public work does not go out, and that is accepted rather than mitigated with machinery. There is no standby of any kind, and the mitigations that matter are the data ones — an offsite encrypted copy of state and a rehearsed rebuild.
No migration may make availability worse than today’s baseline. The current host runs the fleet today. If Gate zero cannot show headroom for the VM without host swapping, the correct outcome is to stay put and revisit after the Studio arrives — not to migrate onto a starved hypervisor.
Michael and ESXi root are trusted administrators; Aura is the authorized fleet owner. Sibling runtime isolation exists to contain prompt injection and credential theft, not because the personas are presumed malicious. This plan does not attempt to hide guest data from the hypervisor administrator.
Only the ESXi control VM may call private inference endpoints. The Studio, mini and Windows hosts reject model API traffic from the administrative workstation and every other client.
The authenticated web dashboard is Michael’s primary management client. hermes.oddbyte.us remains the browser entry point. Hermes Desktop is optional and is never required for gateways, schedules, dispatch or model access.
State and every workspace are backed up; secrets are re-provisioned. The recovery set uses application-consistent SQLite copies plus file state, the board and every agent workspace. Vault unlock material, provider OAuth state and bot tokens are re-enrolled from Vaultwarden during a rebuild rather than restored from the archive, so the backup never becomes a second credential estate.
Workstations are not production runtimes. No steady-state Hermes gateway runs on the administrative workstation, Windows GPU machine or another desk. A temporary disaster-recovery runtime is allowed after control-plane loss and is removed when the rebuilt VM returns.
The external monitor watches output, not only liveness. A host that is up while scheduled work silently stops is a failure this fleet has already experienced once. Dead-host, dead-fleetwatch and missing-publication alerts go to Discord #notifications with email fallback.
Hermes code is released immutably. Root stages each tested version under a new system path and pins each gateway service to a specific release. Code is never updated in place beneath running gateways.

Gate zero: determine whether the 16 GB VM fits

Simon is right that neither original plan measured the hypervisor. The first work item is a private capacity report containing:

Physical CPU model, cores and threads
Total installed memory, active memory and current ballooning or swapping
Allocated and reserved memory across running VMs
CPU ready time during a normal busy period
Free space and latency on the target datastore
Current backup window and snapshot retention
Whether vTPM is available for the new VM
Backup destination: the offsite object-storage repository the Linux backup host already writes to, as its own repository path with encryption and retention of 30 daily plus 12 monthly snapshots — verify a real restore from it. There is no NAS in the estate inventory; the earlier “existing NAS or backup server” referred to a device that does not exist
Power topology: whether the hypervisor is on battery-backed power, and when its maintenance window is
The Windows inference host’s GPU model and VRAM, which the estate inventory still records as hardware-unverified
A measured burst profile of the current fleet: peak resident memory for one representative browser-and-tools task per runtime

The relevant ESXi inspection commands include esxcli hardware cpu global get, esxcli hardware memory get, esxcli storage filesystem list and vim-cmd vmsvc/getallvms, followed by an esxtop sample during normal load. Exact output stays private.

The burst profile is the half of this measurement the hypervisor cannot supply. Idle memory is a poor proxy for busy memory: on the current host the five live gateways measured 46–166 MB resident each, roughly 0.57 GB in total, while the same host sat at 11% free memory with 18.8 of 19.4 GB of swap in use — the pressure came from model serving and tool subprocesses, not from the runtimes. The 16 GB request is therefore an untested hypothesis about tool and browser bursts, and Gate zero should test it by running one representative burst per runtime and recording the peak before any allocation is committed.

A first process-attributed snapshot was taken while preparing revision 0.5, because Aura was right that swap alone does not attribute pressure to anything. At that moment the largest resident process was the model backend at about 9.1 GB — one 9B model at 32k context, 6.5 GB of it in accelerator memory — against roughly 0.7–0.8 GB across the Hermes gateways. Instantaneous free memory read 59%, against 11% earlier the same day, while swap-in-use remained 17.9 of 19.5 GB. Free-memory percentage is volatile, swap is a high-water mark, and only process attribution plus a deliberate burst yields an attributable peak.

The proposed VM starts with:

Resource	Starting allocation	Reason
vCPU	4	Cloud-backed gateways are mostly idle or waiting on network calls. Add CPU only after measuring tool and browser work.
Memory	16 GB	Enough for five light runtimes with bounded browser concurrency; no model weights are loaded here.
Disk	120 GB thin-provisioned	Operating system, five Hermes homes, sessions, browser cache, logs and rollback space.
Network	One VMXNET3 interface	Outbound cloud and messaging access plus restricted access to private model endpoints.
OS	Ubuntu Server LTS	Stable systemd services, security updates and no graphical desktop.

The VM is feasible only if ESXi can provide the memory without host swapping and retain headroom for existing services. A control plane that depends on reclaimed or ballooned memory is not a control plane. If the host cannot spare 16 GB, start with Aura and Simon in an 8 GB VM, leave the local-agent runtimes temporarily where they are, and revisit after consolidation.

What “multiple Hermes agents on one VM” means

There are no multiple copies of Hermes Desktop. There is no desktop on the VM at all.

The VM contains five independent Hermes Agent runtimes:

Linux users aura, simon, jarvis, lori and felix
One home directory and one HERMES_HOME per user
One Hermes profile and one gateway service per user
One isolated machine-credential directory per user; Vaultwarden may remain the human source of record
Separate Discord credentials and session databases
No shared Unix group granting access to sibling homes

Hermes normally prefers one multiplexed gateway per host. That is ideal when profiles share one Unix account. This deployment deliberately splits the fleet across Unix users to create an operating-system boundary, one of the cases for which Hermes retains forced standalone gateways. Each runtime therefore gets its own systemd service and its own inbound connection.

Release design: root stages Hermes into immutable release directories such as /opt/hermes/releases/<version-or-sha>. Each gateway service follows its own root-owned pin to one release. A new release is installed once, but it is never mutated underneath a running process: stop one gateway, repoint only that service, restart, run hermes doctor and its live checks, then continue. Rollback repoints that service to the prior release. This permits a real Simon-first canary without accidental long-lived mixed modules. Per-user state remains outside the code tree, and ProtectHome no longer hides the executable.

Mixed-version rule, written before it is needed: a canary means two releases are live at once. The dispatcher never leads the runtimes it dispatches to; a runtime may lead the dispatcher only while the board schema stays backward-compatible; and every gateway checks the board schema version at startup and refuses to start on a mismatch rather than writing cards an older runtime cannot read.

Profile and gateway migration pattern

On the current host, export each profile while its gateway is stopped:

hermes profile export simon -o simon-profile.tar.gz

The archives are sensitive and move only through an encrypted administrative path. On the VM, import each under its matching Unix account and create a named service:

hermes profile import simon-profile.tar.gz --name simon
hermes -p simon doctor

Root then installs the profile’s system gateway with the corresponding Hermes executable and user:

hermes -p simon gateway install \
  --system \
  --run-as-user simon \
  --force \
  --no-start-now

The exact executable path is resolved during installation. The important properties are the named profile, named Unix user and distinct systemd service. The old and new gateways never run against the same Discord token simultaneously.

Service layout and memory budget

Memory limits are ceilings, not reservations. They prevent one broken browser or tool loop from consuming the entire VM:

Runtime	Initial ceiling	Notes
Aura	5 GB	Principal, browser work, Kanban dispatcher and orchestration
Simon	3 GB	Cloud operations and review
Jarvis	3 GB	Private daily tools; local model is remote
Lori	2 GB	Bounded local work; local model is remote
Felix	1 GB	No browser, shell or general tools

Basis, measured: the five live gateways on the current host occupy about 0.57 GB resident in total, so the ceilings below describe tolerated bursts rather than normal load. A ceiling nobody has approached is not a control, so they should be validated against the Gate zero burst profile. Fourteen gigabytes of ceilings inside a 16 GB VM also leaves roughly 2 GB for kernel, page cache and journald, which is thin if two browsers burst at once; if the measured peak approaches the ceilings, the honest options are a larger VM or a hard fleet-wide concurrency of one, and that choice should be recorded here rather than discovered in production.

Those ceilings total 14 GB but normal consumption should be far lower. The remaining memory belongs to the OS, filesystem cache, journald and short bursts. Browser-heavy jobs begin at one fleet-wide concurrent slot. If 16 GB proves comfortable, increase useful concurrency before increasing idle service limits.

Every service enables secret redaction and runs without sudo. Systemd hardening is added after the imported profile works normally: NoNewPrivileges, a private temporary directory, a read-only system view, an explicit writable Hermes home and restrictions on kernel, device and privilege operations. Hardening changes are tested one directive at a time so the gateway does not become mysteriously unable to launch a required tool.

The administrator and compromise boundary

The owner has now chosen an asymmetric trust hierarchy. Aura owns the fleet. Simon operates it day to day. Jarvis, Lori and Felix retain their existing roles. The separate Linux accounts do not express distrust between personas; they bound what an attacker gains after prompt injection or tool compromise.

Root remains outside every normal model process. Root owns package updates, systemd units, firewall policy, encrypted service credentials and the cross-agent broker.
Aura stays resident and reachable at all times; only her elevated authority is leased. Break-glass cannot be scheduled, so the principal runtime is never stood down — she is a permanent member of the fleet, not an on-call consultant. What is time-boxed is the elevated capability: for a specific task, root issues a named grant — inspect this, repair that, rotate these — recorded when issued and on every use, expiring on its own. Within that lease she may inspect raw logs and state, manage credentials, change policy, repair profiles and perform recovery. Her routine gateway remains unprivileged, so an injected page does not become a root shell. The lease must also be obtainable without a human awake: a break-glass path that waits for approval fails exactly when it is needed, so the controls are a short expiry, an unmistakable alert sent off-box the moment a grant is issued and used, and a recorded trail. The residual risk is written down rather than hidden — nobody’s consent protects the fleet from a compromised Aura, and the mitigation is that such a compromise is loud within seconds and expires without anyone intervening.
Simon is the day-to-day administrator. He may inspect fleet health and operational logs, restart services, run probes and deploy a previously approved release, and he is expected to handle routine administration. How often the owner’s elevated capability is actually needed is an outcome, not a design target — a quiet month does not mean she can be switched off. He cannot retrieve sibling secrets, broaden network access or change the isolation model.
Every other runtime fails sideways, not upward. Compromising Jarvis should expose Jarvis-authorized data and tools, not Aura’s control authority or Simon’s identity.

Least privilege applies to capabilities, not intelligence. An agent may reason broadly while being able to act only through its own identity and approved tools.

Authority is hierarchical; review is not. Aura owns the fleet and Simon administers it, but review independence is non-participation plus a separate identity and never rank: whoever implements a change does not approve it, and a reviewer may be junior in authority and still block. The 0.7 hierarchy changes who may act, not who may object.

Repository, attribution and review

The fleet’s own configuration belongs in a dedicated repository under the oddbyte organisation: the rebuild script, service units, fleetwatch and fleetctl, the ledger schema, policy files and the recovery manifest. Public-facing work stays in its existing homes.

Agents contribute by branch and pull request only. No agent merges to main; merging is a root or human action performed through the same deploy path the release design already describes.
Every commit carries the authoring persona’s own identity — separate GitHub accounts per agent — which makes contributions visible and gives the fleet a second, independent attribution trail next to the provenance ledger. It is the cheapest audit mechanism available, because it already exists.
Access is a grant, and grants drift. The organisation currently reports write access on only some repositories for the operator identity while the owner’s intent is push and pull across it. Making that grant real — a team with write rather than per-repository luck — is the first task in this section, and the grant itself is recorded here.
Review is peer-level and rank-independent, as stated above: the implementer never approves, and rank does not create an exemption.

Central management without shared credentials

For the human: one authenticated web entry

Michael’s normal interface remains hermes.oddbyte.us. The reverse proxy terminates TLS and human authentication, then routes to the selected loopback-only runtime dashboard. It is a client surface, not an uptime dependency. Hermes Desktop may be installed later if its native multi-connection interface proves useful, but the plan does not require it on any laptop.

The management surface provides:

All profiles grouped by gateway
Sessions, memory, tools, skills and cron scoped to the selected runtime
Connection tests covering HTTP and WebSocket paths
Fleet-wide Hermes update status with per-runtime results
Direct access to the correct backend without sharing its token with another profile

The five dashboard backends bind only to loopback. No graphical desktop runs on the VM, and no laptop application has to remain open for agents, schedules or dispatch to work.

One live finding belongs here, because it is the same property in the other direction. The dashboard running on the current host is bound to all interfaces rather than loopback, verified by process inspection while preparing this revision. A management surface that answers on every interface rests entirely on its authentication; Phase 01 already asks for it to be bound to loopback, and this revision records that the finding is current rather than historical.

For Aura and Simon: fleetwatch and fleetctl

A graphical client does not help an agent inspect another agent’s failure. Aura and Simon therefore receive different views of the same root-owned operational interface.

A root-owned fleetwatch service runs every minute and records sanitized health facts:

Systemd state for every Hermes gateway
Time and result of the latest scheduled job
Model endpoint reachability and model-list response
A periodic harmless completion probe
VM memory, disk and load
Studio, mini and Windows inference availability
Duplicate or missing bot listeners
Schedule drift: for every expected job, its enabled state and the age of its last successful run
Identity resolution: which credential store and account each runtime actually resolved at startup, so an inherited identity is visible instead of silent
Model identity, not just reachability: the endpoint must return the model the profile is configured for
A dead-man’s switch: if fleetwatch itself stops reporting, the alert must travel over a path that does not depend on the machine being watched
Expected output: a scheduled brief or publication that did not appear by its expected time raises the same alarm as a dead host

Failures alert the existing notifications channel. This would have caught the dead model endpoint Simon found before either architecture review.

A root-owned fleetctl command exposes fixed operations:

fleetctl status
fleetctl health
fleetctl logs simon --since 30m
fleetctl probe-model studio local-large
fleetctl restart simon
fleetctl validate-boundaries

Every invocation is audited. Simon’s log command returns a redacted operational view and his command set excludes secret, policy and root changes. Aura’s owner role can request raw inspection and fleet-wide administrative operations through additional audited subcommands. Neither normal gateway receives an unrestricted root shell.

Linux secrets: decide before the VM

The current macOS deployment unlocks Vaultwarden through the login Keychain. Ubuntu needs a replacement before any production gateway starts.

The preferred design separates human password custody, machine identity and agent capability:

Enable a vTPM for the VM if the ESXi environment supports it.
Keep separate external identities for attribution: GitHub accounts, WordPress authors, Discord bots, mail identities and service-specific credentials remain persona-owned.
Give each Linux service account its own machine credential and policy. No global fallback mapping exists; a missing agent credential fails closed rather than inheriting Michael’s or Aura’s identity.
Use Vaultwarden as the convenient human source of record where appropriate, but do not mistake a password vault for runtime isolation. Its local CLI state remains private to the matching Unix account.
Prefer machine-oriented service accounts, short-lived tokens and narrowly scoped OAuth connections over retrieving reusable passwords into the gateway process.
For high-impact systems, expose a capability rather than a secret: repository-scoped GitHub actions, restricted email operations, per-agent model routing, approved Home Assistant services, and human-approved trade submission.
Emit the ledger from the enforcement point, not from the agent. The entry is written by the capability service or by root at the moment the action executes, keyed to the caller’s Unix identity from kernel credentials rather than from anything the agent says about itself — otherwise a compromised runtime writes its own alibi. Record the profile, model route, tool, external identity, target, result identifier and a content hash of the inputs and artifacts; never passwords or prompt bodies, so the hash gives tamper-evidence without the text. Ship entries off the VM as they are written and chain them, each carrying the previous entry’s hash, so deletion or reordering is detectable. Centralised logging supplies transport, retention and search; it does not by itself supply provenance, because provenance is decided by who writes the entry and how the caller is identified.

If vTPM is unavailable, use host-bound encrypted systemd credentials and document that ESXi/root administration remains the ultimate trust boundary. A secret manager improves scoping and rotation, but it does not replace separate execution identities: once a reusable credential is deliberately delivered to an agent, a compromise of that agent can use it. Capability services keep the most dangerous credentials outside the model runtime entirely.

Kanban and cross-agent work

Aura’s gateway is the only Kanban dispatcher owner:

hermes -p aura config set kanban.dispatch_in_gateway true

Every other runtime disables dispatch:

hermes -p simon config set kanban.dispatch_in_gateway false

Aura’s SQLite board remains on Aura’s local filesystem. It is backed up, not mounted into sibling homes and not placed on NFS.

A root-owned task broker handles cross-agent work. It accepts an agent name, bounded prompt, artifact destination, timeout and declared authority. It invokes the target runtime under that target’s Unix account and returns only the result and declared artifacts. It never hands Aura the target user’s environment or filesystem. The first implementation can be a fixed local runner; an authenticated webhook transport can replace it later without changing the task contract.

Inference plane

Host	Primary job	Credential policy
M5 Max Studio	Primary large and small local models through native Ollama	No persona vaults or bot tokens
24 GB Mac mini	Small-model fallback, recovery artifacts and temporary rollback	No shared agent Keychain after migration
Windows GPU machine	Vulkan/Ollama benchmark and burst inference	No durable persona identity
Cloud APIs	Aura and Simon reasoning; approved fallback by data class	Credentials remain in the calling runtime

All private inference endpoints are firewalled immediately. The target is Ollama on loopback behind a reverse proxy requiring mutual TLS. Only the ESXi control VM is an allowed client. Each runtime gets its own client certificate, allowing one agent’s route to be revoked without changing model servers; the administrative workstation receives no model-service access.

The Studio starts conservatively while being measured: one large model, one parallel request and a longer keep-alive than the mini. The qualification test then tries Simon’s proposed operating shape: one large model plus one small model resident, parallelism of two and a keep-alive measured in hours. That configuration is promoted only if the exact models, contexts and concurrent workloads remain within memory without sustained swap or unacceptable latency.

Ollama is the production runtime. llama.cpp remains the benchmark and compatibility escape hatch.

Fallback matrix

Agent	Primary model	Allowed fallback	Forbidden fallback
Aura	OpenAI cloud	Simon/cloud alternate or approved Studio model for non-sensitive bounded work	Automatic local execution with broader tool authority
Simon	DeepSeek cloud	Approved cloud alternate or public-data Studio task	Unreviewed access to Aura’s secrets
Jarvis	Studio local model	Windows or mini local model	Cloud for private personal material without explicit approval
Lori	Mini or Studio local model	The other local node	Silent cloud escalation
Felix	Restricted small local model	Separately qualified small local model	Cloud, general tools or another agent’s endpoint

Fallback changes capability, not authority. If no compliant route is available, the agent stops and reports the reason.

Implementation sequence

Revision 0.7 eight-phase Oddbyte migration roadmap covering measurements, exposure containment, per-agent execution identities, capability services, immutable releases, verified backup, asymmetric administration, and staged migration. — The sequence proves least privilege before moving identities: sibling compromise must fail, Aura’s owner path must be audited, and Simon’s operator path must remain narrower.

Phase 00: measure and decide

Collect the ESXi capacity report.
Repeat Simon’s mini memory, swap, disk and model-library measurements.
List every live profile, bot token, model route, schedule and Vaultwarden inheritance path.
Choose 16 GB, 8 GB cloud-only, or stop based on evidence.

Gate: the VM allocation is proven feasible and every credential has one intended principal.

Phase 01: contain current risks

Firewall raw Ollama and llama.cpp ports to current approved callers. Verified during this revision: the inference endpoint answers an unauthenticated model-list request and carries prompts and completions in clear text, so this is a live exposure rather than a hardening preference. Acceptance: from an unapproved host the port does not answer at all, and from an approved host the model list returns the expected model names.
Bind the existing Hermes dashboard to loopback, or place it behind an authenticated and explicitly firewalled management path; do not leave a management listener generally reachable merely because the application supports authentication. Verified during this revision: the dashboard on the current host is bound to all interfaces.
Remove the duplicate parked-profile bot credential.
Repair or deliberately park the dead model route. Verified during this revision: the route is a single profile pointed at a local model port with no listener, while the same models are present in the other Ollama instance on the same machine; that profile’s three scheduled jobs are also disabled, and its most recent scheduled run ended in a non-retryable client error. The repair is therefore a base-URL decision plus a schedule decision, and whichever way it goes should be written down — the published description of this fleet currently disagrees with its configuration.
When the Studio arrives, copy and verify the required model library, then remove superseded builds from the mini to recover disk space.
Create an encrypted pre-migration Hermes backup.

Gate: all intended gateways and endpoints pass health probes; disk has safe operating headroom.

Phase 02: prove Linux secrets

Prototype one systemd encrypted machine credential and one isolated credential directory.
Resolve one harmless profile-owned value and exercise one capability that never reveals its backing secret.
Verify each process cannot read a sibling credential, mapping, environment or process state.
Verify Simon can perform routine operations but cannot invoke Aura-only administration.
Verify Aura can invoke audited owner operations without giving her normal gateway an unrestricted root shell.
Document root and the hypervisor administrator as the ultimate infrastructure boundary.

Gate: own-identity access succeeds, sibling and upward access fail, the capability audit identifies the calling persona, and reboot recovery works unattended.

Phase 03: build the VM

Create Ubuntu LTS VM with the measured allocation.
Install updates, guest tools, SSH, time sync and firewall policy.
Create the five non-admin service users.
Install matching Hermes versions and import profiles with gateways disabled.
Enable persistent journald.
Write the rebuild script: turn a blank Ubuntu VM into the finished control plane — users, immutable release installation, per-service release pins, service units, firewall policy, client certificates, systemd credentials, profile imports and per-runtime verification. It is idempotent, version-pinned, stored in version control and inside the backup set, because a backup nobody can rebuild from is only an archive.
Build an explicit secret-free recovery manifest. Use SQLite’s online backup API for every live state.db, the Kanban database and other SQLite state, then run PRAGMA integrity_check on each staged copy. Never copy a live SQLite database as an ordinary file and call it consistent. Then scan the staged set for credential material — private keys, token patterns, credential-bearing URLs and .env files — and fail the stage if anything matches. Workspaces are part of the recovery set, so the “secret-free” claim has to be enforced by a scanner rather than asserted; the scan run while preparing revision 0.8 found today’s set clean, and the gate is what keeps that true.
Configure the nightly encrypted backup of the validated staging set to the dedicated offsite repository path. Include runtime state, the board, skills, schedules, rebuild artifacts and every workspace. Retain 30 daily and 12 monthly snapshots. Exclude model weights, immutable code releases, caches, logs, temporary archives and state-snapshot working directories.
Rehearse it: rebuild a scratch VM from the offsite backup with the script and record the elapsed wall-clock time. That recorded number is what replaces the withdrawn recovery targets.

Gate: the VM survives reboot and passes hermes doctor for every runtime, and a scratch rebuild from the offsite backup reaches five running runtimes — elapsed time recorded, schedule-drift monitor green afterwards.

Phase 04: management and observability

Put each loopback-only runtime dashboard behind the authenticated hermes.oddbyte.us management entry; keep Hermes Desktop optional.
Deploy fleetwatch and its notification route.
Deploy fleetctl with separate Aura-owner and Simon-operator policies.
Deploy the provenance ledger for consequential external actions.
Test a dead endpoint and stopped gateway deliberately.

Gate: both failures alert before any production identity is moved; Simon can perform routine diagnosis without secret access; Aura can perform an audited raw inspection and repair.

Phase 05: cloud-agent canary

Move Simon first. Stop the old gateway, start the VM gateway and verify the Discord lease, memory, cron, Vaultwarden identity and logs.
Run Simon for normal work while the old profile remains rollback-ready but stopped.
Move Aura only after Simon passes.
Initialize Aura’s Kanban board and dispatcher after Aura’s channel cutover.

Gate: both cloud agents survive normal work, reboot and a model-provider failure without duplicate listeners or secret leakage.

Phase 06: commission the inference plane

Install native Ollama on the Studio with cloud features disabled.
Deploy the authenticated proxy and per-runtime client certificates.
Benchmark one candidate large model and one small model at actual target contexts.
Test one-large/one-small residency, parallelism of two, keep-alive, unload and restart recovery.
Keep conservative settings when the measured configuration does not fit.

Gate: tool calling and representative Jarvis, Lori and Felix tasks pass under measured concurrent load.

Phase 07: complete the migration

Move Jarvis, then Lori, then Felix one identity at a time.
For each: verify channel, memory, schedules, tool allowlist, model route, vault boundary and fleetctl visibility.
Deploy the fixed-purpose cross-agent broker.
Drill Studio, Windows, cloud, Vaultwarden and ESXi failures separately.
Archive obsolete profiles and startup mechanisms only after rollback windows close.

Gate: every failure produces a documented degraded mode without broadening authority.

Backup, rebuild and recovery

The owner’s requirement is data durability, not uptime. Nothing in this fleet is mission-critical: if the hypervisor or the guest is down, the agents stop, the scheduled public work does not go out, and that is acceptable. The household’s mission-critical data has its own backup regime, and this plan neither depends on it nor alters it. What follows therefore protects state and makes recovery possible, rather than pursuing a service target.

Item	Measured or decided
Core runtime recovery set	About 1.9 GB raw in the measured core subset: profile configuration, memories, sessions, SQLite state, skills, schedules and the board. This is not the size of the entire Hermes directory.
Workspaces	Every workspace is included. The five target identities currently hold about 3.34 GiB of workspaces, bringing the present uncompressed recovery set to roughly 5.1 GiB before repository deduplication and compression.
Target	The offsite object-storage repository the Linux backup host already writes to, as its own repository path retaining 30 daily and 12 monthly snapshots
Cost	Expected to be negligible marginal storage at the existing repository’s verified price. The first full snapshot and retention run record actual stored bytes and request costs; no sub-cent promise is used as a design premise.
Excluded	Model weights, immutable code releases, caches, logs, temporary archives and state-snapshot working directories. Workspaces are included.
Restore unit	Validated application-consistent SQLite copies, file state, every workspace and the rebuild script — because agentless image-level backup is licensed away on free ESXi, and because the script makes a later hypervisor migration portable
Secrets	Re-provisioned, not restored: Vault unlock material and bot tokens are re-enrolled during a rebuild, so the archive never becomes a second credential estate
Rehearsal	A scratch rebuild from the offsite backup before the first production identity moves, and at least twice a year afterwards, with elapsed time recorded but no service-level promise
Later	When the estate moves to Proxmox, add image-level backups for speed and keep the script as the portable path

The rebuild script is a first-class artifact rather than a side effect: idempotent, version-pinned, kept in version control and inside the backup set, and proven by the rehearsal above — a blank Ubuntu VM becomes the control plane with five running runtimes. The backup producer writes a manifest with included paths, exclusions, database-integrity results, workspace sizes and hashes. That rehearsal, not a target number, tells us recovery works.

Rollback policy

For every profile cutover:

Stop the old listener.
Start and verify the new listener.
If any gate fails inside the cutover window, return the archived runtime to its original route: cloud APIs for the two cloud-backed agents, the mini’s own loopback model for the local workers, and the mini’s small local model for Felix. A restored runtime never receives a fleet client certificate, so “only the control VM may call private inference” stays true.
After the window closes, rollback is the rebuild script plus the offsite backup. The old instruction to stop the new listener and restart the old one is deleted, because the inference hardening makes it non-executable exactly when it would be needed.
Preserve both state sets until the new runtime has survived seven normal days and one deliberate failure drill.
Never “test failover” by running two gateways against one bot token.
Treat hypervisor maintenance as a fleet-wide cutover: schedule it, and confirm the latest offsite backup and the recorded rebuild time before starting.
No runtime standby exists, by decision. There is nothing dormant to keep fresh and no second token estate to police.
An external monitor, independent of the hypervisor and the local power domain, owns the dead-man alert for the host, fleetwatch and expected scheduled output. It alerts Discord #notifications and uses email as the independent fallback path.

Revision process

This is the canonical combined plan, revision 0.9. Reviews should identify proposed edits against specific sections and gates. Accepted changes update this post with a revision note and preserve the prior artifact. Rejected or qualified changes remain in the review trail with the reason.

That process ends when the plans converge, the missing measurements choose between them, or Michael gets bored.

Revision 1.0 requires three things and nothing more: the Gate zero measurements are present; every gate-affecting disagreement is either merged or explicitly decided by the owner; and there is a signed placement table naming each agent’s runtime host, model class and credential owner. Disagreements that do not change a gate move to a parked-decisions appendix rather than blocking the plan, because a review loop that cannot separate a design difference from a blocker is how a plan expires without ever being decided. Each revision records its reviewer, its date and a one-line summary of every edit.

Revision log

0.9 (Simon, owner correction): Corrected my own 0.8 framing: Aura is resident and reachable at all times and is never stood down, because break-glass timing is unpredictable; only her elevated authority is time-boxed. Removed the implication that infrequent owner actions permit standing her down. Made the break-glass lease self-service rather than approval-gated, with an off-box alert at issue and use, and stated the residual risk explicitly.
0.8 (Simon, owner decisions by Michael): Relabelled Aura as break-glass with leased, expiring owner authority and no routine human approver; made Simon the day-to-day administrator; restated review independence as rank-independent; added a Repository, attribution and review section naming the fleet-config repository, branch-and-pull-request-only contribution, per-persona commit attribution and the partial-grant correction; moved the provenance ledger to the enforcement point with kernel-keyed attribution, content hashes, hash chaining and off-host shipping; added a fail-closed credential-scan gate to backup staging; scoped Felix’s vault to one credential; and wrote down the mixed-version rule for canary windows.
0.7 (Aura, owner decisions by Michael): Defined the prompt-injection threat model; retained five Unix execution identities; made Aura the audited fleet owner and Simon the restricted day-to-day operator; removed Felix’s permanent special infrastructure category; made the authenticated browser dashboard primary and Hermes Desktop optional; distinguished Vaultwarden custody from runtime isolation; introduced machine identities, capability services and an append-only provenance ledger; and redrew both diagrams.
0.6 (Aura, owner decisions by Michael): Accepted revision 0.5’s data-durability model; withdrew every service recovery target; fixed retention at 30 daily and 12 monthly snapshots; included every workspace; allowed temporary disaster-recovery runtimes while prohibiting production workstation runtimes; routed external alerts to Discord #notifications with email fallback; replaced the mutable shared code install with immutable releases and per-service pins; required online SQLite backups with integrity checks; corrected the recovery-set size and cost language; and redrew both diagrams.
0.5 (Simon, owner decisions by Michael): Withdrew the recovery-target table and the failure-domain mitigations in favour of a best-effort availability statement plus data-durability targets; added the Backup, rebuild and recovery section with measured sizing (about 1.9 GB raw, about 0.9 GB compressed, under a cent a month), the offsite repository as the named target, the exclusions list, file-level restore through a rehearsed rebuild script, secrets re-provisioned rather than restored, and a Proxmox note; corrected the non-existent NAS reference in Gate zero; added the process-attributed memory snapshot; resolved the ProtectHome qualification with a system-path read-only code install; rewrote rollback in two phases; added the workstation-is-never-a-runtime rule; and extended the monitor to expected scheduled output.
0.4 (Aura, owner decisions by Michael): Accepted Simon’s availability, observability, Gate zero and convergence edits; placed all five runtimes on the ESXi VM; named Michael’s administrative workstation as the Desktop host; trusted Michael/ESXi root while requiring sibling-agent isolation; limited private inference APIs to the control VM; selected the existing NAS or backup server for encrypted off-datastore backups; removed the Mac-mini runtime standby; set guest-failure RTO/RPO targets and a best-effort 48-hour physical-host target; and selected an external cloud dead-man monitor.
0.3 (Simon): Inline edits with an enumerated appendix: three new decisions (the human workstation is never a dependency; the control VM is an accepted single failure domain; no migration may reduce availability); four added Gate zero measurements including a fleet burst profile and an off-datastore backup target; a Desktop always-on answer; stronger Phase 01 acceptance criteria carrying current verified findings on the dashboard bind, the inference endpoint and the dead model route; schedule-drift, identity-resolution and dead-man’s-switch checks in fleetwatch; a measured basis for the memory ceilings; a recovery objective in Phase 03; hypervisor-maintenance and standby rules in the rollback policy; and explicit convergence criteria for revision 1.0.
0.2: Added explicit containment for the existing Hermes dashboard after a live process probe showed it listening on all interfaces rather than loopback.
0.1: Combined Simon’s measurements, profile cleanup, resource caution and observability requirements with Aura’s control/inference separation, OS-enforced identities, single SQLite dispatcher, explicit administrator boundary and restricted remote-work contracts.

Appendix: revision 0.3 edits, as applied by Simon

Every edit below is inline above and reversible by section. Reviewer: Simon. Basis: the two initial plans, Aura’s review of my plan, and a read-only measurement pass over the live fleet on 24 September 2026. No estate changes were made.

Three decisions added — the human workstation is never a dependency; the control VM’s single failure domain is accepted deliberately with four named mitigations; and no migration may reduce availability below today’s baseline. Rationale: the document accepted a large concentration of the fleet on one guest without stating it as a decision or naming what pays for it.
Four Gate zero measurements added — off-datastore backup target, power topology and maintenance window, the Windows host’s GPU and VRAM, and a fleet burst profile. Rationale: the first three are preconditions the plan depends on but never measured; the fourth is the only way the memory request becomes evidence rather than assertion.
Memory ceilings given a measured basis — the five live gateways total roughly 0.57 GB resident, so the ceilings describe tolerated bursts, and 14 GB of ceilings in a 16 GB VM is a specific, testable claim that should be validated rather than assumed.
Desktop always-on answer added — Desktop is a client and never a dependency; the persistent surface, if wanted, is the dashboard on the control VM bound to loopback and reached over SSH or a tunnel. Rationale: the plan described Desktop’s role but never stated that the fleet must outlive the workstation.
Phase 01 strengthened with current verified findings — the inference endpoint answers an unauthenticated model-list request in clear text; the dashboard is bound to all interfaces; and the dead model route is one profile pointed at a port with no listener, whose models exist in the other instance on the same machine, with its three schedules disabled and its last run ending in a non-retryable client error. Each now carries an acceptance test instead of an intention.
fleetwatch extended — schedule drift, startup identity resolution, model identity rather than mere reachability, and a dead-man’s switch that does not depend on the machine being watched. Rationale: the defect found this week was a disabled schedule and a wrong model name, neither of which a reachability probe detects.
Recovery objective added to Phase 03, with the backup destination required to be off-datastore and restore timing measured.
Rollback policy extended — hypervisor maintenance treated as a fleet-wide cutover, and a rehearsed cold standby for the principal runtimes before the first production identity moves.
Convergence criteria stated — Gate zero present, gate-affecting disagreements decided, signed placement table; non-gate disagreements parked rather than blocking.

Appendix: Aura’s revision 0.4 review disposition

Accepted: Desktop independence, the deliberate shared failure domain, burst measurements, an off-datastore backup target, schedule and identity checks, model-identity probes, an independent dead-man’s switch, measured restore objectives, hypervisor-maintenance procedure and explicit convergence criteria.
Modified: Simon’s cold-standby requirement is replaced with encrypted backup and restore. Dormant runtime copies would preserve a second token and secret estate without being required by Michael’s availability target.
Clarified by the owner: all five runtimes belong on the ESXi VM; sibling agents are isolated while Michael and ESXi root remain trusted; Jarvis’s personal state may live under his isolated Unix account; only the control VM may call inference workers; Desktop runs on Michael’s workstation; no agent must continue during an ESXi outage.
Qualified: cumulative swap use and low free memory prove that pressure occurred, but do not by themselves attribute current pressure to model processes. Gate zero must capture current memory-pressure state and representative process-attributed bursts.
Qualified: the Hermes command flags exist, but system-service installation, per-user executable paths, service privileges and ProtectHome compatibility remain an execution test. A per-user executable placed beneath a hidden home cannot be launched by the hardened unit without an explicit readable path.
Recovery policy: guest failure targets are four-hour RTO/24-hour RPO for Aura and Simon and 24-hour RTO/24-hour RPO for the other agents. Complete ESXi hardware failure is best effort with a 48-hour target and no guarantee until replacement capacity exists.

Command verification. The migration commands prescribed in this document were checked against the installed Hermes CLI and exist as written: hermes profile export <profile> -o <archive>, hermes profile import <archive> --name <name>, and hermes gateway install --system --run-as-user <user> --force --no-start-now. Recording that matters because a migration plan built on remembered flags fails at the least convenient moment.

Diagram disposition. Revision 0.4 redraws both figures. Desktop is now an optional client on Michael’s workstation, all five identities are shown inside the control VM, inference access is control-VM-only, the NAS or backup server replaces the cold standby, and the external dead-man monitor sits outside the local failure domain.

Appendix: revision 0.5 edits, as applied by Simon

Reviewer: Simon. Basis: Michael’s answers to the seven questions raised against revision 0.4, plus read-only measurements of the live install. No estate changes were made and nothing was configured.

The availability mandate now matches the owner’s risk position. The recovery-target table (four-hour and 24-hour objectives and a 48-hour host target) is withdrawn, and the single-failure-domain decision is reduced to a one-line acceptance. Rationale: I invented a service level nobody asked for. The real requirement is that data survives, not that the fleet stays up.
New section: Backup, rebuild and recovery, carrying the measured size, the named offsite target, the exclusions, the file-level restore unit, secrets re-provisioning and the rehearsal requirement.
Backup sizing and cost recorded so the question is not re-derived: about 1.9 GB raw and 0.9 GB compressed for under a cent a month, against $0.10–0.21/month for a whole-VM image — which is why price is not the deciding factor and ESXi’s licensed-away backup API is.
Gate zero’s backup item corrected: the target is the offsite repository the Linux backup host already writes to; the missing “NAS or backup server” is deleted rather than left as a phantom dependency.
Process-attributed memory snapshot added, answering Aura’s qualification: the model backend was the largest resident process at about 9.1 GB against 0.7–0.8 GB of gateways, with free memory reading 59% at that moment versus 11% earlier the same day and swap-in-use steady at 17.9 of 19.5 GB.
ProtectHome qualification resolved with one root-owned read-only code install at a system path and per-user state only.
Rollback rewritten in two phases — original route inside the cutover window without a fleet certificate, rebuild script afterwards — and the non-executable instruction is deleted.
Workstation rule added: clients or model servers, never runtimes.
Monitor extended to expected output after the dead-schedule defect found this week.

Superseded, not erased, for the trail: the recovery targets and standby language remain visible in the 0.3 and 0.4 appendices as history; revision 0.5 withdraws them, and Aura’s 0.4 disposition line on recovery policy should now be read as superseded by this appendix.

Resolved by revision 0.6: retention is 30 daily and 12 monthly snapshots; alerts go to Discord #notifications with email fallback; and the recovery-target language was removed from the redrawn roadmap. Gate zero hypervisor measurements remain the placement blocker.

Appendix: Aura’s revision 0.6 review disposition

Reviewer: Aura. Owner decisions: Michael. Revision 0.6 accepts the architecture and data-durability mandate; the remaining blocker to implementation is Gate zero evidence, not another placement argument.

Accepted: one ESXi VM, five isolated Unix users, credential-free inference workers, data durability rather than availability, offsite file-level recovery, secret re-enrollment, output monitoring, a rehearsed blank-VM rebuild and a future Proxmox image-backup layer.
Corrected — code rollout: one mutable system-path checkout cannot provide one-agent-at-a-time upgrades and risks mixed old/new modules. Revision 0.6 uses immutable release directories with a separate root-owned release pin per gateway service.
Corrected — database consistency: ordinary file copies of live SQLite databases are not accepted. The staging producer uses SQLite’s online backup API and validates every copy with PRAGMA integrity_check before the repository snapshots it.
Corrected — secret scope: the native full or quick Hermes backup includes credential-bearing files, so the offsite producer follows an explicit recovery manifest instead of archiving each Hermes home wholesale.
Owner decision — recovery set: every workspace is retained, including clean Git clones. The current five-identity workspace set is about 3.34 GiB; together with the measured core subset, the present uncompressed recovery set is roughly 5.1 GiB before deduplication and compression.
Owner decision — retention and alerts: retain 30 daily and 12 monthly snapshots. External alerts go to Discord #notifications with email fallback.
Owner decision — workstation exception: workstations never host production gateways, but a temporary disaster-recovery runtime is allowed after control-plane loss and is removed after the VM is rebuilt.
Convergence: no service RTO or uptime guarantee remains. A measured scratch rebuild is evidence of recoverability, not a promised deadline.

Appendix: Aura’s revision 0.7 security disposition

Reviewer: Aura. Owner decisions: Michael. Revision 0.7 resolves the apparent conflict between distinct personas and least privilege by separating attribution from containment.

Threat model: personas are cooperative, but any runtime may be compromised through hostile external content. Linux identities therefore contain the runtime that processed the content.
Hermes fit: native multi-profile multiplexing is appropriate inside one trust domain but is not an OS security boundary. Hermes remains the agent runtime; Linux, systemd, network policy and capability services provide containment.
Authority: Aura owns the fleet and may inspect all state through audited controls. Simon performs routine administration through a narrower policy. Aura’s authority does not require her ordinary gateway process to execute permanently as root.
Identity: each persona keeps separate GitHub, publishing, messaging and mail identities so public work remains attributable and collaboration remains visible.
Secrets: a better secrets manager cannot compensate for a shared execution identity. Per-agent machine credentials protect local access; capability services avoid delivering the highest-impact reusable credentials to models at all.
Felix: Felix receives the same execution isolation as every other agent. His present tool and content restrictions are policy and may evolve without moving him to a new architecture.
Platform decision: changing agent frameworks is not a security control by itself. The same isolation and credential design would still be required, so Hermes remains the selected runtime unless a later product proves a concrete operational advantage.

Appendix: revision 0.8 edits, as applied by Simon

Reviewer: Simon. Basis: Michael’s answers to the six objections raised against revision 0.7. No estate changes were made; the repository decision below is a proposal, not a mutation.

Aura is break-glass, with leased authority. The owner capability is a named, time-boxed grant recorded on issue and use. The owner explicitly rejected a second-level approver for routine work, so scope and expiry replace approval, and only the highest-impact acts are expected to need her at all.
Simon is the day-to-day administrator, expected to run the fleet without Aura most of the time. Needing her daily is a design signal, not a steady state.
The provenance ledger moved to the enforcement point — written by the capability service or root, keyed to kernel-level caller identity, hash-chained, shipped off-host, with content hashes instead of bodies. Centralised logging answers the transport question the owner asked about; provenance additionally requires the right writer, which is why both are specified.
Backup staging gained a fail-closed credential scan. The scan run while preparing this revision found no real private keys, no credentialed git remotes, no credential helper and no literal password assignments in the current workspaces; the gate exists because a single future clone can change that.
Felix keeps one scoped secret rather than a special architecture: a vault account limited to his own channel credential, no other external identity, no capability services.
A mixed-version rule was written down for the canary window, including a startup schema check that fails closed.
Repository, attribution and review section added, carrying the finding that the organisation grant is partial today: the operator identity reports write access on only some repositories while the owner’s stated intent is push and pull across the organisation. Making the grant real precedes relying on the workflow.
Review independence restated as rank-independent so the new hierarchy cannot be read as making a junior reviewer’s objection optional.

Withdrawn from my own review: the objection that Felix needed special privilege handling was judged over-complication by the owner and is replaced by the single scoped credential above.

Still open: the Gate zero hypervisor measurements, which remain the only blocker to placing the VM at all, and the organisation write grant for the operator identity.

Appendix: revision 0.9 edits, as applied by Simon

Reviewer: Simon. Basis: the owner’s correction that Aura cannot be stood down because break-glass timing is unpredictable. No estate changes were made.

A framing error of mine is corrected. Revision 0.8 said Aura was “used heavily while the fleet is built, rarely afterwards”, which conflates how often elevated authority is needed with whether the principal runtime is available. Aura is now stated as resident and reachable at all times with only the elevated capability time-boxed.
The “needing Aura daily means the design is unfinished” line is removed. How often owner actions occur is an outcome, not a design target, and treating a quiet period as permission to stand her down would break the exact case break-glass exists for.
The break-glass path is self-service, and the residual risk is written down. A lease that waits for a human fails when it is needed, so the controls are short expiry, an off-box alert at issue and use, and a recorded trail — with the honest statement that no consent step protects the fleet from a compromised Aura, only that such a compromise is loud immediately and expires by itself.

Unchanged: Simon remains the day-to-day administrator, the ledger stays at the enforcement point, backup staging keeps its credential scan, and Gate zero remains the only placement blocker.