We have done the diagnosis and we have done the map. You know the trap: re-explaining yourself into a box that forgets. You know the surfaces: the Chat that forgets, and the ones that can be made to remember. This chapter is where you stop re-explaining. This is the chapter the title of the whole book is pointing at.
The move is simple to say and it changes everything once you do it. You take the things you keep typing over and over, who your customers are, how you talk, what you are working on, your rules and your standards, and you write them down in a place Claude reads on its own, automatically, before it does anything at all. You do not tell it inside a conversation that will vanish. You tell it once, in a file that stays, and it reads that file every single time it starts work. The re-explaining stops because the explanation is already there, waiting, being read before you have even finished typing your request.
You may have heard a version of this idea already, from a completely different world. People in the note-taking world talk about building a second brain, a system outside your head that holds everything you know so you are not carrying it all in working memory. Here is the connection worth making. A second brain built for you is notes you can search. Context engineering is a second brain built for the AI, notes it reads before every task without being asked. Same instinct, one difference that matters: this one is not for you to reread, it is for the machine to read so it shows up already knowing you. If the second brain idea already clicks for you, this is that, pointed at your AI instead of at yourself.
Now let me show you the actual pieces, because "write it down where it reads it" splits into a few kinds of memory, and they behave nothing alike.
The always-on brief: CLAUDE.md
There is a file called CLAUDE.md. The name is literal, it is a file named CLAUDE, and its whole job is to be the thing Claude reads before every task on that surface. Think of it as the briefing you would give a new hire on their first morning, except you write it once and every "new hire," every fresh session, reads it automatically before they lift a finger.
What goes in it changes as you grow, and this is worth teaching as a progression, because it is exactly the journey I went through and the one you will too.
When you are starting out, put everything in it. Who you are, what your business does, who your customers are, how you write, your rules, your rates. One file, read always. This is correct and it is simple, and simple is the right call when your whole setup is one file. Do not overthink it. The win at this stage is enormous and the cost is nothing.
But watch what happens as the system grows, because the file starts to strain. My own CLAUDE.md is not a warehouse that holds everything about my business. It is an operating manual and a router. The always-read part is short: a brief who-I-am section, then mostly rules for how to work. How my agent team is set up and which role does what. Which kind of work goes where. My writing rules. My privacy rules. And then the pointers to where the deeper context lives. My actual brand voice, my detailed audience definitions, my strategy, those do not sit in CLAUDE.md. They live in Notion, and the file tells Claude where they are and when to go fetch them through the connector, for the tasks that need them. The file does not try to know everything. It knows how I work and where everything is.
Here is the reason to make that shift, stated plainly, because it is the whole logic. The AI reads this brief on every single task. So the brief should carry what every task needs, and point to the rest. Who you are and your house rules are needed every time, so they stay in the always-read file. Your full audience research is needed only when you are writing for that audience, so it lives in a scoped place and gets fetched when it is relevant. A bloated always-on brief is not free. It spends attention on every lap, making the AI read your entire strategy deck before answering a one-line question. The router keeps the always-on part lean and sends the AI to the deep context exactly when the deep context matters.
So the rule of the progression is this. Start with everything in one file, because simple wins. As it grows, let the file become a router: the always-read part holds who you are, your house rules, and a map of where deeper context lives, and the deep context moves into scoped files and connected sources that get pulled in when relevant.
Now, the obvious question. Where should that deeper context actually live? And the honest answer is that it does not matter nearly as much as people think. Your second brain can live in a lot of places, and none of them is the right one. There are only two requirements, and any option that meets both is fine.
One, the AI has to be able to read it. That means it is somewhere a surface can reach: local files it can open, or a connected source it pulls through a connector. Two, it has to have a structure the AI can navigate. Named files or pages, one topic per file, not one giant document that dumps everything into a wall of text. A tidy shelf it can find things on, not a junk drawer.
Meet those two, and here are the common homes so you recognize yours. Local markdown files in a folder are the simplest thing that works, and they work directly with Code and Cowork. If you use Obsidian, you already have this and may not realize it, because an Obsidian vault is just a folder of markdown files, so Code can read it as it stands, no migration. A GitHub repo is the same as local files with version history on top, which is natural if you already live in repos. Notion is what I use, read through the connector, and it shines when your second brain doubles as your actual workspace with databases you already run your business from. Google Drive, or anything like it, works through connectors too and is fine when your material already lives there.
The move is to use the one you already use, not to go pick the best one. Do not migrate your whole life into a new tool for the sake of tidiness. The router in your always-read brief does not care where the context lives, it just needs to point at wherever it already is. If your notes are in a folder, point there. If they are in Notion, point there. The pattern is identical and the tool is a detail.
The difference this makes is not subtle. Before, you told the AI your voice inside one chat, and that chat is now gone, so the next one sounds generic again. After, whether your voice lives in the file or in a Notion page the file points to, every session starts already sounding like you, because it read who you are and knew where to find the rest before it wrote a word. You went from "I told it once, in a conversation that vanished" to "it reads me every time it starts, and it knows where to look for the rest."
Scoped context: project instructions
CLAUDE.md is who you are in general. But you do not do only one kind of work, and you do not want your invoicing context bleeding into your content context. So there is a scoped version. Project instructions, or a project workspace, let you attach a specific set of context and files to a specific kind of work.
The client proposal work gets the proposal context: your positioning, your pricing logic, your past examples. The content work gets the content context: your audience, your voice, the topics you cover. Same principle as CLAUDE.md, narrower aim. The AI reads the general brief and then the project brief, and now it knows both who you are and which job you are doing right now.
You do not need to overthink the line between the two. General truths about you and your business go in the always-on brief. Things that only matter for one type of work go in that work's project context. If you get it slightly wrong the world does not end, you move a line from one file to the other.
The AI's own notebook: auto-memory
Here is the kind of memory people find most surprising. The AI can keep its own running notes about you. Not a file you write, a file it writes, quietly, as it learns things across your work together. It remembers that decision you made three sessions ago and why. It remembers the standing facts about your project so you stop re-establishing them. It is the difference between an assistant who is new every day and one who has actually been working with you for a month and remembers the month.
You do not have to manage this closely. You mostly let it accumulate and occasionally tidy it. But knowing it exists changes how the whole thing feels. Your context is not only the brief you wrote on purpose. It is also the growing memory the AI keeps of working with you, which means the setup gets better the longer you use it, on its own.
Why all of this is an asset, not a chore
Here is the reframe I promised in chapter one, and now you have the parts to feel it instead of just hear it.
The things in this chapter you build once and then reuse on every task. The always-on brief, the project contexts, the memory that accumulates by itself. That is what makes them an asset. You spend the effort up front and it pays out on every future lap, instead of the prompt-engineering trap where you paid the full setup cost on every single request and kept nothing. This is the opposite economics.
But let me be honest about a thing I got wrong when I started, because "build it once" quietly implies "and never touch it again," and that is not true. Context is a living thing. My own context files have changed many times as the business changed. My audience widened, so the audience definition had to widen with it. My positioning shifted, so the brief that described it went stale until I updated it. My writing rules sharpened as I learned what actually worked, and the old rules would have held me to a worse standard. An asset is a garden, not a monument you build and admire. It stays valuable because you tend it.
And here is the part that matters most, because it is counterintuitive. An outdated brief is worse than no brief at all. A missing brief just leaves the AI uninformed, and it will hedge or ask. An outdated brief actively misleads, and it does so with full confidence, because the AI has no way to know your context went stale. It will describe last year's audience to this year's customer and sound completely sure. So maintenance is not optional polish. It is the thing that keeps the asset from turning into a liability.
None of this breaks the economics, which is the whole point. Tending a garden is a tiny fraction of the cost of replanting it from bare soil every single morning, which is what re-briefing from scratch on every task actually is. Build it once, then maintain it, and it still pays out on every lap. It just is not fire-and-forget, and anyone who tells you it is has not run one for long.
Let me make it concrete with two examples, one of them from my own system.
Example: brand voice and audience as standing context [from my own system]. I write content on a rhythm, LinkedIn posts and blog pieces, several times a week, and every piece has to hit a specific kind of buyer and sound like my company and not like generic AI. The naive way, the way I did it early on, was to describe the audience and the tone inside every new session. I would get something that was seventy percent right and thirty percent off, and I would hand-fix the voice every time, forever.
The built way is that my content setup reads my brand voice, my definition of who I am writing for, and even recent signals about what has been landing, from standing context sourced from Notion, automatically, before it drafts anything. This is the router pattern from a few pages ago, in action: none of that brand voice or audience detail sits in my always-read brief. It lives in Notion, and the setup goes and fetches it exactly when a writing task needs it. Mine happens to be Notion because my databases already live there and my second brain doubles as the workspace I run the business from. Yours might just as easily be a folder of markdown files, and the pattern is identical. I do not re-explain the audience. The system already knows the specific buyer titles I write for, the language they use about their own problems, and which angles worked lately. I am describing the shape of it here, not handing you my actual files, because the files are mine and the shape is what teaches you. What changed is that the drafts arrive already on-voice and on-target, so my job shrank from rewriting the tone to nudging the ideas. The tone is handled. It is handled because the context is standing infrastructure, not something I retype at eight in the morning and half remember.
Example: the freelancer's standing brief. Say you are a freelance designer. You want every AI task to respect your rates, the kinds of clients you will and will not take, and your house writing style. The naive way is that you remember to mention these sometimes and forget others, and the output drifts depending on what you happened to include that day. The built way is one always-on brief that holds who you are, what you charge, and how you write, read before every task. What changed is that consistency stopped depending on your memory. The context enforces the standard so you do not have to remember to.