Building a Personal AI Operating System

Narrative 15 min read

In early April 2026 I had a Telegram bot connected to Claude that could answer questions. By mid-April I had an autonomous agent system managing my family calendar, school grades, consulting pipeline, health tracking, and more — all running on a Mac Mini in my apartment.

The first git commit to the agent-system repo is dated 2026-04-10. Everything in this story happened from that date forward; the “Telegram bot I’d been running” predated it, but the structured multi-domain OS started there.

This is the story of how it was built.

Day 0: The Telegram Bot That Crashed for 56 Hours

It started with a bug. My Telegram bot — the primary interface to Claude — crashed and stayed down for over two days. The root cause was embarrassingly simple: an environment variable (ANTHROPIC_API_KEY) was being exported in the daemon script, but Claude’s --channels flag requires claude.ai authentication instead. The daemon crash-looped silently.

That outage taught me the first lesson of agent infrastructure: if you can’t see it, you can’t fix it. There was no monitoring, no alerting, no watchdog. Just silence.

The fix wasn’t just removing the bad env var. It was building an entire observability layer:

A watchdog cron job that checks the bot every 15 minutes
A reusable telegram-notify.sh script for any process to send alerts
Unconditional KeepAlive in the launchd daemon config
A patched Telegram plugin that preserves reply context

Day 1-2: The Domain Model

With the bot stable, I needed to organize the chaos. I was asking Claude to help with school, family, work, consulting, and personal growth — all in the same conversation. Context was getting polluted.

The solution was life domains — each a self-contained unit with its own:

config.yaml — integrations, specialists, schedules
SOUL.md — personality and communication style
state/ — live data (grades, pipeline, habits)
memory/ — accumulated knowledge
scripts/ — automation

Eight domains emerged: Family (amber), School (blue), Siemens (teal), Consulting (purple), Growth (emerald), AI Foundry (rose), Health, and Life Ops. Each got a color, an icon, and a dedicated section in the dashboard. (Domain count as of April–May 2026; Health and Life Ops were added after the initial launch week.)

A CEO orchestrator sits above all domains, aggregating their reports into an executive summary every night.

Domain heartbeats (every 4-6 hours)
  └── Each domain: state/report.md
       └── CEO aggregate (nightly)
            └── executive-summary.md
                 └── Nerve Center dashboard

Day 2-3: MCP Servers — The Tool Layer

Domains are useless without tools. MCP (Model Context Protocol) servers give Claude structured access to external services. I already had a few (email, calendar, GitHub). Over three days, I added:

Canvas LMS — 6 tools for pulling courses, assignments, grades, announcements
Nutrition — USDA food database, calorie/macro tracking with dual JSON+markdown storage
Mem0 — fully local semantic memory using Ollama embeddings + Qdrant
Nerve Stream — fire-and-forget event streaming to the dashboard
Playwright — 28 browser automation tools via headless Chromium
Supabase — 8 tools for structured data queries and analytics
Skylight — family calendar and chore management
CoinGecko — crypto portfolio tracking

The total as of April 2026: 16 MCP servers providing approximately 100 tools (exact count varies as servers are updated). Every one registered in a single .mcp.json file.

Day 3-4: The Model Router

Running everything through Claude Opus would cost $50+/day. The solution: a model router that classifies tasks into tiers.

Tier	Models	Cost per 1M tokens
Worker	Haiku, Ollama qwen2.5:7b	$0.25-1.00 (or free)
Specialist	Sonnet, Kimi K2.5	$0.38-3.00
Executive	Opus	$15.00

The router analyzes task text for complexity signals, classifies into a tier, checks the daily budget, and auto-downgrades if spend exceeds 80% of the $15/day target. Kimi K2.5 was the breakthrough — 4.1x cheaper than Sonnet with competitive quality for coding and analytics tasks.

A unified router sits on top, directing traffic across three systems: Agent System tools, OpenClaw agents, and Claude Code sessions. It has a 50-case test suite validating routing accuracy; latency is sub-second in practice.

Day 4-5: Automation Explosion

With domains, tools, and routing in place, automation became the priority. An initial set of cron jobs ran daily (the system later grew to ~155–160 cron jobs by mid-2026; what follows describes the early April launch set):

7:00 AM — Canvas assignment sync
7:05 AM — 9-source morning briefing to Telegram
Every 15 min — Telegram watchdog + domain state sync
8 AM, 2 PM, 8 PM — 48-hour deadline alerts
Every 4 hours — Dashboard snapshot + Vercel redeploy
Every 6 hours — GitHub repo enrichment for 23 projects
Nightly — CEO executive summary aggregation
11 PM — Cost tracking summary
Sunday 8 PM — Weekly review generation

Alert agents fire on specific triggers: grade changes on Canvas, consulting deals going stale, upcoming birthdays (at 7, 3, 1, and 0 days out).

The CRM emerged naturally. Per the rules in CLAUDE.md: “whenever a person’s name comes up, check or create their entry.” Over that initial build period, contacts accumulated as markdown files with YAML frontmatter, searchable from the dashboard. (By June 2026, the CRM holds 808 entries.)

Day 5-6: The Nerve Center Dashboard

All this data needed a single pane of glass. Nerve Center v5 is a Next.js app with a cyberpunk glassmorphism design — dark backgrounds, glass panels, neon accents, domain-specific colors.

It has 14+ pages at launch (48 pages by June 2026): CEO overview, one per domain, system vitals, org chart, CRM, activity timeline, project tracker, goal dashboard, and nutrition.

The hardest problem: Vercel can’t read the Mac Mini filesystem. Solution: a prebuild script snapshots all state into JSON, API routes try live filesystem first (for dev), then fall back to snapshots (for production). A cron job rebuilds and redeploys every 4 hours.

Each domain gets a floating chat button that streams Claude responses via SSE, loaded with the domain’s personality (SOUL.md) and live state as context.

Day 6-7: OpenClaw Integration and Polish

The final push unified two parallel agent platforms. OpenClaw had its own agents for research, slides, QA, and analytics. Rather than maintaining duplicates, we built a hybrid model:

MCP for shared services (tools, data access)
OpenClaw skills for OC-native features (channels, task management)
AI-OS engines for heavy compute (research, deck building, RAG)

Six OpenClaw agents were retired and redirected to Agent System equivalents. A shared memory protocol synced knowledge chunks across systems. The skill registry catalogs skills across 4 tiers and 5 backend types; exact counts change as the system evolves — see the OpenClaw Integration page for current details.

What I’d Do Differently

Start with the watchdog. The 56-hour outage was preventable. Build monitoring before anything else.
File-based state from day one. Conversation memory dies with the session. Files survive forever.
Budget tracking from the start. I didn’t know my actual spend until day 5. By then I’d burned through more than I expected.
Fewer domains initially. Six domains was ambitious. Start with two or three, get them solid, then expand.

The Numbers

Snapshot as of mid-April 2026 (initial build). Numbers in parentheses reflect the system as of June 2026.

Metric	April 2026	June 2026
Agent packages	~28	~31
MCP servers	16	16
Total tools	~100	~100
Cron jobs	~14	~160
CRM contacts	~130	808
Life domains	6	8
Dashboard pages	14+	48
Daily budget target	$15	tracked for visibility
Build start	2026-04-10 (first git commit)	—

The full architecture details for every subsystem are in the Architecture References section. If you want to build something similar, start with the Domain Architecture and Model Router docs.