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.
Top comments (0)