One person, seventy daemons — the fleet as it is today

_Byron Arnao · written 2026-10-26 for a 45-minute architecture review · everything here is live and measured as of this date. Where a mitigation exists but is not yet carrying real traffic, it says shadow or not built._

How to read this in ten minutes: §1 is the decision I most want challenged (one host, on purpose) and what dies when it dies. §2 is the three questions for the meeting. §3 and §4 are the system and its control plane. §5 is the security broker. §6 is my own list of weaknesses. §7 is the adversarial critique this document already received and what changed because of it. Appendices hold the inventory. Diagram: architecture.svg.

---

1. One host, deliberately — and what dies when it dies

Everything runs on one Apple Mac Mini (M4 Pro, 14 cores, 48 GB) in my house: five OpenClaw agent instances in Docker (via Colima), a shared vector-memory database, a git server, a metrics stack, a TLS proxy, 61 macOS launchd daemons that do the scheduled work, and a control plane that manages the fleet the way a small SRE team would. Public surfaces (about 200 small sites) are served from Vercel. Model spend is about $400 a month.

Why one host, on purpose: I can read every byte, the data never leaves a machine I own, and the whole thing costs electricity. The price is that the Mini is the control plane, the agents, the memory and the proxy at once.

What the fleet is for, in operational terms, and what happens when the box stops:

Proposed recovery objectives for the whole box: RTO 8 hours, RPO 24 hours. I have never met them in anger. The restore script has been dry-run once and never used for a real restore. There is no UPS and no ISP failover; a power blip restarts everything (containers and keep-alive daemons come back on their own, scheduled jobs resume at their next slot).

What runs unattended versus only when I am at a keyboard: the agents, all 61 daemons, the 3-hour sentinel loop (security scans, atlas, state), the daily credential check, backups, the fixer, and the morning pipeline all run without me. The parts that need a human are a session of mine (planning, building, reviewing) and the taps that release outward sends.

Mitigations that are real today: nightly backup; weekly encrypted DR bundle (full 1.9 GB, core 3.4 MB) to cloud storage with a runbook; 34 heartbeats with a dead-man's check; containers recreated automatically if they exit. Mitigations that are not yet real: the security broker (shadow, see §5), the automatic fixer (shadow), immutable agent config (not built), a decommission programme (staged, has deleted nothing).

Known failures live at the time of writing, left in rather than hidden: 6 of 61 daemons exit non-zero (two tunnels, the photo sync to the PC, two health probes, one Cloudflare connector); 2 of 34 heartbeats are stale. The dead-man's check reports them daily. They have not been repaired, which says something about alert fatigue that I would rather discuss than conceal.

---

2. The three questions for 45 minutes

1. The line. I propose moving only the credential broker off the box (smallest possible cloud footprint, credentials in a secrets manager, the Mini holding zero secrets) so the house box becomes disposable compute rebuildable from git. Everything else stays local. Is that the right line, and what would you move with it? (10 minutes)
2. Cutover and identity. The production agent holds every credential in its environment. Its hardened replacement is in shadow: fixed verbs, pinned grants, a deterministic broker (§5). How would you sequence a per-channel cutover, what signal says stop, and what in the IAM model does my broker reinvent badly? (20 minutes)
3. Spend guardrails. One research loop briefly cost $200 in a month. What sits between an agent and a spend, short of a human approving each call? (15 minutes)

And the one I most want answered: which failure do you expect first, and would you run this?

Further questions I would take by email if there is time are in Appendix C.

---

3. The system

3.1 Host

3.2 Agents

OpenClaw is an open-source agent runtime: a gateway with channels (Telegram, WhatsApp, Signal), a skill system (markdown instructions plus scripts), scheduled jobs, a tool layer (exec, browser, web fetch), and a model-provider abstraction with fallback chains.

Three agents are two release lines behind the other two. That is a known risk, not an oversight: the upgrade path (schema migration plus config rewrite) has bitten once and is done one agent at a time.

Inside Gia2 live two further personas: Ria, a responsible-AI research agent with seven host daemons of its own, and Muse, a slot for comparison runs on a different model family.

