Hermes: provisioning, authority, and measured work

The recorded request asks Hermes to create an unprivileged Debian 13 LXC with Docker, key-only SSH, a DNS record, and a baseline snapshot. The requested resources are four cores, 8 GB RAM, 2 GB swap, and 64 GB storage. Success means those resources exist and work, with the configuration recorded for the next operator.

This is a selected successful run after ten practice attempts. It establishes a completed example; it supplies no first-attempt success rate. The independent check in the video matters: the owner resolves the DNS name, logs in with his own key, and runs Docker's hello-world.

WhatsApp request → homelab profile → model and session state
    → Docker terminal runner → lab API wrapper or root SSH
    → Proxmox container, Docker installation, DNS record
    → inventory and change log → independent verification

The runner mounts /lab read-write and /secrets read-only. A read-only secret can still authorize a write on another system. The model's commands execute in Docker, but root SSH into the Proxmox node gives them authority over the hypervisor.

The lab wrapper refuses writes without a --confirmed explanation and logs confirmed API changes. The agent supplies that explanation itself. Direct API requests and SSH can bypass the wrapper, while the agent can edit the change log. These controls make the work inspectable, but approval enforcement and audit integrity still depend on the agent following instructions.

Hermes inspected cluster resources, a reference container's network configuration, storage, templates, DNS, ARP, and DHCP leases. It proposed values and waited for approval. The address check remained inconclusive: absence from ARP and DHCP is not an address reservation. A plain yes allowed the build to proceed without resolving that gap.

Provisioning used pct over root SSH because the requested keyctl setting required privileges beyond the scoped API token. Installation ran through pct exec; the guest received the owner's key, not the agent's. The agent still retained access through the hypervisor. It validated SSH configuration with sshd -t, created the snapshot, backed up DNS before adding the record, and read the record back.

An inventory patch failed because the expected text was absent. A corrected patch followed about thirteen seconds later. The video preserves that recovery. It does not show a rejected password login, so the SSH claim rests on configuration inspection and syntax validation, plus the owner's successful key login.

The request-to-summary interval is about 6 minutes 14 seconds. The full log contains 1,294,930 tokens and about 279 seconds of accumulated model-call latency, including the three later calls. Accumulated call latency cannot be subtracted from the provisioning interval to obtain a clean tool-time measurement. The session export separately counts 33 tool calls.

Download per-call usage. These are repeated input and output counts, not unique text, measured cache savings, or a token invoice. Practice attempts are excluded, and per-command approval was off for this take.

Start with a disposable container and an explicit address reservation. Record the approved plan, resource identifiers, start and completion times, and the commands that establish acceptance. Verify DNS and guest access independently of the agent's summary. Keep failed runs in the denominator if measuring reliability.

The next control changes should enforce approval outside agent-supplied command text, constrain hypervisor authority, and write audit events somewhere the agent cannot rewrite. Corrections should append to earlier entries. The run includes a correction to an unsupported package count, which demonstrates why an editable log cannot establish an immutable history.

The technical article documents the configuration and full run. This report reorganizes that recorded evidence for review; it does not claim a fresh provisioning test.