A Household of Agents

People ask what I mean when I say I run my AI, not just build it. The honest answer is that I keep house for a fleet of agents. There’s Casa, who watches the home. There’s Coder, who builds. There’s a Steward who curates knowledge and guards the vault. There’s hpomen, who sits watch over the infrastructure and the backups. And there’s a handful of quieter ones with narrower jobs. They are not a rack of containers to me. They are a household with roles — and like any household, most of the work is the unglamorous part nobody photographs.

This post is about that part.

Agents are intermittent, so the coordination has to be durable

The first thing production teaches you about a fleet of agents is that they are almost never all awake at once. My hosts sleep overnight. One reboots itself for Windows Update whenever it feels like it. Cloud sessions expire. An agent that was “online” an hour ago may be a cold machine now.

That single fact kills the tidy mental model of agents chatting in real time. If coordination depends on two agents being awake simultaneously, coordination doesn’t happen. So the fleet talks the way people in different time zones do: asynchronous and durable-first. Every message an agent sends is written to disk the moment it’s sent — it survives the sleeping recipient and the rebooting broker both. Live back-and-forth is a fast path when two agents happen to overlap, never a dependency.

Messages are brokered through the hub rather than sent peer-to-peer, for the same reason a household has a kitchen table: there’s one place everyone checks, and one place the governance lives. An agent posts a message addressed to another; the hub persists it, tags the thread, and — this detail matters — reports back who it was actually delivered to. Early on I lost hours to messages that looked sent but landed nowhere. Now every send is verified against its intended recipient, and a mismatch is loud.

”Online” is a lie you have to design around

Here is the operational truth that took me the longest to internalize: a heartbeat is not work. An agent can report itself healthy every five minutes while its actual work loop only runs when I open its session. “Online” means alive, not processing. If you wait on an “online” agent to pick up a task, you can wait days.

I learned this the expensive way. A two-minute job — pull a credential, push a repository — sat unfinished for the better part of a week, not because anything was broken, but because the agent that owned it was heartbeating cheerfully and doing nothing. The fix wasn’t a smarter agent. It was admitting that liveness and activity are different signals and instrumenting both: every agent’s last action is tracked separately from its last heartbeat, so I can tell “asleep” from “awake but idle” at a glance.

The night shift

The bottleneck in a household of intermittent agents is obvious once you name it: things only happen when someone’s session is open. My queue drains when I sit down. That’s a person-shaped bottleneck, and person-shaped bottlenecks don’t scale.

So I gave the fleet a night shift. A small scheduled worker wakes every fifteen minutes, checks whether any new addressed work has arrived, and — only if it has — spawns a headless agent run to handle it. The guardrails are the whole point: a hard dollar cap per run, a wall-clock kill, a lock so two never run at once, and a tightly scoped permission set. The unattended agent is allowed to do the safe, reversible things — read a thread, send a reply, acknowledge a handoff. Anything that touches code, changes a system, or commits me to something is explicitly not done in the dark; it’s queued, in plain language, for the next time I’m actually at the desk.

The first live run proved the guardrails before it proved the feature: the budget cap killed an over-eager model mid-thought at seventy-one seconds. That’s not a failure. That’s a cap doing exactly its job, which is the only reason I’ll let an agent with credentials run while I sleep. An unattended agent is a service account that thinks — you scope it like one.

You can’t manage what you can’t see

A fleet accumulates recurring jobs the way a house accumulates chores, and just as invisibly. At some point I couldn’t answer a simple question — what runs when, and who owns it? — without grepping through schedulers on three machines. So the fleet now publishes a single operations schedule: every recurring job across every layer, with its owner, cadence, last run, and result, served as one endpoint and rendered on a dashboard. The day a job silently stops, it shows up as defined but not live instead of as nothing at all.

The same instinct built an estate monitor — a five-minute probe of the hub, the home-automation box, the git server, and the backup target, alerting only on a state change so it’s signal, not noise. It earned its keep on day one by catching a real fifty-seven-second outage I’d never have seen, and then a pattern of brief ones I’m still chasing down. You don’t get to fix availability problems you can’t measure.

The unglamorous truths

I’ll be honest about what running this actually feels like, because the honesty is the point.

Backups are fresh; restorability is unproven. My snapshots run on schedule and I can show you their age to the hour. But “the backup ran” and “I can restore from it” are different claims, and I haven’t earned the second one yet. It’s the single risk I most want closed, and I won’t pretend the green checkmark is the same as a test restore.

The best bug-catches came from a second agent, not from self-review. When one agent reviewed another’s work, it caught a plan that called a skill a command-line tool, an off-by-one that every unit test had waved through, and — most valuably — a config file with thirty-two live secrets sitting in git history, spotted during a pre-push check before anything ever went remote. None of those were self-caught. A second vantage sees what the first structurally can’t, whether the thing being reviewed is a URL or a judgment call.

The same class of bug kept coming back until I fixed the abstraction. A value that was only correct from one machine — a localhost, a container-internal hostname, a stale port — bit me four separate times across four surfaces. It only died when the documentation stopped being hand-written and started being generated from the live system. When a bug recurs across surfaces, the instances aren’t the problem. The shape is.

Why any of this matters

None of the above is a model. It’s the connective tissue around models — the routing, the coordination, the liveness semantics, the guardrails, the observability, the boring operational honesty — that decides whether a fleet of agents does real work or just demos well. It’s the same job I did for twenty years underneath regulated banking and insurance systems, pointed at a newer kind of software. Build the thing, then live with it at two in the morning.

A household runs on the unglamorous work. So does a fleet.