Forem: Hunter Kampf

The 15 Patterns That Make an AI Productivity System Actually Work

Hunter Kampf — Mon, 02 Mar 2026 19:25:57 +0000

Most people who try to build a personal AI system make it too complicated too fast.

They add databases. They set up vector stores and orchestration frameworks and synchronization pipelines. They spend three weekends on infrastructure and never quite get to the part where the thing is useful. I know because I did the same thing with my first approach: four databases, two API layers, a graph store, a vector index. Impressive to demo and annoying to use.

The HQ system, the AI productivity setup I described in the last post, took a different path. (If you're landing here directly: HQ is a personal productivity system built on markdown files, Claude Code, and a git repo. No apps, no databases, no infrastructure. The previous post covers why.) After ten weeks of daily production use, I can tell you exactly what made it work. Fifteen patterns. Most of them are the opposite of what I expected.

1. Markdown as the Database

Everything in the system lives in markdown files in a git repo. Projects, tasks, contacts, meeting notes, plans, everything. No database. No vector store. No app.

I know how that sounds. But here's what markdown files actually give you: human readability, version control, instant full-text search, and native AI comprehension. Claude reads a markdown file the same way you do. No serialization, no embedding pipeline, no retrieval layer. You hand it the file and it understands it.

What this replaced in the original overbuilt architecture: PostgreSQL for relational data, Qdrant for vector search, Neo4j for graph relationships, and ClickHouse for analytics. Four databases down to zero. Not because those tools are bad. They're excellent at what they do. But the problem didn't require them. For knowledge management, planning, and AI context? Markdown wins.

There's also something harder to quantify: you can always see exactly what's in there. Open the file, read it, edit it directly. No abstraction layer between you and your data. When something goes wrong, you find it and fix it. You're not debugging a black box. For a personal system or a small team, the simplicity and visibility are the feature.

The one honest caveat: this doesn't work for high-frequency transactional data or concurrent writes from multiple users.

2. Hierarchical Context Loading

Every folder in the system has a CLAUDE.md file. A plain text file that tells the AI what the folder contains, what's important right now, and how to work with it. The root file gives the big picture. Folder-level files give domain-specific context. The AI loads them progressively as it navigates deeper.

The practical effect: the AI never loads everything at once. It reads the root file to understand the system, then dives into a project folder and reads that file to understand the project. Right context at the right depth.

The deeper point: a CLAUDE.md file is agent programming without writing a single line of code. The instructions you put in that file configure how the AI behaves in that context: how to interpret tasks, what tone to use, what decisions have already been made, what matters this week. I've rewritten the root CLAUDE.md a half-dozen times. Each rewrite made the system noticeably smarter.

3. Skills as Loadable Knowledge

How to access email, how to process meeting notes, how to log contacts, how to plan travel. That specialized operational knowledge lives in skill files that agents load on demand. The main context stays lean. Skills load only when they're needed.

The system currently has fourteen skills: calendar access, email access, email writing style, contact logging, meeting processing, document storage, goal context, task triage, migration rules, travel planning, and four blog-specific skills covering voice, structure, SEO, and editing.

The design principle that matters: a skill file should contain everything an agent needs to perform an operation without asking for clarification. If Claude has to ask "how do I access your email?" the skill file is incomplete. Writing good skill files is harder than it sounds. The first draft of the email-access skill was missing three things I assumed were obvious and weren't.

4. Specialized Sub-Agents

Instead of one monolithic agent that does everything, the system spawns purpose-built sub-agents for specific tasks. Each agent has its own instructions, its own model assignment, and its own tool access.

The email scanner uses a fast, cheap model. It's reading and summarizing. No heavy reasoning required. The meeting processor uses a more capable model. It needs to synthesize complex conversations and route action items accurately across multiple project files. Right model for the right job.

The current roster: email scanner, email drafter, contact logger, meeting processor, project scanner, plan syncer, blog writer, gaming market researcher, tech researcher. Nine specialists instead of one generalist doing everything mediocrely.

5. Planning Files as a State Machine

Three cascading files form a state machine that manages where things are and how they move: monthly, weekly, daily.

Monthly is the radar: what's on the horizon, what needs to happen this month, what's in the backlog. Weekly is the commitment: what I'm actually doing this week, pulled from monthly and from project files. Daily is execution: what's happening right now, with a rapid log running throughout the day.

Tasks move in one direction. Monthly → weekly → daily → done → archived. Items that don't get done migrate forward with a counter. Three migrations and a task gets flagged. Do it, delegate it, schedule it, or drop it. No more zombie tasks sitting in the system indefinitely.

The cascade doesn't start at monthly. Above the planning files sits a goals and values layer: six core values that define what I'm building toward, and quarterly goals that define what matters right now. The monthly plan is derived from those goals. Each week has a theme that connects back to monthly priorities. Each day has a single most-important thing that connects to the weekly theme. The planning files are just how you execute what the goals layer has already decided.

6. Rapid Logging

Everything that happens during the day goes into the daily file as it happens.

The system uses symbols adapted from Bullet Journal: a checkbox for tasks, an X when it's done, a right arrow when something migrates, "note:" for observations. The mechanic is Ryder Carroll's. What's different is what happens with the log afterward. Claude reads it every morning to build today's plan, surfaces what was done yesterday, identifies what's still open, and carries context forward automatically.

This is one of the few things that survived directly from BuJo with no modification. Carroll got rapid logging right. The part that always killed the analog version is gone: the monthly migration ritual, rewriting every open task by hand. The AI handles migration. You just log.

The rule I've settled on: if something happened, it goes in the log. A call note. A task completed. A decision made. Something that came up. Capture everything, even briefly.

7. Proactive Behaviors

Certain things happen automatically. The AI doesn't wait to be told.

After completing meaningful work: log it to the daily plan. After finishing a task: mark it done in the daily plan, the weekly plan, and the relevant project file. After drafting or discussing an email: log it in the contact and organization files. When call notes arrive: extract action items and route them to the right project files without being asked.

This is the pattern that makes the system feel like a good assistant rather than a tool. A good assistant doesn't wait to be asked if they should take notes on the meeting. They just do it. These behaviors are specified explicitly in the root CLAUDE.md: "This is proactive by default. Do not wait for explicit requests." That one sentence changed how the entire system behaves.

The upkeep happens as a byproduct of the work. That was the whole goal.

8. Single Source of Truth

Every piece of information lives in exactly one place. Nothing is duplicated.

Project tasks live in that project's file. Non-project tasks live in the monthly plan. Contact information lives in people files. Meeting notes live in the relevant project folder. The weekly plan references tasks from their home locations. It doesn't copy them.

This sounds simple. It's harder to maintain than it sounds, and the cost of getting it wrong is immediate: if the same task lives in three places, you'll update one and forget the others. Sync failures kill trust in the system, and once you stop trusting it, you stop using it. That's the loop that killed GTD for me in the first place.

One rule, strictly enforced: one home per piece of information. When something shows up in two places, that's a bug to fix, not a feature.

9. Two Memory Files

The system uses two distinct types of memory files for two distinct kinds of knowledge. Keeping them separate is what makes each one work.

Behavioral memory lives in a file called MEMORY.md that loads automatically at the start of every session. This is knowledge about me as a person. Things like: I'm on the road fifty percent of the time, I prefer decisions over recommendations, I lose energy on admin tasks and gain it on deals. When I correct something the AI got wrong, that goes in MEMORY.md too. The AI picks it up next session and doesn't repeat the mistake.

Factual knowledge lives in markdown files organized by project and domain. Project status, contact information, decisions and their rationale, meeting notes. Knowledge about the world I operate in, not about me.

The architecture that's settled: MEMORY.md stays short, scannable, and auto-loaded. Behavioral context at the index level. Topic-specific files hold the deeper notes. MEMORY.md points to them. When the system needs detail, it reads the relevant file. When it just needs orientation, the index is enough.

The test for which layer: if it's about me as a person, MEMORY.md. If it's about the work, a project file.

10. Slash Commands as Workflows

Complex multi-step workflows get encoded as slash commands. /daily isn't just a shortcut. It's full orchestration: read yesterday's plan, archive it, scan email for action items, check the calendar, read weekly context, check for overdue tasks, create today's plan. One command, seven steps, consistent result every time.

The same logic applies to /weekly-plan, /weekly-debrief, and the monthly review. Workflows are defined once, in plain language, and they run the same way every time. No remembering which steps to do. No skipping the ones you don't feel like doing at 7am.

This is what makes the daily review sustainable. It's not a ritual I have to consciously commit to each morning. It's a command I run. The activation energy is typing eight characters.

11. Anti-Goals and Guardrails

Goals tell you what to do. Anti-goals tell you what to stop doing. Anti-goals turn out to be more powerful for behavior change, because they create hard limits the system actively monitors rather than aspirations you have to remember to check.

The current anti-goals: no task carries forward more than three times without a forced decision. No days with five or more meetings scheduled back-to-back. No hiding behind "busy" when the real issue is avoidance. No sacrificing weekend family time for work catch-up.

When the system detects a violation, it flags it. A task hitting its third migration. A calendar day overloaded with calls. The AI calls it out. A static list of goals on a wall can't do that. The system holds me accountable in a way that doesn't depend on me remembering to check.

I'd used goal-setting frameworks for years. This is the first one where I feel the guardrails during the week, not just when I review the goals.

12. Model Selection Strategy

Different tasks need different models. Running the most capable model for everything is slow and expensive. Running the cheapest model for everything produces poor results. The answer is deliberate tiering, built into the system rather than decided at runtime.

Scanning, searching, and simple lookups use the fastest, cheapest model. No benefit to paying for reasoning you don't need. Synthesis, writing, and analysis use a mid-tier model. Complex reasoning, strategy, and architectural decisions use the most capable model.

These assignments are baked into each agent's definition. The email scanner always uses the fast model. The meeting processor always uses the capable model. Nobody decides at runtime. It just runs correctly.

13. Hook-Driven Automation

At session start, a small shell script runs automatically. It outputs the current date, today's ONE Thing, this week's theme, and the current quarterly goals. Before I've typed a word, Claude already knows what day it is and what matters right now.

This sounds like a small thing. The difference it makes is not small. Before the hook, every session started with me re-establishing context: what day is it, what are we working on, what were we doing yesterday. With the hook, we start where we left off. The session feels continuous rather than episodic.

14. Git as Operational Infrastructure

Git isn't just version control for code. In this system it's the operational backbone for everything.

Every change to every file is tracked with a timestamp and context. A task completed, a note added, a project status updated. If something important gets overwritten, git revert brings it back. If I want to know what changed today, git diff shows me. If I'm traveling and working from a different machine, push and pull handle sync. The repo is the single source of truth.

The thing that took me a while to appreciate: the commit history is a changelog of how the system evolved. Looking back at ten weeks of commits tells the story of what we tried, what we changed, and why.

15. Progressive Refinement

The system was not designed upfront and then built. It grew through use, one real limit at a time.

Week one: basic daily planning and a rapid log. Week two: weekly planning and task migration. Week three: email scanner and meeting processor. Week four: skills system, contact logging, proactive behaviors. Week five: anti-goals, model selection, project scanning. Week six: travel workflows, mobile-first patterns.

Every addition came from hitting a specific, concrete pain point with what existed. We never built something because it might be useful someday. We built it when the absence of it was specific and clear.

Worth being explicit about "we" here: this wasn't me iterating on a tool. It was collaborative development where Claude had a perspective worth listening to. More than once I proposed something that seemed logical and got pushback that turned out to be right. The refinement ran both directions.

Week nine ran a different kind of iteration: not addition, but subtraction. After two months of daily use, we went back through every command, agent, and skill file and rewrote them against a writing standard. Forty-two percent line reduction in agents. Thirty-three percent in commands. Dead code removed. The system got faster and the outputs got better. The lesson is the same principle applied in reverse: build the smallest thing that solves the problem, then, once you've lived with it, strip away everything that doesn't pull its weight.

The next absence that's specific and clear: habits. The system handles tasks, projects, plans. It doesn't yet handle the underlying identity infrastructure: the workout streaks, the morning anchors, the "never miss twice" logic when you fall off. That layer is being built now. It'll be a post on its own.

The corollary: the right amount of complexity is whatever solves the current problem. When you feel the urge to add something because it's elegant or impressive or might come in handy, don't. Wait until you feel the specific pain. Then build the smallest thing that removes it.

The Pattern Behind the Patterns

Across all fifteen, there's one thing they have in common.

Context and instructions matter more than infrastructure and code.

The HQ system doesn't work because of sophisticated technology. It works because the AI always has clear instructions, relevant context, and consistent simple workflows. The sophistication is in what you tell the AI and how you structure the information it has access to. Not in what you build.

This has a name now: context engineering. The quality of what the AI gives you comes down to the quality of what you give it. Get the context right and a simpler model performs well. Get it wrong and even the best model produces garbage. I saw this first in my own architecture work: four databases, complex orchestration, mediocre results. Then saw the opposite when we stripped it down to markdown files and good instructions. The gap was enormous.

Most people building AI systems invest heavily in infrastructure and lightly in context. The HQ system got it backwards, and it works better for it.

The configuration layer is the product. Everything else is plumbing. That's the lesson.

*NeoAgentix is a company I'm 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 is building the tools, starting with a distributable version of this system, so anyone can get a working setup without doing ten weeks of iteration themselves. If you want to follow along, please subscribe.

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

Hunter Kampf — Fri, 20 Feb 2026 19:36:44 +0000

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 best hours and doing less better, 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 in Atlanta 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.

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 I 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 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.

If you found this useful, subscribe at neoagentix.com for the next post.

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 above.

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.