Working with AI in 2026 -- Part 2
Context is the Interface
TL;DR: The context window isn’t a log of your conversation — it’s the environment you’re working in. How you build it, manage it, and know when to reset it is a learnable skill. Here’s how I learned to use it deliberately.
Knowing that context matters doesn’t automatically make you good at managing it. Part 1 of this series introduced the latent space — the idea that your prompt navigates a probability space, and that the context window is live signal shaping every response. That framing is useful. But understanding what the context window is and knowing how to work with it are two different things, and the gap between them is where most people stay stuck.
The skill is managing context deliberately. And like most skills, it looks obvious once you’ve developed it and invisible until you have.
There are names for what I’m describing. Prompt engineering is the craft of designing inputs deliberately — structuring questions, establishing role and task, managing what the model is navigating toward. Context management is the practice layer: what you actually do with the window, session to session. Neither is new. I didn’t invent any of this, and there are entire communities building sophisticated frameworks around both. What I can offer is how these ideas behave in daily practice, once they’ve moved from technique to habit.
The first shift is recognizing what the context window actually is in practice.
It’s not a transcript. It’s not a memory bank. It’s not a running record the model consults the way you’d scroll up in a chat to check something. It’s the active environment the model is reasoning from — every token in the window is simultaneous input, weighted and processed together. When you send a message, the model isn’t reading your history and then answering. It’s generating a response shaped by the full state of the window at that moment.
That distinction matters because it changes what you try to control. If the window is a log, you manage it by being thorough — add more, include everything, make sure nothing is missing. If the window is an environment, you manage it like a workspace — deliberately structured, kept clean enough to think in, and rebuilt when it gets cluttered.
The opening of a session is where most of the leverage is.
I call this priming, though it’s less like priming a pump and more like establishing the conditions of a room before work begins. The first few exchanges set the probability neighborhood the model operates from for everything that follows. A session that opens with good framing — what you’re doing, what kind of output is useful, what the relevant constraints are — stays oriented across a long run. A session that starts with a vague first message wanders, and no amount of mid-session correction fully recovers it.
In practice, good priming isn’t long. It’s specific. It doesn’t have to be a formal system prompt or a preamble paragraph. A sentence or two that establishes role, task, and expected output format is usually enough. The goal is to arrive at the first substantive exchange with the model already oriented — already occupying the right neighborhood in the latent space — rather than spending the first three messages trying to steer it there.
What I’ve learned to avoid: opening with the question I want answered without establishing what kind of answer I need. “How do I do X?” drops the model into a generic helpful-assistant posture. “I’m working on Y, here’s the constraint, how do I approach X?” puts it somewhere much more useful.
The harder thing to learn is recognizing drift.
Sessions evolve. You start with a clear goal, work through it, take a side turn to clarify something, follow a tangent that turned out to be useful, then find yourself three exchanges later wondering why the responses don’t feel as sharp. That’s context drift — not a sudden failure, but a gradual shift in what the window is communicating to the model about where you are and what you need.
Context drift has a subtler cousin I think of as context debt. Debt builds when the window accumulates noise: failed attempts, abandoned directions, contradictory signals. Each one isn’t much on its own. Together they crowd out the signal that was working. You can feel it as a kind of flatness in the responses — the model is still technically answering, but it’s lost the thread of what you were actually building toward.
Recognizing drift and debt early is the skill. The fix for drift is usually a short recalibration message — a brief statement of where you actually are and what you need now, without referencing everything that led there. The fix for debt is sometimes the same, and sometimes it’s a reset.
The reset decision is the one I got wrong for the longest time.
My instinct was always to continue. Starting a new chat felt like losing work — all that context, gone. But that’s the wrong frame. A context window that’s drifted or debt-laden isn’t an asset; it’s drag. Every response you pull from a cluttered window is being shaped by everything you didn’t mean to include as much as by the things you did.
The way I think about it now: context is not cumulative value. It’s working state. And working state goes stale.
The recipe metaphor is useful here. Imagine starting a recipe from step four without knowing what was done in steps one through three. The instructions for step four assume a state of ingredients that you haven’t established. You can sometimes infer it, but you’re working around an absence, not from a foundation. Starting a new session mid-project has the same problem — except you can fix it, by taking two minutes to re-establish the context that makes the next steps sensible before you send the first message.
My criteria for a reset: if recalibrating in the current window would take longer than opening a fresh one and priming it properly, open a fresh one. The new chat isn’t a loss. It’s a clean workspace.
Three things changed in how I run sessions once I started treating context as something to manage rather than something that just happens.
I started every significant session with an explicit prime — a short statement of what I’m working on, what role I need the model in, and what good output looks like. Not a formal ritual, just enough to establish the room before the work starts. Sessions that open this way stay on track longer and require less mid-session steering.
I started watching for the flatness signal. When responses start feeling technically correct but slightly beside the point, I take that as a sign to pause and recalibrate rather than push harder. Pushing harder into a drifted context just digs the drift deeper. A short recalibration — “let me restate where I actually am” — resets the neighborhood more reliably than rephrasing the question.
I stopped treating the reset decision as a failure. A fresh chat is a tool. Using it when the current window is working against you isn’t starting over; it’s choosing the right instrument for where the work actually is. It’s not nothing. Re-establishing context takes real effort — on complex work, you’re carrying a lot. What changed for me is that the output from a clean, deliberately primed session is worth that overhead. As the work gets more layered and more automated, managing that overhead becomes its own design problem — but that’s a different post.
This is Part 2 of “Working with AI in 2026.” Part 3 is about iteration — what happens after you’ve built a good context and gotten a useful first response. Navigating well and managing context well gets you to a good starting point. Iteration is how you get from there to something worth keeping.