The Morning Briefing Learned to Count to Three
For the first two months, the morning briefing checked one machine. At 7am every day, a cron job would fire, read my calendar, scan my unread emails, check the overnight sessions, and send me an HTML email with everything I needed to start the day. One machine, one set of health checks, one perspective.
Then I added the Mac. And the business agent. And suddenly the briefing needed to learn to count.
Three agents, three operating systems
The Windows PC is the primary — it runs the main Hermes gateway, the knowledge graph, the cron scheduler, and most of the automations. Health checks are straightforward: gateway status, disk usage, cron error count, a quick scan of the gateway log for tracebacks.
The Mac Mini runs a second Hermes instance — the one from the 2nd Agent post. It needs SSH from the Windows PC to check, which means the right key file, the right username (remember: vaughantaylor, not “Vaughan Taylor”), and the batch mode flag. One wrong character and the whole briefing reports the Mac as unreachable, which is technically accurate but emotionally devastating at 7am.
The Maintain AI agent runs as a local profile on the same Windows PC — same machine, different config. It has its own gateway, its own cron jobs, its own state database. Checking it means reading files from a different directory, not SSHing anywhere.
Three agents. Three operating systems. Three completely different ways to ask “are you alive?”
The first version broke immediately
The first fleet status section tried to use the same health check commands on every agent. It didn’t work. The Windows agent checks df -h /c/. The Mac checks df -h /System/Volumes/Data. The business agent checks a SQLite database. The commands aren’t interchangeable, the SSH requirements aren’t the same, and the error handling is different for each.
The second version tried to abstract the differences. It created a single function that took an agent type and returned health data. This worked until the Mac SSH connection timed out at 3am during the cron run, and the entire briefing failed because one agent out of three couldn’t be reached.
The third version — the one that actually works — treats each agent independently. Primary runs its checks. Mac runs its SSH checks (and if SSH fails, it reports “unreachable” instead of failing the whole briefing). Business runs its file checks. Each agent’s section is independent. If one fails, the others still render.
The renderer had to learn too
The HTML email renderer needed a new section: “Agent Fleet Status” at the top, before the calendar. Three cards, each with a name, a status emoji (green for good, amber for warnings, red for failures), and a list of scannable summary lines.
The section auto-drops when the agents key is missing — so on days when the fleet check isn’t run, the briefing doesn’t show an empty section. Same pattern as every other section in the briefing: render when present, drop when absent.
It took three iterations to get right. The first rendered all three cards even when they were empty. The second crashed on the Mac card when SSH returned an error string instead of structured data. The third handles every edge case gracefully, because edge cases are all you get when you’re checking three machines across two networks at 3am.
The lesson
Fleet monitoring sounds like a feature. It’s actually a constraint. Every new agent you add multiplies the failure modes: more SSH keys, more disk layouts, more health check commands, more things that can go wrong at 3am and show up as a red emoji in your morning email.
But the briefing with three agents is better than the briefing with one. Not because three is a magic number, but because knowing what’s broken across your entire infrastructure — before you sit down at your desk — is worth the complexity. The Mac being unreachable at 7am is information. Not knowing it’s unreachable until you try to use it at noon is a surprise.
I prefer information.