The Case for Burning It Down

I spent three months building Pete. An AI chief-of-staff running on a headless Mac Mini in my garage. Nine cron jobs. Two Telegram bots. A memory system with three layers. Cross-session semantic search. A 19,000-character instruction file telling him how to behave.

Yesterday I backed it all up and prepared to delete the user account.

Not because it failed. Because I finally understood what I actually needed — and it wasn't most of what I'd built.

How Cruft Accumulates

Nobody sets out to build something bloated. You start lean. One bot, one chat, one model. Then you add a plugin because someone on Discord said it was essential. You add a cron job because the morning briefing idea sounds great. You add a memory layer because context across sessions seems important. You add another memory layer because the first one wasn't quite right.

Each addition makes sense in isolation. The problem is that nobody removes anything. Every layer stays. Every backup file stays. Every config workaround from a bug three versions ago stays. You end up with 30 backup copies of your config file and a plugin that takes up 629MB of disk space returning zero useful results.

I asked Pete to dump everything he knew about my brother's business — every conversation, every lead, every decision from three months of operation. When his semantic search layers came back empty, I braced for the worst. But what he actually produced surprised me.

Pete knew the website had 48 live routes across 19 images and 15 pages. He knew which sprints were complete and which were blocked waiting on my brother for deliverables. He knew the service areas, the tech stack, the repo location, the Google Drive folder ID for meeting recordings, and the Gmail addresses to monitor. He had my brother's Telegram ID and had correctly internalized the rule to never DM him directly — group chat only.

That's not nothing. That's a solid operational snapshot. Pete knew the map. He just didn't know the territory.

What was missing: any actual conversation content. Any customer names or leads. Any of the weekly industry intelligence from three months of scheduled trend scans. The compounding knowledge — the stuff that should have been growing richer every week — simply wasn't there. To be fair, we never actually connected Gmail or put Pete to work on lead capture. The business was still ramping up. So the absence of customer data isn't Pete's fault. But the memory systems that were supposed to be capturing everything else? Those were running, consuming resources, and storing nothing retrievable.

Or so I thought.

After Pete produced his context dump, I went to the terminal and queried QMD — the local semantic search engine built by Tobi Lütke (yes, the Shopify founder) — directly from the command line. What came back stopped me cold: 2,070 indexed files. 5,396 embedded vectors. Brand voice documents, email templates, business configuration files, full session transcripts including actual conversations with my brother, cron job histories, session bridges, project specs. Three months of accumulated knowledge, all searchable, all there.

The data wasn't missing. The agent just couldn't reach it.

When Pete searched through his tools, QMD returned nothing. When I searched the same index from the terminal, it returned everything. The integration layer between the agent and the search tool was broken — and nobody noticed for months because the system looked healthy from Telegram. Infrastructure you can't access through your workflow might as well not exist. QMD is brilliant software. It was doing its job perfectly. The failure was in the plumbing between the agent and the tool, not in the tool itself.

I exported the full QMD index to markdown: 2,962 files, 22MB of actual knowledge. That's what three months of operation actually produced — session transcripts, daily logs, project specs, cron outputs, conversation history. Not nothing. Not 8.6GB either. Twenty-two megabytes of signal buried under gigabytes of infrastructure.

As for lossless-claw — that 629MB plugin? Turns out 628MB of it was npm dependencies. The actual code is under a megabyte. It does in-session context compression, not cross-session storage. It was never designed to be a searchable knowledge base. I'd installed it because someone recommended it, without understanding what it actually did.

The system was busy. It was productive in spots. But the ratio of infrastructure to output was way off. A 1.6GB workspace containing 22MB of real markdown. 8.6GB of total state to support 6KB of agent-accessible context — even though the real data was right there, one layer beneath. That's not a memory system. That's a filing cabinet with everything in it and a lock on the drawer.

The Sunk Cost Trap

The hardest part of starting over isn't the technical work. It's the feeling that you're throwing away effort. Three months of config tweaks, incident investigations, upgrade rituals, plugin installations. I wrote an 8-page incident report about a rogue gateway that ran undetected for 17 days. I documented every hard-won lesson in an instruction file that approached 20,000 characters.

But here's what I realized: the lessons survive the wipe. The cruft doesn't.

