Context that travels

The loop

Think → Build → Remember, then around again.

• Think in the brain: research, brief, decisions.
• Build in ~/dev or ~/design: pages, components, screens.
• Remember: what I kept goes back to the brain project.

It doesn't always start at Think. Sometimes I prototype first and write the spec after, because a coded page answers questions a brief can't. The brain is the starting point and the memory, not a rulebook: a build session is free to try a layout or a section the spec doesn't have.

1. Loading context

Every session starts the same way, whatever the agent or the folder. One command finds the project and loads its context:

node ~/second-brain/.agents/hooks/brain-context.mjs --cwd "$PWD"

In a code repo, the repo's instruction file points to its brain project, so the agent knows that ~/dev/booking-app is the booking-app project. In Claude Code a session hook runs it automatically. In other agents, the instructions tell them to run it. Same loader everywhere, so no agent gets a different version of me.

What it loads, in order:

1. The global core: who I am, the rules that apply everywhere, the corrections that matter across projects.
2. The project essentials: what the project is, my brief and my rules, the project's lessons.
3. The decisions that match the task. When I say what I'm about to do, the loader ranks decisions by the words in the request and shows the matching ones in full, with their reasons. The others stay listed by their first line, so nothing is hidden.
4. Everything else on demand: details, roadmap, research, history. Listed, not loaded.

An earlier version kept only the most recent decisions. I dropped it: an early decision can matter more than yesterday's. Age isn't relevance.

2. Sharing context between brain, code and design

Loading gets the project into the session. Sharing is how pieces move between projects and folders while I work.

Ingredients in the prompt. When I build, I name what to combine: "voice from this analysis, layout reasoning from that site, content from my draft." Those ingredients win where they overlap with the project's own files, and the project fills whatever the prompt leaves open. Mixing sources is the point. I take the reasoning behind a reference, never its surface, unless I ask for a close match.

Shared references, declared. Some knowledge serves several projects: my career facts, my agency's identity. A project declares the shared files it needs, one by one. Nothing loads because two projects happen to sit in the same category. Explicit beats clever: I can always see why an agent knows something.

Notes to an agent, anywhere. I can leave a line in any file, a brief, a page of copy, a code comment: @agent: this title stays, propose a new subtitle. The next agent that opens the file answers right below it. It works the same in the brain and in a repo, so a question from a design session can wait in the code until a build session picks it up.

Chat-only mode. When I want to think before anything is written, I start with +chat or +brainstorm. The agent explores in the conversation and writes nothing, no file, no code, until I say "apply".

3. Remembering: the write-back

During a build session, edits stay where the work lives. Finishing a page doesn't close anything.

When I say "update brain", the agent writes back what I kept, and only that:

• the current state of the project
• decisions, each with its reason
• next steps in the roadmap
• the copy of a new page or section
• a visual or verbal direction I kept, described from the code into the project's design or voice file, next to my text and never over it
• links to the Figma file or the prototype

Tries I didn't keep need nothing. A dropped direction gets one line only when it teaches something.

/done closes the session: it saves, consolidates the corrections into lessons and makes one commit of its own files. Nothing is pushed without my say.

The loop also runs the other way. From the brain, "sync booking-app" reads what changed in the repo, code included, and updates the project. So a page I built on a Sunday without saying "update brain" doesn't get lost.

4. Optimisation: measure what every session pays

Context isn't free. Every line in a file that loads at start is read in every session, by every agent. So I measure it.

A small script estimates how much context each type of session loads at start, and how long the loader takes.

The useful part isn't the total. It's the table that multiplies each file's size by the number of session types that load it. My global instruction file is loaded by all of them, so a paragraph cut there saves more than a page cut anywhere else.

What came out of it:

• Tiers. Always-loaded essentials, task details on demand, history never at start.
• Short cores, no hard caps. A size target, never a reason to drop a rule.

I treat the setup like a product: ship, watch where it creates friction, cut what doesn't earn its place.

5. Tools: CLI first, MCP last

Agents also need to reach my tools: Notion, Gmail, Drive, Calendar, GitHub, the browser. The popular answer is MCP: plug a server or a connector into the app and the agent gets a set of tools. I avoid them as much as I can. My rule: when the vendor ships a command-line tool, the agent uses it, through a short skill that says how. The rule is written in my global decisions and in each skill's description, so the agent picks the CLI even when a connector is installed.

Why:

• Context cost. A connector puts its tools in front of the model, often in every session, whether the task needs them or not. A CLI skill costs one line in the skill list, and its full instructions load only when the task needs them.
• Every agent, same tool. A connector is set up app by app. A CLI lives in my terminal: Claude Code, Codex or the next agent runs the same command, with the same account. It's the same idea as one instruction file for every agent.
• I can run it myself. When something fails, I paste the command in my terminal and see exactly what the agent saw. No black box.
• It composes. Output goes to a file, through jq, into the next command. A Notion page read as Markdown can land straight in a brain project.
• Fewer surprises. The Gmail connector rewrote the links in my mails and couldn't carry a large PDF. That's why I moved off it.
• Control. Credentials stay in the system keychain or an environment variable, with the narrowest access. My Notion key only sees the pages I share with it.

What it looks like, with Google Workspace and Google's gws CLI:

gws gmail users messages list --params '{"userId":"me","maxResults":5}'
          gws drive files list --params '{"pageSize":5,"fields":"files(id,name)"}'
          gws calendar calendarList list --params '{"maxResults":5}'

Same pattern for Notion (ntn), GitHub (gh), Cloudflare (cf), web pages to Markdown (Crawl4AI) and the browser (Playwright CLI, with saved sign-in profiles).

Each skill fits on one screen: how to log in, the handful of commands I really use, and one guardrail: read before writing, ask before anything that deletes, sends, publishes or spends.

Adding a tool is a skill too. connect-tool notion looks for the vendor's official CLI and installs it. When there's none, it writes a one-file Python CLI over the vendor's API. It proves one real read works, then writes the skill. A few minutes, and every agent has the tool.

MCP stays for what a terminal can't do, like a live link to a Figma file open on my desktop.

6. Dream: reviewing memory before it drifts

Memory saved session by session drifts. The same rule ends up in two places with slightly different words. A summary goes stale after the decision behind it changed. A correction I gave weeks ago never made it into the file the agent actually reads.

So I have a review step called dream, named after what sleep does for memory: replay the day, keep what matters, make connections. I run it by hand on one project, /dream booking-app, or across the whole brain with /dream --global.

It looks for:

• forgotten corrections, first, because a correction I have to repeat costs me the most
• duplicates to merge, keeping every condition and reason
• contradictions between decisions
• stale summaries that no longer match their source
• useful connections across projects

And it follows strict rules. Originals are saved before any change. A contradiction stays visible until I choose, never resolved by "the newest wins". A one-off fix never becomes a universal rule on its own. Anything that changes a commitment comes to me as a before/after proposal. And it's manual: no scheduler, no background run.

On its first real run on my brain, it found guidance that still described how things worked before I reorganised my memory: how decisions load when no task is given, and where lessons are filed. It corrected them using the approved migration record and my journal as evidence, saved the originals first, and left my own text untouched.

What stays human

The loop moves context. It doesn't decide. Choosing a direction, judging a draft, saying no to a plausible idea: those don't go in the loop. Say the AI suggests a multi-step wizard for a booking app. It's plausible, and it's wrong for people who book from their phone between appointments, so a single page stays. That call is mine.

Close

Note 1 was about building the memory. This one is about keeping it alive: load only what the task needs, share it on purpose, reach tools through the terminal, write back what I kept, and review it before it drifts.

The agents change every few months. The loop is what I keep.