I didn't mean to build this

I've created something I did not mean to create.

Seven months ago, nothing was organized. I had AI doing stuff for me, sure. Today it's a machine I couldn't have fathomed back then. It reads, it writes, it schedules its own work, it fixes itself when it breaks, and most of what it does happens completely on its own, a lot of it literally while I'm asleep.

Marc Andreessen was on Joe Rogan a while back talking about a term going around Silicon Valley: the AI vampire. The person who realizes the opportunity cost of this moment is far too high to spend sleeping. That's me — a portrait right next to the definition. So this is the whole machine: what it actually does, what I had to kill along the way, and exactly how you can build your own.

Seven months of burning through systems

I opened Claude Code for the first time in January of this year. In the seven months since, I've burned through basically every way there is to organize an AI's brain. Basic memory stores. CLAUDE.md docs. Then whole frameworks built by smart people. Good systems, but built like a software team: a CEO, an engineer, a QA person. Built for people who live in pure code.

That's not my life. I'm consulting, I'm doing real estate, I'm creating websites, I'm chasing business ideas. I didn't need a system that excelled at code. I needed a system that understood particulars: instructions, details, the context of what I do every day.

Then I watched a video where Wes Roth was talking about an idea from Andrej Karpathy: your notes, when you're working with agentic systems, are not for you. They're for the agent. Everything should live in plain text files on your local computer, with the AI acting as a librarian. It files everything, it links everything, and it keeps everything current.

That clicked. And because this machine keeps receipts of absolutely everything, I can show you what happened next: the migration history has every entry dated July 14th. I tore out the old system and replaced it in a day.

If you're starting from scratch, the core of it is simple: three folders and a rules file. Mine didn't start simple, because I dragged seven months of accumulated brain into it. But here's what you get: everything is interconnected. Every action understands everything else going on in its world. People love to talk about hallucinations. I don't have hallucinations anymore. I have semantic — or technical — problems, sometimes. And I have to maintain it. What I absolutely do not have is agents that don't know what they're doing.

Today the vault is over thirteen hundred pages, and the interesting part is what runs on top of it. Right now there are about 34 scheduled tasks on my Mac, and from 9am to 8pm every day they run completely on their own. One writes and publishes articles to one of my websites twice a week: it writes, it publishes, then it goes and tells the search engines what it did, autonomously. One runs part of my video pipeline: it drafts an entire show and then stops for me to review it, because that workflow needs a hard review gate before anything goes out into the world. One tracks every business relationship I have and checks every hour whether anybody needs a follow-up. My favorite runs at 8pm every night: one job goes back and reads what every other job did that day and drops a report in my inbox. Now I've got the machine reviewing the machine.

The graveyard

Before you think I'm just sitting here telling you how amazing my system is: a lot of what I've built in the last seven months, maybe most of it, is now dead. I killed it. My directory keeps a record of every automation that's ever lived in my system, about sixty at last count, including the dead ones.

Grave one: the orchestrator. If you've spent more than ten minutes on X lately you've seen these: downloadable autonomous agents, supposedly self-improving, dozens of built-in tools, talks to you over Telegram or Slack, and you're supposed to treat it like a little employee. The pitch is strong. Install one brain to run everything else. I did it. I ran one as the operator of my entire system. It routed jobs, managed workers, sent me updates, and it was genuinely impressive. It was also busywork. Every job that used to just run now had the orchestrator bolted onto it, and when the orchestrator broke, everything around it broke too. The embarrassing part is that I killed it once in the spring, and then two months ago, after my own system was already working, I talked myself into trying it again. Within 24 hours I had reversed the decision, deleted everything, and this time I wrote it into my doctrine so I can't talk myself into it a third time. I literally keep a checksummed archive of my own dead orchestrator. The lesson: you don't need a boss agent. Not one you build, not one you install, not the next one on GitHub. You are the orchestrator. Simple, direct jobs; the schedule runs the tasks.

Grave two: the outreach autopilot. I automated follow-up emails. The machine could send personalized emails all day long, completely on its own. You know what happened? Nothing. Zero replies. Because automation is an amplifier: automate something that works and you get more of what works. Automate something unproven and you get silence at scale, faster, while paying for the privilege. Killed it July 27th, and the system card I keep for it is honest to the point of being brutal: no replies, a pile of burned tokens, retired on owner decision. Prove it by hand before you build the automation.