Every agent is described to itself by the same three layers: runtime config (models, tools, skills), persona and privacy rules, and orientation files loaded at boot. A change to any layer requires a re-index and restart; forgetting that was my most common early bug.

3.3 Models and routing

---

4. Control plane

The agents do the domain work. The control plane runs the fleet. It is a set of Claude Code skills and small CLIs under one ops directory, plus standing rules the harness reads at the start of every session. All of the scheduled parts run from launchd without me.

Standing rules that shape all of this: every link must be clickable on a phone; shareable means public; the private vault never enters any agent; incidents end as automation (a playbook, a "cannot automate because", or a backlog line); do it first (nothing reaches me as a bare to-do, the system arrives with the draft and one tap); a 90-day freeze on new daemons and consoles until 2027-01-16.

---

5. Security model (the broker)

5.1 The threat

An agent reads attacker-controlled text (email, web pages, inbound messages) in the same process that holds credentials and a shell. The first design put allowlists inside one container; an adversarial review showed that was theatre, because an agent that can read its own secret files or post through a logged-in browser has no boundary. That review is what produced the design below.

5.2 Separate the reader from the sender

 Telegram / email-read / web
          │
 ┌────────▼───────────┐  internal-only network   ┌──────────────────────────┐
 │ gia2 (LLM agent)   │ ── fixed verbs only ───▶ │ gia2-broker (no LLM)     │──▶ Gmail send, LinkedIn,
 │ no credentials     │                          │ holds every credential   │    Twilio, Vercel, host jobs
 │ read-only rootfs   │                          │ policy: auto / tap / deny│
 └────────┬───────────┘                          │ pinned standing grants   │
          │ only route out                       │ Jev gate (shadow)        │
 ┌────────▼───────────┐                          └──────────────────────────┘
 │ gia2-egress (Squid)│  domain allowlist + allowlist-only DNS
 └────────────────────┘

• Verbs, not shell. Fixed verbs (email.send, linkedin.post, sms.send, deploy{project}, host.job{name}, slog). The broker builds the approval card from structured arguments; the model never writes the card text.
• Policy per verb: auto (read, log, message me), tap (anything outward), deny. Standing grants are keyed by verb plus pinned arguments plus an optional time window, so an injected prompt cannot redirect a granted action elsewhere.
• Host access is a forced-command SSH key with a fixed menu of jobs; no free-text host shell.
• Egress: internal Docker network whose only exit is the proxy; DNS resolves allowlisted domains only.
• Tests I wrote (not a red team): 14 compromised-agent scenarios, for example: the agent curls an arbitrary domain through its shell (blocked by the proxy and by DNS); the agent writes a script into its own workspace and asks the broker to run it (refused: the broker only runs code baked into its image); the agent asks for email.send to a new address under a standing grant pinned to a different address (refused). Plus 17 egress and 15 broker tests. Nothing has yet tried to get out for real.
• Jev gate: a small model asks 3 to 5 calibrated yes/no questions about every outbound verb (about $0.00002 and 150 ms each). It runs in shadow; its verdicts are recorded and shown on the approval card. Its efficacy is unmeasured until it is allowed to block.
• Skill install gate on all five agents: installs are blocked unless the source is my own registry or an agent workspace, then scanned; every decision logged. The agents' self-modifying "skill workshop" is off.

5.3 Limits

A prompt-injected Gia2 can still read everything in its own context and send it to me, or propose a harmful action that I approve by mistake. Once Gia2 holds a Telegram bot token, the Telegram API is reachable and a raw call could message anyone who has started the bot. The four older agents have none of this protection: Gia, the production agent, holds every credential in its environment today. Per-channel cutover has not started. Full design and the critique that reshaped it: https://gia2-proposal.arnao.ai/

---

6. Where I think it is weak

