What An AI Context Window Actually Is. It Is A Desk.

Ryan “RyMac” McKinney · USMC · 15 August 2026 · 6 minute read

A context window is everything the AI can see while it works: your instructions, the conversation so far, and any files it opened. It has a hard limit. When it fills up, the oldest things drop out of view, the model does not tell you, and the answers keep coming as confidently as ever. That is the whole thing you have been running into.

Picture a real desk

There is only so much room on it.

You put a new folder down. Something already there slides off the edge and onto the floor.

Nobody announces it. There is no alarm. You just carry on working from what is still on the desk.

That is a context window. That is all it is.

Why it feels like it "suddenly got worse"

This is the part that makes people think the model broke.

You spend 40 minutes building something up. It is going great. Then somewhere past the middle it starts giving you answers that ignore a decision you made 20 minutes ago.

You did not do anything wrong. The thing you told it is simply no longer in front of it.

And here is the cruel part: it does not know that. It cannot say "I have lost the pricing decision you gave me." It just answers with what it can still see, in the same confident voice it used when it had everything.

Confidence is not a signal of completeness. It never was.

So just get a bigger desk, right?

That is what everybody tries first. Buy the model with the million token window and stop worrying about it.

It helps. It does not fix it, and I want to be honest about why.

Research into long-context performance keeps finding the same uncomfortable thing: models get worse at using information as the pile in front of them grows. More on the desk means more to sift, and the important sheet gets buried under things that merely look relevant.

So dumping your entire business into a giant window is not the solution. It is the same problem with a bigger footprint.

The fix is not more room. The fix is deciding what sits on the desk and what waits in a drawer until it is needed.

What a drawer looks like

A folder. An actual folder on your computer.

The trick is that the desk needs to know the drawers exist. So you tape a card to the desk that says where everything is.

~/business/
├── CLAUDE.md          <- the card taped to the desk. 11 lines
├── Context.md         <- what is on the desk right now
└── ops/
    ├── clients/       <- the drawers
    ├── offers/
    ├── sops/
    └── archive/

Now the desk stays clear. The agent reads the card, the card sends it to 1 file, that file names the folder holding today's work, and it opens only that.

Nothing else is on the desk, so nothing else can fall off it.

The 3 questions this answers

"Why did it forget what I told it?" It did not forget. It stopped being able to see it. Those are different problems with different fixes.

"Why does it make things up later in a session?" Because a gap where information used to be still gets an answer. The model fills the hole rather than reporting it.

"Why does starting a fresh chat fix it?" Because you cleared the desk. That is also why the fix does not last: you cleared it, you did not organize it.

The test that tells you the truth

Open a brand new session. No memory of you, no history.

Ask it where one of your projects stands.

If it finds the answer in 2 moves, your filing is sound.

If it cannot, no prompt is going to rescue that. The information was never written down anywhere it could look, and you have been holding it in your own head and re-typing it every morning.

Most setups fail this. Mine failed it the first time.

Where this comes from

The method has a name. Interpretable Context Methodology, ICM, and it is not mine. Jake Van Clief and David McDermott wrote the paper. Their argument in 1 line: the folder structure can do the job people currently write orchestration code to do.

I read it, ran it on my own businesses, and have been showing the receipts since. If you want the methodology itself broken down, I wrote that up here: Interpretable Context Methodology in plain English.

And if you want the version where I explain why I stopped trying to fix this with more agents, that is the context engineering post.