I know that Telegram groups need to be configured in two places. I know that thinking level must stay at medium or the model narrates actions without executing them. I know never to run OpenClaw from the admin terminal. I know to check process ownership after a reboot. None of that knowledge lives in a config file. It lives in my head, in my blog posts, in conversations like this one.

What I Should Have Done Differently

I jumped in too fast. OpenClaw was expanding daily — new features, new plugins, new guides. The community was building skills and sharing configs. I added things because they existed, not because I needed them. I installed a memory plugin before I had anything worth remembering. I set up nine cron jobs before I knew which information actually mattered to my day.

The fix isn't "be more careful adding things." The fix is a principle: add nothing until you feel its absence.

On my fresh install, I'm starting with exactly one thing: the Telegram connection. Pete answers when I talk to him. That's it. No crons. No plugins. No memory system. I'll use it like that for a few days. When I miss the morning briefing, I'll add one cron. When I need Pete to remember something across sessions, I'll add GBrain. When I need Gmail monitoring for business leads, I'll wire that up.

Every addition will be a response to a real need, not a theoretical one.

The Maturity Curve

There's a pattern I've seen in every technical system I've built, and I think it applies to AI agent setups especially well.

Phase 1: Enthusiasm. Everything is possible. You install every plugin, enable every feature, add every integration. The system grows fast. It feels productive because it's busy.

Phase 2: Complexity. Things start breaking in ways that aren't obvious. A gateway runs under the wrong user for 17 days. A plugin takes up 629MB and may be storing data — but you can't query it when you need to. Config files accumulate backup copies. You spend more time maintaining the system than using it.

Phase 3: Clarity. You finally understand what you actually need. It's dramatically less than what you built. The morning briefing matters. The industry trends matter. The Gmail integration would matter — but you never connected it because you were too busy configuring memory plugins. Some things your agent knew well. Others it should have known and didn't. The real question isn't "did it work?" but "was the complexity justified by the output?"

Phase 4: The rebuild. You start over, but this time you build only what Phase 3 told you matters. The system is smaller, faster, and actually useful. You add things one at a time, only when you feel the gap.

Most people get stuck between Phase 2 and Phase 3. They keep patching. Keep adding. Keep hoping the next plugin or the next upgrade will fix the feeling that something isn't right. The courage is in admitting that the architecture itself is the problem — not any individual piece of it.

Stick With One Thing

There's a related temptation that hits at exactly this moment: switching platforms entirely. I felt it. Hermes Agent looks great. It has a self-improving learning loop. The community is excited. It would be easy to convince myself that the problem was OpenClaw and the solution is Hermes.

But the problem wasn't the platform. The problem was me — adding things I didn't need, not verifying they worked, not removing what wasn't serving me. Switching platforms would just restart the same cycle with different config files.

The deeper lesson: stick with one thing long enough to truly understand it. Understand what it can and can't do. Understand what you actually need from it. Then make it do exactly that, and nothing more. The grass is always greener on the other repo.

I'm keeping OpenClaw. I know its quirks. I know its failure modes. I know that ps aux | grep openclaw-gateway is the first command to run when something breaks. That knowledge has real value. Starting over on a new platform means re-learning every quirk from scratch.

There's a time to switch. But it's after you've truly exhausted what you have — not after you've barely scratched the surface while burying it under plugins.

Thin Harness, Fat Skills

The final push came from Garry Tan. The Y Combinator CEO has been building in public with OpenClaw, shipping gstack (his opinionated Claude Code setup) and GBrain (a structured knowledge brain for AI agents) — both open source, both MIT-licensed, both reflecting an architecture philosophy he calls "thin harness, fat skills."

The idea is simple. The harness — the thing that runs your agent — should be thin. Minimal. A conductor, not a warehouse. The intelligence lives in skill files (reusable markdown procedures) and in your knowledge base, not in a bloated config with 30 backup copies and 629MB of plugin state.

That hit me hard. Because that's exactly what I'd built — a thick harness. My agent's identity, memory, knowledge, and operational logic were all entangled with the OpenClaw config. Three memory layers woven into the gateway. Nineteen thousand characters of instructions injected into every session. Plugins bolted on, never removed. The harness owned everything, and when I asked it to give that knowledge back, it couldn't.

