Don't let your AI context die with your AI tool
AI context engineering, minus the part everyone misses: your context should not depend on which tool is reading it. Build the brain — the tools will die.
May 14, 20264 min readMichael Fellner
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.
Frequently asked questions
- What is context engineering?
- It is the practice of shaping the material an AI model reads before it answers, rather than chasing a better prompt or a smarter model. The term comes from Andrej Karpathy. The claim behind it is simple: what separates a useful AI workflow from a useless one is not the model, it is the context it is working from. Build that material deliberately and the same tools produce noticeably better work.
- Why should your AI context not live inside your AI tool?
- Because the tool will be replaced. Claude Code did not exist eighteen months ago, Cursor was not ascendant twelve months ago, and Codex CLI appeared a few weeks ago. If your context sits in one product's storage, you are betting that product is still the right answer in eighteen months. Keep it in markdown files in a directory you own and you can swap the tool underneath and lose nothing.
- What makes a context vault actually work?
- The discipline that feeds it, not the vault itself. Installing Obsidian takes five minutes; remembering to save every useful insight by hand lasts about two weeks. What scales is process: handover protocols at the end of every major session, automated triggers that drop a structured summary into the right folder, and audits that check whether a new entry contradicts an older one. The agents have to write back, not only read.
- Who owns the context created during client work?
- The client does. The context layer built during an engagement stays with the client when the engagement ends, and is not absorbed into a personal library. They keep what was built and the brain that supported the build, so the next person they hire inherits the vault rather than starting cold. The work compounds for the client. It is the principle that pairs with building to be replaced.
Signal, by email
One email when there is a new piece. No sequence, no digest, no drip campaign.
Prefer a reader? Signal has an RSS feed
Google lets you choose which sources it shows you more of. Mark DETGAAO as a preferred source and Signal moves up in your search results, not everyone's.
Add as preferred sourceOne click, and reversible in your Google settings.
Want help thinking through what this changes for your marketing operations?
Start a conversation