I Was Using AI to Write Code. Then We Started Using It to Run My Life.

My productivity system died in October, and I didn't notice until December.

Not dramatically — no single failure, no missed deadline that blew everything up. It just quietly stopped working while I was busy, and by the time I figured it out I was already three months behind on things that mattered.

It was the fourth time, by the way. Four systems over twenty years — all good, all eventually quiet for the same reason I couldn't see. I assumed I was the problem: wrong tool, not disciplined enough, too much going on. The actual cause didn't become clear until I stumbled into the answer while building something completely unrelated.

I've run through pretty much every productivity system you've heard of.

Franklin Covey first — at the Naval Academy and into my time in the Navy, when the structure of military life made values-first planning feel natural. GTD in 2009 when I moved to DC Public Schools as Logistics Manager and suddenly had to manage my own complexity instead of executing someone else's plan. Bullet Journaling at Caesars when I was an executive casino host, where I needed something fast, handwritten, and durable enough for a twelve-hour shift on the floor. Focus Course — Shawn Blanc's system — when I moved into sales at Galaxy Gaming and the time horizon stretched to months instead of weeks.

After Galaxy Gaming, I settled into a hybrid that worked well: Focus Course principles about protecting your margin and goal setting, combined with BuJo's rapid logging and migration discipline. I moved away from GTD's heavier framework — not because David Allen was wrong, but because the overhead started outweighing what I got back. Gary Keller's The One Thing also stuck: every day, before anything else, one question — what's the single most important thing I can accomplish today?

Each system worked for a season. The frameworks were good. I still use pieces of all of them.

But every system eventually died. For years I pointed at myself as the problem. It took a while to figure out what was actually killing them.

As it turns out, it was the upkeep.

GTD works if you do the weekly review. The weekly review takes real time and real cognitive energy, and when you're traveling, firefighting, running on four hours of sleep — it's the first thing to go. Miss a few and the inbox piles up, the system stops feeling trustworthy, and once it stops feeling trustworthy you stop using it. BuJo's migration process is the same. Great idea: at month end, go through every open task, decide what's worth carrying forward, rewrite it by hand. When you've got forty tasks and a full life, doing that at midnight is a second job nobody signed up for.

The problem wasn't David Allen, Ryder Carroll, or Shawn Blanc. The problem was that every system required maintenance, and maintenance was always the first casualty of a busy week.

Something different was happening on the software side.

I was building an AI agent platform through Claude Code, Anthropic's AI coding agent that runs inside your editor instead of a chat window. The workflow was markdown-heavy: plain text files with simple formatting, a CLAUDE.md at the root of every project that Claude read automatically at session start. It held everything Claude needed to know — what we were building, what decisions had already been made, what questions were still open. No re-explaining. We just picked up where we left off.

I added slash commands — shortcuts you type that trigger multi-step workflows automatically. Reusable skill files that loaded specialized knowledge on demand without bloating every conversation. I was working inside VS Code, which turned out to be a natural environment for managing complex projects: file tree, integrated terminal, editor, all in one place. Work that felt overwhelming started feeling navigable.

Then I started noticing the parallels. The development workflow was doing all the same things a productivity system is supposed to do — capture, tracking, maintenance, guardrails — just automatically. So we started applying the same approach.

We tried Obsidian first. I get why productivity people love it — the plugin ecosystem is enormous; the backlinks and graph view are genuinely interesting. But for me it was too much: too many surfaces, too many configuration decisions before you ever started capturing anything useful. I spent more time setting it up than using it.

Markdown files in a git repo — plain text, version-controlled so every change is tracked and nothing is permanently lost — turned out to be simpler and better. One folder. CLAUDE.md at the root. A planning subfolder. A folder per major work area. The same structure we'd put in place around building the platform — the CLAUDE.md, the project folders, specs and guardrails baked into the workflow — applied now to my professional and personal life.

The process from there was genuine back-and-forth — not me designing a planning system and handing it off to be built. I'd try a new structure for a week, it wouldn't quite fit, and we'd talk through why and rebuild it differently. Claude would surface a pattern I hadn't considered. I'd push back on something that looked good on paper but wouldn't survive contact with how I actually work. The system got better because those conversations happened.

Then we went deep on what the system actually had to do — not what would be nice to have, but what it had to do or it would die like everything else. We landed on five non-negotiables.

It had to work while traveling. I'm on the road fifty percent of the time. Anything that required a fixed desk setup or a specific physical tool died on the first trip.

The AI had to absorb the maintenance. Maintenance was what killed every previous system. Whatever we built, the upkeep couldn't fall on me — the weekly reviews, the task migration, the filing and routing. If I was responsible for all of that, I'd stop doing it. Same as before.

It had to keep work and personal together. The same brain managing a deal with a casino customer is also tracking my kids' baseball schedules and 4-H commitments. Artificial silos between "work" and "personal" created gaps where things fell through. A system that forced me to manage them separately just made that worse.

It had to capture everything with zero friction. The moment capture gets inconvenient, things stop going in. Once things stop going in, you stop trusting it. Once you stop trusting it, you stop using it. I'd seen this loop before.

It had to be something I could see and touch. Not a black box, not an app that abstracts everything behind a UI you can't get behind. I needed to open a file, read it, edit it directly — see exactly what was in there. If something broke, I needed to be able to find it and fix it myself. A system you can't inspect when it goes wrong isn't a system. It's a dependency.

With those five defined, we went through every system I'd used and pulled out what had actually survived. The daily ONE Thing from Gary Keller. Rapid logging from BuJo. A Top 3 for the week. The capture-and-clarify discipline from GTD. Margin from Focus Course. Values as the filter from Franklin Covey.