GBrain takes a different approach. Your knowledge lives in structured markdown files in a git repo — compiled truth on top, append-only timeline on the bottom. The agent reads before it responds and writes after every conversation. The brain gets smarter over time because the knowledge compounds in files you own, not in a plugin's opaque database. It runs locally with PGLite — no server, no subscription — and the hybrid search (vector + keyword) actually finds things when you ask.

This is what my v2 will be built around. Not more layers. Not more plugins. A thin harness with a structured brain that I can read, edit, and move between platforms without losing anything.

The timing of all this is both addictive and draining. People like Garry and Peter Steinberger (who built OpenClaw essentially solo with AI agents) are shipping in public every single day — new tools, new philosophies, new repos. You watch it happen in real time on X and GitHub. It's inspirational and overwhelming in equal measure. The temptation is to chase every new release, install every new tool, jump on every thread. That's how I got here — 8.6GB of enthusiasm and 75MB of actual value.

The lesson from all of them, if you read carefully, is the same: less infrastructure, more output. Build only what serves you. Validate that it works. Delete what doesn't. The people shipping the most are the ones with the leanest setups, not the most elaborate ones.

The Plan

Day 1: Fresh OpenClaw, Telegram only. Verify it works. Stop.

Day 2-3: Wire Gmail for my brother's business. This is the first thing that helps someone other than me.

Week 2: Add GBrain for structured knowledge — but only after I've used the bare system long enough to know what I want to remember.

After that: add crons only when I feel the gap. If I don't miss the intel digest after two weeks, it was never important.

The archive is on a separate machine. Everything is recoverable. And honestly, Pete earned more credit than I initially gave him — he had a solid operational picture of every project, every person, every piece of infrastructure. The issue wasn't that he learned nothing. It was that 8.6GB of system state was the wrong vehicle for 75MB of real knowledge. The signal was there. It was just buried under an avalanche of plugins, backups, and config artifacts that had no business existing.

What Open Source Actually Taught Me

Here's the thing nobody tells you about running AI agents on open-source infrastructure: the value isn't just in the system you build. It's in what building it teaches you about how AI actually works.

Three months of running OpenClaw with Codex, wiring Telegram bots, debugging gateway processes, watching crons fire and fail — that's not wasted time even if I'm deleting the installation. That's an education in how models think, how tool integrations break, how memory systems compound (or don't), and where the real friction lives between what an AI can do and what it actually does in production.

You can't get that from a subscription product. You can't get it from a chat window alone. You get it by running the thing yourself, on your own hardware, watching it succeed and fail in ways no tutorial prepares you for.

Look at what the open-source builders are actually shipping. Garry Tan built GBrain and gstack because he needed them — not because they looked good in a demo. Tobi Lütke built QMD because semantic search over local files is a real problem he wanted solved. Peter Steinberger built OpenClaw largely with AI agents themselves. These aren't hobby projects. They're production tools built by people who run them daily and open-sourced them so others can too. The fully open-source agent stack is real, it's powerful, and it's getting better every week.

But here's what I've also learned: open source and frontier models aren't competing. They're collaborating. The open-source tools give you the infrastructure — the agent runtime, the knowledge layer, the semantic search, the automation. A frontier model in a conversation gives you the strategic thinking — the "should I even be doing this?" analysis, the architecture review, the pushback when you're about to make a bad call. Every major decision in this post was worked through in a long session on Claude. Every piece of infrastructure that executes those decisions runs on open-source tools on a Mac Mini in my garage.

The agent runs the business. The conversation shapes the strategy. Neither replaces the other. The people building the most impressive AI setups right now aren't choosing between open source and proprietary — they're using both, in their respective strengths, and getting more out of each because of the other.

That's the real lesson from three months of building Pete: the experimentation is the education. The plugins that didn't work taught me what I actually need. The memory layers that stored nothing taught me where knowledge should live. The crons that fired into the void taught me which information matters. None of that learning happens if you don't build it, break it, and have the honesty to start over when you see what it taught you.

Starting over isn't admitting failure. It's the natural consequence of learning. You built something, you understood what it taught you, and now you're building the thing you actually need.

The first build is the tuition. The second build is the degree.