Running agents in production: five months of MyClaw
Product consultant & builder
MyClaw is my personal AI operations system: a set of agents that run briefings, memory, finance tracking, and a growing share of my development work. It started on February 22, 2026 as a config file and a napkin note. Five months later its ecosystem includes an iOS project that took on 25,523 commits in nine weeks of agent-driven development.
The commit history records something useful: what changes when agents go from tool to workforce, and what discipline that takes.
One note on honesty: the heatmap on this site’s homepage includes this work, log-scaled, so a two-hundred-commit agent day sits in fair proportion beside a five-commit hand-made one. Agent work should be presented in proportion, and labelled.
Timeline
Phase one: teach it to remember
The early commits are all memory: a native memory wiki, knowledge-graph consistency checks, standing orders that survive across sessions, and seeders that mirror personal vaults into a queryable brain. An agent with amnesia is a chatbot. An agent with structured, verified memory starts to be useful.
April 17 has the commit I quote most: "Tighten daily report prompts: cut raw data, amplify computed insight." Nine words that define the agent’s job as judgment over recitation. Most of what gets called prompt engineering is really job design.
Phase two: operate it like infrastructure
By May the language of the commits changes. Doctor checks verify runtime health. Evidence trails record what the agents actually did. Finance queries get fallback sources. The June and July commits read like a runbook: "Fail closed on embedding quota errors." "Protect live Talk turns during voice deploys." "Make evening brief coverage-aware and interpretive."
Fail-closed is the important one. When the embedding provider hits quota, the system stops, reports, and waits, in place of guessing. For an agent with write access to real systems, the expensive failure is confident action on bad information. Designing the halt is harder than designing the action, and the halt is what makes the system trustworthy.
The deploy-protection commit encodes an old truth: agents now run live sessions, and a deploy has to respect them the way a web deploy respects in-flight requests. Twenty years of infrastructure patterns apply directly. The workload is just stranger.
Phase three: the swarm
openclaw-ios compresses the story into nine weeks: 25,523 commits on one iOS codebase, agent-generated. At that volume you can see which practices survive. Commits stay tiny. Dedup keys appear in message handling — "include sender in duplicate-user-message dedup key" — because at swarm scale the same thought arrives twice. Merge discipline hardens, because parallel agents collide the same way parallel humans do, only faster.
The lesson for anyone building with agents: a swarm amplifies whatever engineering culture you already have. Small commits, health checks, idempotency, and evidence trails scale up well. Sloppiness scales up too. You choose what gets amplified before the swarm starts.
What this means for product work
The fleet articles on this site describe improvement waves rolling across five products in a day. That throughput is agent throughput, governed by the discipline above. The agents execute. The judgment about what to build, what to price, what to protect, and when to halt stays human.
This is what I bring to client work: a working, operated example of AI-assisted delivery, with five months of production lessons on where agents excel, where they need supervision, and how to design that supervision. The homepage heatmap is the visible surface of the system, updating daily.
The takeaway
Three phases: memory, operations, swarm. The durable lessons are familiar ones — small reversible steps, health checks, fail-closed design, evidence trails — applied to a workload that moves faster than any team before it. Judgment stays human by design.
My time is for hire.
Two ways to work with me: a full project build, where I design, build, and ship your product with these methods, or consulting inside your team.
Keep reading
Sprints are dead for prototyping
A working prototype is now quicker to build than the meeting to discuss it. That kills the sprint as a prototyping tool, and it changes how product decisions get made.
The MVP is the easy part now
I have shipped five MVPs since February. Building them was the quick bit. Technology stopped being a moat, users are settling into fewer apps, and audience is the asset that decides who wins.