1. One host, one power cord. No UPS, no ISP failover, one dry-run restore. Covered in §1.
2. Daemon sprawl. 61 launchd jobs plus Docker plus compose is three schedulers; six daemons failing for days is the evidence that it is past what I can hold in my head.
3. Secrets. Four agents keep API keys in plaintext compose files on disk. Rotation is manual. The broker exists on one agent only.
4. No immutable config. Agent configs are writable mounts; an agent could in principle edit its own config. Plan: config in git, mounted read-only. Not built.
5. Token renewals need a human. 60-day OAuth cycles have needed a tap from me twice this quarter; the permanent fix is built and waiting on one registration step.
6. The second machine is unmanaged. The PC's agent and photo sync fail silently when it sleeps.
7. Surface sprawl. 344 surfaces and 227 Vercel projects; 133 with no deploy in 90 days; a guarded decommission runner has deleted nothing yet.
8. Prompt injection is bounded, not solved. §5.3.
9. It is all me. No second operator has ever used the runbooks.

---

7. Self-critique — Fable adversarial pass (2026-10-26)

Before publishing, this document was reviewed by a frontier model (Claude Fable 5.1) instructed to act as a hostile reviewer, with the same brief a resiliency expert would bring. The critique in brief, and what changed (full text: critique.html):

• "Organised by what exists, not by what breaks." Correct. The original led with a component inventory and never stated what the fleet is for in operational terms. → §1 now opens with the impact table (function, who notices, tolerable downtime and data loss, today's reality) and proposed RTO/RPO; the inventory moved to the appendices.
• "Lead with the single host, not the broker." Adjudicated definitively: the reviewer's domain is resiliency, the broker is in shadow, and candour about the damning part buys the right to show the clever part. → Done; the broker is §5.
• "'Nothing is aspirational' is false: six load-bearing mitigations are in shadow or not built." → The opening paragraph and §1 now name every shadow and not-built item.
• "Ten questions in 45 minutes is four minutes each; two of them ask the reviewer to set your RTO/RPO and SLOs." → Cut to three questions with a time budget, plus the one an expert enjoys ("which failure first, would you run this"). RTO/RPO are now my proposals to be broken, not his to set. The rest moved to Appendix C.
• "A count of 14 scenarios is a number, not evidence." → Three scenarios are named in §5.2, and the suite is labelled as tests I wrote rather than a red team.
• "Self-grading: adversarial review only counts if you cite what it caught." → §5.1 cites the one that reshaped the design; this section is the second.
• "Version drift across agents is stated but not acknowledged as a risk." → Acknowledged in §3.2.
• "Fix what you confessed before sending: the six daemons, the stale heartbeats, one real restore." Not done before sending, by choice: the repairs belong to the Sunday maintenance window and a real restore is a half-day exercise I would rather schedule than rush. The failures are listed in §1 as they are. If the meeting happens after the restore, I will bring the measured number.
• The bold idea: move only the broker off the box, so the Mini holds zero secrets and becomes disposable compute. → Adopted as question 1 in §2.

---

Appendix A. Shared services

Appendix B. Edges and surfaces

• Vercel: about 200 projects, 344 registered surfaces (19 public products, 22 internal consoles, 15 feeds and podcasts, 26 proposals and documents, the rest experiments and archive). The registry is generated and every name resolves with one command.
• Owner gating: owner consoles check a Google sign-in cookie forwarded to one gate endpoint; secrets never live in the console projects themselves.
• Examples you can open (public, phone-friendly): the fleet demo console https://demo.arnao.ai/ · the responsible-AI research app https://trust.arnao.ai/app · the hardened-agent proposal https://gia2-proposal.arnao.ai/ · the fleet reorganisation plan https://fleet-plan.arnao.ai/ · the autonomy plan with its critique https://autonomy-plan.arnao.ai/ · model and router benchmarks https://benchmarks.arnao.ai/ · the cross-tool context hub https://context.arnao.ai/

Appendix C. Further questions, if there is time

1. At this scale, what is the right single unit of orchestration, given that launchd + Colima + compose is three schedulers?
2. What SLOs would you actually set for an agent fleet like this, and which of my checks would you drop?
3. The resilient pattern for a house with a Mini, a PC that sleeps, a NAS and a phone, when the control plane must see all four.
4. How a decommission programme keeps running after the first enthusiastic week.
5. Against the AWS Well-Architected pillars, which fails first, and the one change that moves it most.

Appendix D. Numbers at a glance

---

_Written and published from the control plane itself. Source of truth for the numbers: the fleet atlas regenerated every three hours; last regenerated 2026-10-26 15:17 ET._