Skip to content
Agent Tree Knowledge Hub
🎓 Find your path Subscribe

The 8 Domain Agents

Tier 3 · Everything Built 8 min read

A CEO agent that has to understand 8 life domains simultaneously would spend most of its time re-loading context. The domain agent architecture solves this by putting a persistent brain at each domain, leaving the CEO free to coordinate rather than own.

The 8 Domains

Section titled “The 8 Domains”

school

BYU coursework, MBA program, Canvas grades, professor agents, analytics suite. Heartbeat :03.

family

Calendar, family logistics, budget (SimpleFIN-backed), HydroJug/health family items, Sam-related tasks. Heartbeat :08.

growth

LinkedIn strategy, Socrates (X/Twitter autopilot), newsletter, comment engine, Leland coaching. Heartbeat :13.

ai-foundry

BYU AI Foundry org, application pipeline, student projects, Corbin/team coordination. Heartbeat :22.

siemens

Siemens work responsibilities, MBP relay for delegated work tasks. Heartbeat :27.

consulting

Slopes Mortgage, Felix’s products (Subefy), client deliverables. Heartbeat :32.

health

Garmin data, recovery emails, peptide protocol, health-expert agent, workout scheduling. Heartbeat :37. (Added 2026-04-16.)

life-ops

Home logistics, accounts, warranties, administrative tasks. Heartbeat :52. (Added 2026-04-16.)

The stagger (:03, :08, :13…) is intentional. Eight domains firing simultaneously would create a thundering-herd problem on the Mac Mini. Staggered at ~5-minute intervals, the load is even across the hour.

The Heartbeat Architecture

Section titled “The Heartbeat Architecture”

Each domain heartbeat is a cron job — 8 hourly cron entries in the crontab — that runs the domain agent’s heartbeat script. The script does three things:

  1. Reads state. Loads the domain’s state/*.yaml files, recent CHANGELOG entries, and any open loops tagged to this domain.
  2. Calls the LLM (Sonnet tier). With the domain context loaded, the agent produces a structured assessment: what’s in-flight, what’s at risk, what needs JD’s attention.
  3. Writes state/report.md. The output is a structured markdown file, not a Telegram message. This is the key design decision.

The prompt is imperative, not conversational. Domain agents don’t ask questions — they write answers. The report format was specified on 2026-04-16 when the heartbeat architecture was installed: “agents write structured state/report.md instead of asking questions.” A domain agent that outputs “Should I do X?” is not doing its job.

What report.md Contains

Section titled “What report.md Contains”

The format varies by domain but the structure is consistent:

# Health Domain Report — 2026-06-10 07:37


## Status: AMBER


### In-Flight
- Garmin schedule: 32 workouts live through Aug 3 ✓
- Peptide protocol: PEPTIDE-PROTOCOL-2026-06-09.md delivered ✓


### Needs Attention
- KB freshness: expert-kb/ has no scheduled refresh (WORKPLAN P3 / story H14)


### Open Loops (P0-P2)
- [ ] Baseline bloodwork before tesa switch (owner: jd)

The CEO reads these reports during its heartbeat cycle. When multiple domains are AMBER or RED simultaneously, the CEO synthesizes and surfaces a brief to JD — rather than eight separate Telegram messages.

Persistent Domain Rail

Section titled “Persistent Domain Rail”

The original domain agents (2026-04-16) were heartbeat-only: they ran hourly, wrote a report, and stopped. They had no memory between runs beyond what they could read from state files.

The 2026-05-31 audit called this out as a limitation. A domain agent that re-reads its entire state every hour and has no accumulated context misses things that span multiple sessions — a multi-week project status, a relationship arc, a slow-building risk. The persistent domain rail (shipped 2026-05-31) addressed this by giving each domain agent a bridge-connected session it can resume across heartbeats, not just a stateless hourly script.

Domain vs Project

Section titled “Domain vs Project”

Not everything that happens in a domain belongs to a named project. The domain agent owns two categories:

Domain todos — single actions, chores, one-offs. “Register car.” “Clear stale Skylight tasks.” “Buy milk.” These live in ~/clawd/domains/<domain>/state/tasks.yaml with project_slug: null.

Project-attached work — tasks that belong to a named project, linked via project_slug: <slug>. The project WORKPLAN holds milestones; the domain task is a specific action within one milestone.

Domain agents don’t scaffold projects for tasks. When a new multi-artifact effort starts — a real deliverable, an end-state, a project that merits tracking over weeks — the CEO or JD scaffolds a project explicitly. The domain agent tracks its progress via the project’s CHANGELOG.

The 2026-05-31 Audit

Section titled “The 2026-05-31 Audit”

The honest reckoning of domain agent quality happened on 2026-05-31: a 5-agent audit that assessed the state of each domain. Verdict: “6/8 hollow domains, 18 no-code agents, dead dashboards.” Stale data. Agents that wrote reports citing their own April context.

That audit triggered the cleanup that followed: domain agents were rebuilt to write honest reports from live data, hollow agent packages were flagged for work, and the persistent rail gave domains a session that could track change over time rather than re-deriving state from scratch every hour.

The audit wasn’t hidden. Its findings were used to build the 2026-06-08 evolution proposals that the work queue then shipped. That’s the loop working as intended: the system observed its own quality problem, surfaced it, and fixed it.

Next: The Organization Charter — the supreme governing document: commandments, hierarchy, model routing, and why a written charter matters for an AI org.