Every AI assistant I use wakes up with amnesia. New session, blank slate. It does not remember yesterday’s decisions, my file conventions, or the mistake it made last Tuesday that cost me an hour. Most people fight this by re-explaining context at the top of every conversation, which is unpaid onboarding work you perform daily, forever.
I stopped doing that. My setup now rests on two artifacts: a single instruction file that encodes how the assistant must operate, and a second brain it can read from and write to on demand. The instruction file holds five operating rules I call the Karpathy 4+1. The second brain is an Obsidian vault that persists everything worth remembering between sessions. Together they turn a stateless tool into something closer to a colleague with a filing cabinet.
This article is the implementation, not the theory. As a fractional COO/CFO I run this system daily across finance work, operations, and software projects, and it is the same discipline I push clients toward in the practical AI stack: standardize the base layer before you chase the exciting one.
The problem: capable tools, zero continuity
Modern AI assistants are strong at reasoning and weak at remembering. Session context evaporates. Preferences drift. The assistant that formatted your report perfectly on Monday reinvents its own style on Wednesday. Worse, without standing rules it defaults to eager behavior: over-building simple asks, refactoring code you did not ask it to touch, and burning tokens re-reading files it saw ten minutes ago.
Both failures have the same fix: externalize what the assistant cannot retain. Rules go in a file it loads automatically. Memory goes in a vault it loads deliberately. The distinction matters, and most setups I see collapse the two into one bloated prompt that gets ignored.
The rules: Karpathy 4+1
The first four rules are adapted from advice Andrej Karpathy has given about working with AI coding agents. The fifth is mine, added after watching token bills climb. They live at the top of a master instruction file that every project inherits, and they govern every session regardless of whether the output is code, a memo, or a spreadsheet.
Here is the block exactly as I run it. Copy it and paste it into your own CLAUDE.md (or any assistant’s instruction file) as is.
## Operating Rules: Karpathy 4+1
These govern every session, whether the output is code, a config,
a memo, or a script that processes data in the background.
1. **Think First.** Don't assume. Don't hide confusion. Surface
tradeoffs before acting. State assumptions explicitly, present
multiple interpretations rather than picking silently, and ask
clarifying questions BEFORE implementation when the ask is
ambiguous.
2. **Simplicity First.** Minimum artifact that solves the problem.
Nothing speculative: no unrequested features, extra abstractions,
or error handling for impossible scenarios. Test: would a senior
engineer find it overcomplicated?
3. **Surgical Changes.** Touch only what you must. Clean up only
your own mess. When editing existing code, configs, or docs,
don't reformat unrelated sections, refactor working logic, or
"improve" things that weren't asked about.
4. **Goal-Driven Execution.** Define success criteria up front.
Loop until verified. Turn vague asks into measurable outcomes.
State a brief plan with verification checkpoints before
multi-step work, and write that plan to the project's plans/
folder.
5. **Token Discipline.** Do the least work that answers the
question. Read only the files needed; avoid re-reading what's
already in context. Prefer search over full reads when scanning.
Batch independent tool calls in parallel. Write code once, run
it once; don't iterate speculatively. If a task needs multiple
passes, say so and confirm before burning through them.The test I apply to rule 2 is blunt: would a senior engineer call the output overcomplicated? If yes, it fails, no matter how impressive it looks. Rule 3 exists because the most expensive AI failure mode is not a wrong answer; it is a correct answer wrapped in a hundred lines of unrequested churn that you now have to review.
Rule 4 has a physical home. Every project keeps a plans folder, and any multi-step piece of work starts with a dated plan file in it. This sounds bureaucratic until you realize it gives the assistant, and you, a durable record of what was decided and why. The plan outlives the session that produced it.
The memory: a vault the assistant reads and writes
Rules tell the assistant how to behave. The second brain tells it what is true. Mine is an Obsidian vault, plain Markdown files, no proprietary format, that holds people, glossary terms, active projects, session history, and a file I consider the highest-leverage page in the whole system: prevention rules, a running list of mistakes the assistant must not repeat.
The vault has a defined load order, and the assistant follows it like a checklist when triggered.
| Step | File | Purpose |
|---|---|---|
| 1 | Brain orientation file | Entry point and manifest for everything below |
| 2 | Content catalog | Full index; the assistant picks the 2 to 5 pages relevant to the task |
| 3 | Active tasks | What is currently in flight |
| 4 | Vault conventions | Operating rules for the vault itself |
| 5 | Prevention rules | Documented mistakes not to repeat |
Two design choices do most of the work here. First, loading is deliberate, not automatic. The handshake fires on trigger phrases like “check the vault” or “what’s on my plate?” rather than dumping the whole vault into every session. Memory you load indiscriminately is just noise with a storage cost; rule 5 applies to the second brain too.
Second, the loop closes. Sessions end with a write-back: the daily log gets updated, project pages absorb what changed, and anything that went wrong becomes a prevention rule. The house rule is absolute: no session ends without write-back, because a second brain that is only read from is a snapshot that rots. The write-back is what makes it compound. Every mistake documented today is a mistake the assistant sidesteps in every future session.
One file to rule them all
The piece that makes this scale is boring: file hierarchy. One master instruction file sits at the root of my code workspace and every project inherits it. Project-level files add only project specifics. And because I run four different AI CLIs, the other three import the same master file, so Claude, Codex, Gemini, and Kilocode all operate under identical rules from a single source of truth.
That single-source constraint is the same one I apply to human organizations. A company where every department writes its own playbook has no playbook; I made that argument for businesses in why your company needs an operating system, and the logic transfers to AI tooling without modification. When the rules live in one file, updating your standards is a one-line edit that propagates everywhere. When they live in five prompts, your standards are whatever each session happens to remember.
What actually changed
The measurable difference is startup cost. A new session goes from ten minutes of re-briefing to one trigger phrase. The less measurable but larger difference is consistency: outputs follow the same conventions, plans land in the same folder, and repeated mistakes trend toward zero because they get written down instead of re-experienced.
There is also a hiring analogy I keep coming back to. An assistant with standing rules and persistent memory onboards the way a good employee does: read the handbook once, keep notes, get better every week. An assistant without them is a brilliant temp you retrain every morning. The retraining cost is invisible on any invoice, which is exactly why most people never fix it.
Build your own this week
You do not need my exact stack. You need the four components, and they take an afternoon.
Start with the rules file: write five operating rules in a plain Markdown file your assistant loads every session, and steal the 4+1 above if useful. Add the plans convention: one folder per project where every multi-step plan gets written before work starts. Then stand up the vault: any folder of Markdown files works, seeded with an orientation page, an active tasks page, and an empty prevention rules page. Finally, enforce write-back: end every meaningful session by having the assistant update the log and record any mistake as a prevention rule.
The system earns its keep within a week, and the prevention rules file alone pays for the setup the first time the assistant silently avoids an error it made last month.
FAQ
What is a second brain for an AI assistant? It is external, persistent memory the assistant can read and write: plain files holding your projects, preferences, glossary, and documented mistakes. Because the assistant’s own session memory resets, the second brain carries continuity across sessions and even across different AI tools.
Do I need Obsidian to build one? No. Any folder of Markdown files works. Obsidian is convenient because you can browse and edit the same files the assistant uses, but the load-order convention and the write-back habit matter far more than the software.
Why not just put everything in one big system prompt? Cost and signal. A prompt loaded into every session should hold only universal rules; everything situational belongs in memory the assistant pulls on demand. Dumping the whole vault into every conversation buries the rules that matter under context that does not, and you pay for the noise twice: in tokens and in degraded attention.
What are the Karpathy 4+1 rules? Four principles adapted from Andrej Karpathy’s guidance on working with AI coding agents: think first, simplicity first, surgical changes, and goal-driven execution, plus a fifth I added: token discipline. Together they are a standing defense against the default failure modes of eager AI assistants.