The tool will die. Save the brain.
The conversation about AI context engineering is forming fast. The piece most people miss: your context should live somewhere that doesn't depend on which tool is reading it. Build the brain. The tools will die.
Andrej Karpathy has been pushing a term I've come to like: context engineering. It's the idea that what separates a useful AI workflow from a useless one isn't a better prompt or a smarter model. It's the material those models are reading before they answer.
Last week Casey Simone published Pt 1 of a series called "How to Claude Code Agents Like an Engineer". It's a generous, careful piece for non-technical people getting started, and it does something I wish more writing in this space did: it takes the philosophy seriously before the tooling. If you're earlier in this curve, read it first.
This post is what sits next to hers. For anyone past the early stage, frustrated with chat windows that forget you, and looking for what to build on top.
How I got here
About a year ago I built a site for a small business client. It was fine. Functional, clean, on brand. And generic. Her actual context (the rhythm of her operation, her staff, the way she talked about her work) wasn't in the build. The brief was in my head. The site wasn't what it could have been with more context.
So I started keeping context. First in chat windows, pasted in every session, repeated every time. Then in Gems, then in Projects, each one a walled garden with its own version of the truth. I'd write a handover at the end of a long session, save it as a file, reuse it next time. Each new handover replaced the old one. No history.
That's where the vault came in.
The principle
Your context should live in something that doesn't depend on which tool is reading it. Markdown files. Plain text. A directory you own and your tools borrow.
The agents read AND write to it. That part matters. Most people configure their AI tools to read context. Fewer let them write back. The automated bi-directional access is what turns a folder of static notes into a brain that compounds.
I use Obsidian for this. It's what fit me. It's not the only path. Whatever comes after Obsidian will work too, as long as it preserves the principle: your context belongs to you, the tools are visitors.
What feeds the vault
The vault is the easy part. Anyone can install Obsidian in five minutes. The harder part, and the part that decides whether this works for you in six months, is the discipline that feeds it.
Manual stuffing doesn't scale. If your plan is to remember to save every useful insight by hand, you'll do it for two weeks and then stop. The thing that has to scale is process.
Handover protocols at the end of every major session. Automated triggers that drop a structured summary into the right folder. Audits that check whether the new entry contradicts something older. I have a system called Aeryn (for the nerds, named after Aeryn Sun, the name matches the personality) that audits PRDs and code without me invoking her. Claude Code triggers her at key phases, she audits, hands back, CC keeps going. A handful of in-progress builds all write to the same vault, enriching each other instead of dying with their respective chat windows or terminal sessions.
The point isn't the specific tools, I use a variety. The point is that the feed runs without you thinking about it, and what gets fed is structured enough to be useful a year from now.
Client work has its own rule
For my own work, my vault, my knowledge.
For client work, their vault, their knowledge. Not mine.
I don't absorb client context into a personal library. The context layer that gets built during an engagement stays with the client when the engagement ends. They keep what was built and the brain that supported the build. When they hire the next person, that person inherits the vault. The work compounds for the client, not for me.
This is the principle that pairs with build-to-be-replaced. The engagement ends on purpose. The knowledge stays.
Tools change. Discipline doesn't.
Claude Code didn't exist 18 months ago. Cursor wasn't ascendant 12 months ago. Codex CLI just appeared a few weeks back. Obsidian itself wasn't where it is now either.
The tools are going to keep changing. The frontier moves quarterly, and the winner at the end of next year is not going to be the one you're using today.
That's why the discipline matters more than the tool. If your context lives inside a specific AI product's storage system, you're betting on that product still being the right answer in 18 months. It probably won't be. If your context lives in markdown files in a folder you own, you can swap the tool out underneath it and lose nothing.
The brain stays. The tool can die.
So start the vault now. A year from now you'll have a year of compounding context behind you. Most of the people you're competing with will still be pasting their company description into a fresh chat window every Monday and giving each project a PDF copy of their brand style guide.
Want help thinking through what this changes for your marketing operations?
Start a conversation