What It Is
Brain Ops is the local automation and agent infrastructure around my Obsidian-based second brain. It runs scheduled and always-on workflows for the morning briefing, CRM and social maintenance, Atlanta events, weekly reflection, vault search indexing, job-search sweeps, voice ingestion, iMessage capture, and backups — 18 launchd job definitions in total, some cron-style, some live daemons.
Most of the other projects on this site are apps. This one is the thing that keeps the apps, and me, running.
The Control Problem
Delegating work to agents and daemons has a failure mode nobody warns you about: the process stays alive while the work silently stops.
For these 18 jobs, “running” is not enough. I need to see the last run, new work processed, the expected output, and whether I need to intervene.
A daemon that’s been “up” for four days but hasn’t successfully processed a file in four days looks identical to a healthy one — unless you measure the right thing.
The dashboard is built around that distinction. It groups jobs by purpose, collapses healthy detail and opens unhealthy groups, tracks both scheduled-job runs and daemon liveness, separates “alive” from “last successful processing,” shows the freshness of the outputs that matter, detects duplicate daemon instances, and surfaces system and integration health.
The Dashboard Is the Product
The automations existed before the dashboard. What changed was my ability to judge whether I should trust them.
Each job sits inside a purpose—morning briefing, relationships, Atlanta events, reflection, vault infrastructure, job search, or always-on monitoring. Healthy details stay quiet. Anything unhealthy opens itself and shows the schedule, last output, processing watermark, logs, and dependencies needed to decide what to do.
That design is also a boundary between me and the agents. They can do more work on their own because I have a place to see what happened, what did not happen, and where human attention is needed.
What the Rebuild Surfaced
The July 15 rebuild found real problems:
- A false stale status on inbox monitoring: the job was fine, the check was wrong
- A JSON parser failure silently breaking the weekly reflection
- Backup timeouts caused by copying thousands of
.gitobjects nobody needed - And the one that proves the thesis: voice ingestion was alive but hadn’t processed a file successfully in four days Liveness checks said green; the processing watermark said otherwise
Three were fixed that day. The fourth became its own investigation — which is exactly what the dashboard is for: turning silent failures into visible ones.
A Deliberate Non-Decision
The rebuild also surfaced that all 18 job definitions depend on fixed local paths. Moving them would have made the directory look cleaner while risking two days of silent breakage. I left the working paths in place and documented the choice so it can be revisited.
That same judgment applies to AI more broadly. I automate repetition, retrieval, and monitoring. I do not want the system making every decision for me. The useful line keeps moving, so the dashboard is also where I notice when I have delegated too much—or not enough.
What Remains Fragile
Open issue: voice ingestion’s underlying reliability problem is still unresolved. Speaker identification via voiceprints proved unreliable enough that I don’t trust it without spot-checks. And the deeper design question — what belongs in deterministic automation versus an agent judgment loop — gets re-answered every time a job misbehaves.