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. Spent time with my family. Rested. Kept up with my full-time job. Let myself breathe for a minute.
But in the background, a question kept quietly 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 in the back of my head through the family time and the rest and the full-time job piling back up.
Then I was scrolling LinkedIn and a post stopped me. It linked out to a Substack piece about context drift in long AI sessions. I read it and felt something settle.
Not alarm. Relief.
Because here’s what I found when I actually went and asked Claude directly — what do I have in place to handle this, really? — the answer was: more than I thought. The systems I’d been building around my workflow had already solved most of the problem. I just hadn’t named it yet.
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, early content gets deprioritized. The model isn’t forgetting in the human sense. It’s just weighting recent tokens more heavily than old ones. The result is the same: decisions you made at the beginning of a session stop governing decisions at the end of it.
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.
The Three Tools I Use
Memory for durable facts. Most AI interfaces have some version of persistent memory — facts and preferences that carry across sessions automatically. Use this aggressively for anything that should always be true: your stack, your constraints, your user, your architectural non-negotiables. For GigOps, my memory profile includes the full tech stack, the repo strategy, the human approval gate as a non-negotiable design decision, and the first client’s context. I never have to re-explain those things. They travel with me. The limit: memory captures facts, not reasoning. It doesn’t preserve why you made a decision, just what the decision was.
Re-entry blocks for session context. A re-entry block is a dense, structured summary of the current state of a project that you paste at the top of a new conversation to re-anchor the AI before you start working. Mine for GigOps covers the full stack, the architecture pattern and why it exists, what’s complete, what’s deployed, known open issues, and the constraints that must be maintained. It reads like a technical briefing. It takes about 30 seconds to paste and saves an enormous amount of drift-related debugging. The key is that re-entry blocks capture reasoning, not just facts — not just what was decided, but why. You can generate one at the end of any productive session by asking the AI to summarize the current state in briefing format. Save it. I keep mine in the project repo.
Session recaps as a forcing function. At the end of every working session, I generate a structured session recap as a markdown file. This is partly for my own memory, but it also doubles as source material for the next re-entry block. If something important was decided in a session — an architectural choice, a constraint added, a feature scoped out — it goes in the recap, which means it has a chance of making it into the next session’s context. Walking into a new session with that file means I’m not reconstructing state from scratch. I’m picking up a thread that was deliberately set down.
The Practical Rules
Fresh thread for each new phase. A long single 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.
Add constraints to memory immediately. Any time you make a decision that should govern the rest of the project — especially the kind you’d be annoyed to re-explain — add it to memory right then. Don’t wait for the recap. These belong in persistent memory, not just in the conversation.
When something feels off, re-anchor. 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 in the moment gets overwritten by the next long exchange. A re-anchoring sticks.
The Bigger Frame
There’s a version of this that’s easy to dismiss as just a technical workaround for a model limitation. But I think it points at something more important about what it means to work effectively with AI systems.
The AI is not the continuity. You are.
Your job isn’t just to issue prompts. Your job is to maintain the coherent state of the project across sessions, across tools, across the inevitable drift that comes with any 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 — 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 supposed to be 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.
Your re-entry block is your pre-flight checklist. Run it every time.
What’s the longest AI session you’ve let run before questioning whether drift had set in? I’d be curious what you noticed — and what you did about it.
This is Latina in the Loop — building, questioning, and stewarding intelligent systems in real time. Follow along.