The Handoff Problem: Why Your AI Forgets Between Sessions

You spend two hours on a feature. By the end, the assistant knows the codebase's conventions, the three constraints you mentioned in passing, the approach you rejected and why, and the specific bug you'd already ruled out twice. It's genuinely useful — that accumulated context is most of what makes the last hour better than the first.

Then you close the terminal.

Tomorrow you open a fresh session and it knows none of it. Not a degraded version — none of it. You re-explain the architecture, and about twenty minutes in you get suggested the exact approach you rejected yesterday, for exactly the reasons you already worked through.

This is the handoff problem, and it's the most reliably expensive thing about working this way. Not hallucination, not bad code — just the same twenty minutes, every morning, forever.

Why it isn't fixed by longer context windows

The obvious response is "context windows are huge now, just paste everything in." This doesn't work, for two reasons.

The first is that you don't have the thing to paste. The valuable context from yesterday isn't in a file — it's the conclusions of a two-hour conversation. It's distributed across forty messages, most of which are dead ends. Pasting the transcript back in gives the model the search space you already searched, and it'll dutifully re-consider the branches you rejected because nothing marks them as rejected.

The second is that a longer window makes it worse, not better. A model with 30,000 tokens of yesterday's meandering conversation has to work out which parts still apply. Some of it is stale — decisions that got reversed, files that have since changed, a bug that's now fixed. Stale context is worse than no context, because it's confidently wrong instead of absent.

The problem was never capacity. It's that nobody wrote down the conclusions.

The three kinds of context, and only one is worth saving

Codebase context — how this project is structured, what the conventions are, where things live. This is derivable. The model can read the code. Writing it down is mostly wasted effort, and worse, it goes stale silently: a document describing a structure that was refactored last month is actively misleading, and nothing will tell you.

Session context — what we tried in the last hour, which file we're in the middle of, what the current error is. This is genuinely ephemeral and should be. It's about a task that will be finished.

Decision context — we're not using WebSockets because the hosting platform doesn't support them on this plan. We tried Postgres full-text search and it was too slow for the fuzzy matching we need. Auth has to stay in middleware because the marketing pages are statically generated.

Only the third category is worth writing down. It's the only one that's both non-derivable and durable. And the tell is always the same shape: a decision plus the reason it was made. The reason is the load-bearing half — a decision without a rationale gets re-litigated the moment someone sees a simpler-looking option, and "someone" includes an assistant that has never heard of the constraint.

Where it should live

The instinct is to keep a running notes file. In practice this rots faster than anything else in the repo, because updating it isn't attached to anything you already do.

Better: put decision context where it's already load-bearing.

In the project instructions file (CLAUDE.md, or whatever your tool reads) for anything that applies across the whole project. "No WebSockets — the hosting plan doesn't support them, use SSE." Five words of constraint, ten words of reason. This file gets read every session automatically, which is the entire point. Nobody has to remember to include it.

In a code comment for anything local to one file. If the reason a function retries three times is that the upstream API rate-limits in bursts, that belongs three lines above the retry loop, not in a document. A comment that explains a non-obvious why is the highest-value comment there is, and it's the one thing that never goes stale unnoticed — it's right there when someone edits the code it describes.

In the commit message for anything about a change. "Switched to sliding window because fixed windows let a burst through at the boundary" is a sentence you'll be glad exists in eight months, and writing it costs nothing because you're writing a commit message anyway.

The pattern: attach the note to something that already gets maintained. A standalone document is a thing you have to remember to update. A comment next to the code, or a line in the file your tooling already reads every session, isn't.

The end-of-session habit

The one deliberate thing worth doing: before you stop, ask for a summary of decisions made — not work done, decisions.

"Summarise the decisions we made this session and why. Skip what we implemented; I want the constraints and the rejected options."

You get back five or six lines. Most of them you already knew. One or two are things you'd have forgotten by Thursday. Those go in the instructions file or a comment, and they're the difference between starting tomorrow at minute zero or minute twenty.

It takes about ninety seconds. It's the highest-return ninety seconds in the whole workflow, and I skip it constantly, and every time I skip it I pay for it.

What actually happens in a good handoff

The measure of a good handoff isn't how much the next session knows. It's how quickly it stops proposing things you've already ruled out.

A cold session with good written constraints will read the instructions file, see "no WebSockets, plan doesn't support them," and go straight to SSE without you saying a word. It doesn't need to know that you spent forty minutes discovering this yesterday. It needs the conclusion.

That's the whole trick, and it's not really about AI at all. It's the same reason a good README beats a good onboarding call: the call is higher bandwidth and evaporates, the README is lower bandwidth and compounds. We've known this about human handoffs for decades. The only new thing is that the handoff now happens every morning instead of every time someone joins the team, which makes the cost of not writing things down about two hundred times higher.

The uncomfortable corollary

If decision context is what matters, and decision context is exactly the thing that only exists in your head, then the assistant forgetting is not really the problem.

The problem is that you were the only place the reasoning lived, and you were fine with that until something else needed it. The forgetting just made it visible.

Related: Context windows and AI coding · The spec is the work now · Chaining AI tools together