I have a build sitting open that I haven’t gone back to yet.
I just wrapped a six-week intensive cohort. I shipped a product, did a live pitch, and onboarded my first client. Then I did what you’re supposed to do: I stepped away. I spent time with my family, rested, kept up with my full-time job, and let myself breathe for a minute.
But a question kept surfacing: when I pick the build back up, what do I do with that conversation?
GigOps is real, deployed, and has a live client. But the build conversation that got it there is one very long Claude session. Dense. Decisions layered on top of each other. Starting a new session felt right. Clean slate, no accumulated noise. But it also felt risky. What if I lost the thread? What if the new session didn’t have enough context to pick up where we left off? So I sat with the question unresolved, carrying it through the family time and the rest and the full-time job piling back up.
Then I was scrolling LinkedIn when a post stopped me. It linked out to a Substack piece about context drift in long AI sessions. I read it and something settled. I suspected I had accounted for this in some ways but I had to confirm.
When I went and asked Claude directly what I actually had in place to handle this, the answer was: more than I thought. The systems I’d been building around my workflow seemed to cover most of the problem. I just hadn’t tested that assumption under sustained use yet.
Before I went further, I needed to be precise about what was actually happening. I’m testing this now against real builds, not as a polished framework but as a working way to keep continuity intact when a project leaves one session and has to survive the next.
What Context Drift Actually Is
Context drift is not a bug. It’s a structural feature of how large language models work.
Every AI session has a context window: a finite amount of conversation the model can hold in active memory. In a long session, earlier content gets deprioritized. The model isn’t forgetting in the human sense. It’s weighting recent tokens more heavily than older ones. The result is similar. Decisions you made at the beginning of a session stop reliably governing decisions at the end.
This matters more than most people realize because the early part of a session is usually where you establish constraints. The architecture pattern you committed to. The feature you explicitly decided not to build. The scope boundary you drew. All of that is most at risk.
There’s also a second kind of drift: cross-session drift. You close the chat, open a new one, and start fresh. Except you’re not actually fresh. You’re rebuilding context from scratch every time, often imperfectly, often from memory. Over time, you end up with an AI that knows a lot of facts about your project but has no coherent understanding of why decisions were made.
What I realized is that I wasn’t starting from zero. I already had a system in place. I just hadn’t named it clearly enough to use it deliberately.
The Two Tools I Use
The re-entry block, which is also the project instruction. This is a single document that does two jobs. It loads automatically at the start of every session as the project instruction, so the fundamentals (stack, architecture, constraints, active work) are present before you type the first message. And it gets rewritten at the end of every session to reflect what changed. The key distinction from conventional memory is that it carries reasoning, not just facts. It records why a decision was made, which is the part most likely to drift. Every constraint includes the tradeoff that produced it. Every architectural choice includes what it was chosen over and why. That’s what makes it useful across sessions, not just within one.
Session recaps as a forcing function. At the end of every working session, I generate a structured recap as a markdown file. Every decision gets recorded alongside its reasoning. Anything architectural, any constraint added, any feature explicitly scoped out, it goes in the recap. That file becomes the source material for the updated re-entry block, which then becomes the project instruction for the next session. Nothing important has to be reconstructed from memory. You’re picking up a thread that was deliberately set down.
The two tools are designed to feed each other. The recap captures what happened. The re-entry block distills it into what the next session needs to know. Together they maintain something that a single long conversation can’t: a coherent record of the project that survives the gap between sessions.
The Practical Rules
My sense is that these only help if I use them consistently.
Fresh thread for each new phase. A single long thread accumulates drift the way a long meeting accumulates confusion. When you finish a major phase of work, a feature, a deployment, a decision sprint, close the thread. Start fresh with a re-entry block. The old thread is still there if you need to reference it.
Label context that doesn’t need a response. If you need the AI to hold information without acting on it, say so explicitly: “context only, no response needed.” This is useful when you want to load background without triggering a long unnecessary reply.
Document decisions the moment you make them. Any time you land on something that should govern the rest of the project, note it immediately: in the session, in the recap, in the re-entry block. Don’t trust yourself to reconstruct it later. The reasoning is the first thing to go.
When something feels off, re-anchor deliberately. If the AI starts suggesting something that contradicts an earlier decision, that’s a drift signal. Don’t just correct it in the moment. Paste the relevant section of the re-entry block and explicitly re-establish the constraint. One correction buried inside a long exchange gets overwritten by the next one. A deliberate re-anchoring holds better.
The Bigger Frame
This is easy to treat as a workaround for a model limitation. It’s more than that.
The AI is not the continuity. You are.
Your job isn’t just to issue prompts. It’s to maintain the coherent state of the project across sessions, tools, and the inevitable drift that comes with long collaboration. That’s a governance function, not a prompting function. And it requires the same intentionality you’d bring to managing a team: keeping shared context alive, making sure decisions are documented, knowing when to re-brief.
I got my Remote Pilot License for small unmanned aircraft systems before I started building AI systems, and there’s a concept in drone operations called situational awareness. It’s the pilot’s continuous mental model of where the aircraft is, what the airspace looks like, what the weather is doing, and what comes next. When you lose situational awareness operating a drone, the aircraft doesn’t warn you. It just keeps flying. Things start going wrong in ways that don’t make sense until you’ve already lost the thread of what you were controlling.
Context drift is the AI equivalent of degraded situational awareness. The system keeps running. It just stops being governed by what you actually decided.
For me, the re-entry block is becoming the equivalent of a pre-flight checklist. The real test is whether it keeps holding up every time I return to a build.
I’m still testing how well this holds once the sessions get longer, the decisions get messier, and the project pressure goes up. What’s the longest AI session you’ve let run before you noticed drift, and what did you do about it?