Every AI session starts the same way by default: from nothing. The model has no idea what you built yesterday, what was left half-finished at midnight, what the client said on the call this morning, or what you already tried and gave up on. You open a new session and the whole context is gone. You are, again, the person explaining the project from scratch.
For a one-off task that's fine. For someone building software every day across a dozen active projects, it's a tax that compounds. You spend the first ten minutes of every session re-orienting the AI. Then you make the mistake of doing it quickly, and it touches the wrong thing, and you spend twenty minutes fixing it.
I decided to treat this as an engineering problem and build around it.
1.The session that started in the wrong place
I was picking up a project that had been live and running in production for two weeks. New session, opened Claude, jumped straight in. The AI started reasoning from its memory of how the codebase had looked when it last touched it — which was not how it looked now. The component had been refactored. The state had moved. The pattern I'd established for backend calls had changed.
None of that was in the conversation. It was in the repo, sitting there, correct. But I hadn't told the AI to read the files; I'd told it the task. And so it proceeded confidently from a model of the code that was two weeks out of date.
The rule I wrote down from that session: memory tells you context; files tell you truth. Every session now starts with a brief read of the actual files we're about to touch — not a summary of what they contain, but the real thing. The AI's memory of what it helped build is always worth less than the current state of the code.
2.The context that was already there, unread
I was drafting a set of build prompts for a new tool — something that would eventually be pitched at a senior product meeting. I had all the project's own documentation open: the spec, the schema, the scoring framework. I wrote the first draft from those.
What I didn't pull in was the adjacent memory. Platform deadlines that were live in memory files. API restrictions I'd already documented. Compatibility constraints for the environment the tool would run in. None of it appeared in the first draft.
Peter had to ask "have you checked all the relevant Wix constraints?" before I went looking. For something being pitched to a decision-maker in four days, that miss was unacceptable. The information existed. I had written it down. It simply wasn't connected to the task at hand until someone made the connection explicitly.
The system now has a rule baked into it: before writing any spec or build prompt, scan the full memory index for adjacent files. Not just the project's own docs — the platform intelligence, the known gotchas, the deprecation deadlines. Anything that lives within two degrees of the topic gets pulled in before the first draft.
3.The session that ended and left nothing behind
Early on, I didn't close sessions with any kind of record. The work was done, I closed the tab, and the next session started cold. After a while I noticed a pattern: I was re-learning the same things. Making the same kinds of mistakes. Writing the same notes to myself in commit messages.
The compound value of working with AI over months isn't the individual sessions — it's what accumulates. But accumulation only happens if you deposit something at the end of each session. So now every session ends with a three-line report: what was saved, what was updated, what I'll do differently next time. If nothing genuinely improved, it says so. It doesn't fabricate progress.
And every session starts with a hook that fires automatically — a script that reads recent memory activity, flags unfinished items, pulls the last session anchor, and injects a briefing before the first message. Nothing to remember. Nothing to ask for. The context loads before you type.
The two pieces together — session-start hook and end-of-session report — create a feedback loop that actually compounds. Each session is slightly less likely to repeat a mistake than the last one.
The pattern underneath
Three failures, same cause: context that existed wasn't connected to the moment that needed it. Old code state, adjacent memory, prior lessons — all of it was somewhere, reachable, and all of it failed to arrive in time.
The second brain isn't a clever tool. It's a discipline. Read the files. Pull the adjacent context. Leave a record. Do it every session, not the sessions that feel important. The sessions that feel routine are the ones where skipping it costs you most.
What I built to support this:
- A session-start hook that auto-loads recent context and flags open items
- An adjacent-memory protocol for any task with stakes
- An end-of-session three-liner that's short enough to actually write
- A daily brief that aggregates the previous day's activity by project
None of it is complicated. All of it is the kind of thing that only helps if you do it consistently rather than when you remember to.