What we cut was all the maintenance: elaborate weekly reviews, manual task rewriting, heavy time blocking, complex category schemes. Everything that required the system to be fed rather than the system feeding you.

Here's what changed: Claude handles the upkeep now.

The planning system runs on three levels. Monthly is the horizon — a running calendar of what's coming, open tasks across all my projects, things I've committed to. Weekly is the commitment — every Sunday or Monday, a command pulls from the monthly and from active project files, surfaces the three most important things for this week, and builds a structured plan. Daily is execution. These all act as my state machine.

Every morning I run /daily. Before I've typed a word, a small script runs in the background surfacing the date, this week's theme, and my current quarterly goals. Then the command kicks off: it reads what I accomplished yesterday, reviews what's still open, checks my calendar, scans email for anything that needs action, cross-references the week's commitments. What comes out is a structured plan — ONE Thing at the top, then a ranked list broken into must-do, should-do, and could-do. Schedule populated from the calendar. The whole thing runs in a couple of minutes and I didn't touch any of it.

Throughout the day we rapid log in the daily file. Short, symbolic entries: a checkbox for tasks, an X when it's done, an arrow when something migrates. Got off a call — a few notes about what was decided. Something new came up — captured immediately. The symbols come from BuJo. What's different is what happens with them.

When I get off a significant call, I can run the transcript through a meeting processor that pulls the action items, identifies ownership, and routes them to the right project files. Automatically. I don't file a single note manually.

At the end of the week, a debrief command reviews all the daily logs, surfaces what didn't get done, and migrates it appropriately — back to a project file, forward into next week, or onto the monthly backlog. Tasks that have been carried forward three times in a row get flagged. Forced decision: do it, delegate it, schedule it, or drop it. No more zombie tasks living in the system indefinitely.

None of this is just task management.

Every part of the system is anchored to values and goals. Not in a vague, motivational-poster way — literally anchored. My core values live in the root configuration file Claude reads at the start of every conversation. A separate goals file holds the quarterly goals — the two or three things I'm actually trying to accomplish in the next ninety days — along with the specific lead measures I've committed to tracking week by week.

When the weekly planning command runs, it doesn't just pull tasks from the backlog. It reads the quarterly goals and asks: given what we're actually trying to accomplish this quarter, what are the three most important things to get done this week? The Top 3 isn't generated from what's loudest or most recent — it's derived from what matters.

The system also has anti-goals — explicit guardrails against the patterns I know pull me off track. No task carries forward more than three times without a forced decision. No days with five or more back-to-back meetings. No hiding behind "busy" when the real issue is avoidance. When the AI detects a violation — a task hitting its third migration, a day with too many calls — it flags it.

GTD was brilliant at capturing and organizing everything. It was silent on whether any of it connected to what I actually cared about. The HQ system ties execution to direction at every level, and it does it automatically — not because I remember to cross-reference my goals every morning, but because they're built into how every planning command runs.

I'm telling the build story and not just the outcome because how we built it is actually the point.

This wasn't a project I designed and handed off to an AI to build. It was months of iterative conversation — both sides pushing, both sides pulling. I'd propose something that seemed logical on paper; Claude would flag the edge case that would break it. Claude would suggest a pattern that looked elegant in structure; I'd tell it that it wouldn't survive contact with a twelve-hour travel day or a week of back-to-back client calls. Back and forth like that, week after week.

I brought domain knowledge — years of knowing what doesn't work, real constraints from a life that moves fast and doesn't forgive fragile systems. Claude brought something harder to describe: the ability to hold the entire evolving system in mind at once, surface inconsistencies I'd stopped noticing, and iterate without frustration. No ego about being wrong. No fatigue from rebuilding something for the fourth time.

What made it feel different from every other software tool I've used: I wasn't giving commands. I wasn't dictating a spec. I was working with something that had a perspective — and that perspective was useful enough that I changed my mind based on it more than once.

Neither of us could have built this alone. That's not a figure of speech.

After six weeks of daily use, here's what we know about why it works.

The system works because the AI always has the right context at the right moment. Not everything — the right things. CLAUDE.md tells it how I work and what matters. The daily plan tells it what today looks like. Project files tell it what's happening in each area of work. Skill files load specialized knowledge when it's relevant and stay quiet when it isn't.

What it doesn't need is infrastructure. No database, no vector store, no complex orchestration layer. Plain text files tracked in git — readable by any tool, reversible on any change. The sophistication isn't in the technology. It's in the instructions and context.

This has a name now: context engineering — what you give the AI, what information in what structure at what moment, determines the quality of what you get back. It's not about the model. It's about the context. Get the context right and even a simpler model performs well. Get it wrong and even the best model produces garbage.

What we built isn't a productivity app. It's a folder structure, a set of markdown files, a handful of slash commands, and Claude as the operating system running on top of it. Everything in plain text. Everything tracked and reversible. Everything searchable. If Claude Code disappeared tomorrow, I'd still have all of it — readable, portable, mine.

I'm still iterating on it. That's the point — it's designed to evolve, not get replaced. But for the first time in a long time, nothing has died.

In the next post, I'm going to go through the actual patterns — the 15 specific design decisions that make this system work in daily use. Markdown as the database. Hierarchical context loading. Skills as loadable knowledge modules. Specialized sub-agents. Planning files as a state machine. The full picture of what's actually under the hood, and why each piece is there. If you want to know when that's up, subscribe below.

NeoAgentix is a company I am building as a side project — part methodology practice, part platform. The methodology side uses lean and continuous improvement principles to help mid-market businesses find the right AI solutions for the right problems and implement them in ways that actually stick. The platform side builds the tools to run it.