Grave three: the frameworks. The stacks, the skill packets, the personas. None of it is necessarily bad. None of it was built for my kind of work, and when I ripped it all out on July 14th, I learned it was something bigger than wrong fit. Every session had to start by reading a big set of contradicting instructions and extra steps, because the frameworks demanded it. The models are already smart. The scaffolding is really for you. Your agents need knowledge and rules, and that's it.

The pattern across all three graves is complexity. It really feels like you're doing something when you're building it. That's the trap a lot of people fall into.

The way out of the trap is a kill test, and mine has three questions. Did I prove this by hand before I automated it? When it breaks, does anything else break with it? And is it earning the attention it costs me? Anything that fails gets retired, the retirement gets dated and written down with the reason, and the archive stays. Writing the kill down matters more than it sounds: the second time I flirted with the orchestrator, the only thing that stopped round three was that round two was in my doctrine with a date on it.

The four rules that survived

Everything left standing came from something breaking. Not from a video, not from somebody else's framework.

• Everything lives in plain files that I own. Not in some app, not in an AI's chat memory. An AI's memory of a conversation isn't reliable and it isn't portable. The files are the truth and the agents read and write to them. That's the whole relationship.
• No job is done because an AI says it's done. An agent will tell you everything went great. Something separate has to go look at the live website, or the calendar, or whatever the session was working on. That's most of why my system is as receipt-heavy as it is.
• One writer per job. Exactly one process is allowed to write to a given website. Exactly one owns follow-ups. When something goes wrong there's one place to look, and when something publishes I know exactly who did it.
• I approve anything expensive, public, or aimed at a real person. The machine can draft it, stage it, get it completely ready, and then it stops until I say go.

Notice that none of these rules say anything about which model to use. Everybody wants to argue about models. I've swapped models numerous times since January and my opinion changes every day. With this system it doesn't matter. I can change or keep anything, because it's mine.

What a receipt actually looks like

"Receipt-heavy" is abstract until you see one, so here's what I mean. Every job in my system ends by writing down what it did: what ran, what it touched, what it verified on the live surface, and what broke. The 8pm report is just a job that reads all of those and tells me the story of the day: which articles published and were confirmed live, which follow-ups went out, what failed and what caught it. When I said the machine was working while I set up the lights to film this video, that's not a vibe, it's a log I can open.

The receipts are also what makes the graveyard honest. The dead outreach autopilot has a system card that says, in effect: sent personalized emails on schedule, got zero replies, burned a pile of tokens, retired on owner decision, dated. When I tell you it didn't work, I'm reading, not remembering. Your system should be able to embarrass you like that. If it can't, you'll remember your automations as better than they were and rebuild the same corpse with a new name.

Start with an hour, not seven months

My advice is to not start where I am. Start where I started. The first version takes maybe an hour: install Obsidian, get Claude Code, and make three folders.

Then, together with whatever agent you're using, write the rules file. Mine has grown, but the first version of yours only needs a handful of lines, and every one of them maps to something from the graveyard:

• You are the librarian of this vault. New things land in the inbox; file them into the wiki, link them to what they touch, and keep pages current.
• These files are the truth. If it matters and it isn't written down here, write it down.
• No job is done because you say it's done. Check the live thing, then record what you checked.
• One writer per job. If a job already owns something, don't create a second way to change it.
• Draft anything. Send nothing. Anything public, expensive, or aimed at a real person waits for my go.

That's genuinely the whole starting kit. Feed it the things you care about: articles, meeting notes, client stuff, ideas. Start asking it questions. Use it by hand for a week or two. At some point you'll realize you've asked it to do the same thing three or four times, and that's the indication of where your first automation goes: one scheduled job that writes down what it did. Not an orchestrator. Not a framework. A job with a receipt.

I went back and looked. My first job, back in April, tracked my own Claude usage and posted it into Slack every night. Completely unnecessary. It was also the right first job, because the first morning you read a receipt from work that happened while you slept, you'll understand how I ended up seven months deep in this.

The honest math

I do spend real time maintaining this machine. But while I'm doing that, the machine is running my business: the articles publish, the follow-ups go out, and the report lands in my inbox at 8:30. The honest math is that I traded doing the chores for maintaining the thing that does the chores, and the trade gets better every month, because the models keep getting better and my rules don't have to change.

That, all together, is what I couldn't have fathomed in January. It's just me, a reasonably high-performing Mac, and a big old folder of text files.

If you're a business owner who wants something like this without the seven months of headache, that's exactly what I do now. And I'm going to keep documenting this machine: what breaks, what gets built, and what dies next.