How the system got built

It didn't get built in a week. It got built in three phases over about six months: breadth in the spring, consolidation and a safety layer in June and July, then depth over sprawl in August and September. The git history of the agent system starts on April 10, 2026, and the numbers below come from measuring that history, not from memory.

I'm telling it straight because the earlier version of these docs didn't. More on that first.

#A correction before the story

The old docs had an article called "OpenClaw: the first harness." It described OpenClaw as my foundation: a TypeScript and Python runtime with a research loop, a cost router and Obsidian memory. That article was built from an internal spec file that was mislabeled. The file actually described my own system as it stood in April 2026.

The truth is less tidy. OpenClaw is a real, large open-source project. Early in 2026 I installed it, wrote tutorials about it, and briefly bridged my system to it through a small connector. That bridge went dead and I removed it in June. My system is built on Claude Code and my own scaffolding. When I audited the history in September, "openclaw" showed up exactly twice in the agent system's git log, both in June, and one of them was the commit retiring the bridge.

If you read the old version, discard it. This one survives someone opening the repo.

#Before April: experiments

January through March was a lot of starting things. Chat bots, one-off apps, a Telegram bot wired to Claude, an OpenClaw install. New repos showed up at roughly 28 a month from February through July. Lots of surface, not much depth in any one place.

Most of that early work lives in other repos, so the agent system's own history starts in April. What changed in April wasn't a new tool. It was a decision about the runtime.

#The runtime decision: build on Claude Code, not beside it

I didn't want to maintain an agent runtime. Claude Code already had the loop, the tools, file access, and a permission model. So instead of writing my own, I made Claude Code the runtime and built the layer around it:

• Files as state. Standing rules live in CLAUDE.md files that every session reads at start. Anything that has to outlive a session goes to a file or a table, never to chat history. Sessions rotate; state doesn't.
• The OS as the scheduler. cron and macOS launchd fire jobs. No custom event loop.
• Integrations where Claude Code had none. Telegram, voice, memory, a CRM, the cockpit.

The trade is real. When the CLI changes behavior, my system changes with it, so today the CLI has one owner: a tested upgrade pipeline with an automatic rollback. What I got back: I don't maintain the loop, the tool dispatch or the context handling. My job narrowed to the rules, the state and the wiring. Honest read: for a personal system where the value is in the domain knowledge and the guardrails, not the loop, that was the right call, and I'd make it again.

#Phase one, April to May: breadth

• April 10. Git history starts.
• April 16. The second brain goes always-on: hourly domain heartbeats, open-loop tracking, email polling, a morning briefing. A self-healer and health checks went live the same day, because I couldn't trust what I couldn't see.
• April 29. A fleet supervisor for parallel Claude Code instances lands (one git worktree plus one tmux session per worker). Then it sits nearly unused for two months.
• May 22. Root cause first becomes a written rule: fix the process that produced the bug, not just the bug.
• May 23. I stop reviewing pull requests. Agents review code; I review the product in prod.
• May 25. The budget cap and quiet hours come out of the charter. Cost is tracked for visibility, not capped.
• May 26. The cockpit becomes one persistent web chat over every agent session, synced across devices.

Commit volume stayed flat in this phase. I was adding things, not finishing them.

#Phase two, June to July: consolidation, and the safety layer with it

Merges into the agent system went from 6 in May to 78 in June to 166 in July. That's the phase where the April work finally got used. The fleet supervisor built on April 29 got adopted at scale in June: a two-month gap between building a capability and using it. That's the most ordinary finding in the whole history, and the one most likely to apply to you.

The safety layer arrived in the same weeks, and I don't think that's a coincidence:

• June 16. The cockpit becomes Nerve Center v6 and splits from its Python backend: keep the surface, replace the spine.
• June 30. The universal send gate ships. Its CI check found five autonomous email senders that bypassed approval on its first run. Manual audits had missed all five.
• July 1. One raw restart of the session supervisor killed every live session at once. A hook that blocks raw restarts followed.
• July 3. The Telegram transport is rebuilt around a write-ahead journal, so nothing inbound can be dropped.
• July 11. A durable agent bus replaces fire-and-hope messaging.
• July 16. A token audit parks autonomous domain firing, including the X agent's loops.

My claim, which I'd defend: the enforcement layer enabled the throughput instead of taxing it. At 13 times the merge rate you can't review every action, so you need exactly one door that outbound actions pass through. The gate is what made running that fast a decision instead of a gamble.

Two other things changed in July. Formal agent definition files didn't exist before July; agents had been folders and scripts. And the count of distinct commit authors went from 1 to 6. Nobody was hired. Agents started co-authoring commits.

#Phase three, late July to September: depth over sprawl

Repository creation fell from that 28-a-month pace to 16 in August and 10 in September. Merges peaked at 332 in August. New surface went down while work per surface went up. A growth dashboard would call that a slowdown. It's the opposite.

The depth phase was mostly about measuring, then removing:

• July 24. Opus 5 shipped and became the default the same day. From August 15, the Warden (my governor for autonomous agents) adopts the newest model in a family automatically, behind a probe and a quality bench.
• July 31. One model was doing over 90% of the work volume (list-price equivalent) at top effort, for everything. The fix was a rule, not a cap: review effort scales with what the change can break.
• July 21 and August 15. The hourly LLM domain heartbeats were retired, then the rest of the heartbeat class was switched off. Most runs had been no-ops behind a change check.
• September 9. A loop of kernel panics traced to memory pressure: a large local model loaded many times a day plus browser swarms, and orphaned child processes from timed-out headless runs. Fixed with an honest memory gauge, a breaker, and a shared spawn helper that kills the whole process group.
• September 11 and 20. The morning standup, which I'd stopped reading, got killed. A liveness job kept resurrecting it daily until it was killed for real.
• September 27. The Claude CLI gets its one owner.
• October 1. A chat-speed audit found model time was 85 to 90% of the wait in the cockpit. Interactive panes dropped from top effort to high.

Honest read: the best weeks in this phase deleted more than they added.

#What I'd tell you if you're starting

1. Pick the runtime, then build around it. The application layer is where your value is.
2. Expect a gap between building and using. Mine was two months. Plan for adoption, not just shipping.
3. Build the gate before you need it. I found five ungated senders. You have some too.
4. Measure, then cut. Heartbeats, standups and digests all felt useful when built. The logs said otherwise.
5. Write the history from the repo. My own docs got the origin story wrong. The git log didn't.

Next: The CEO agent