You made a decision on Tuesday. You and the agent talked through why the auth layer had to stay stateless, weighed two approaches, picked one, and moved on. On Thursday you open a new session, ask for a change nearby, and the agent cheerfully proposes the approach you already rejected. You explain it again. You’ve now paid for that decision twice, and the second time bought you nothing.
That’s context loss, and if you operate agents for real work it’s probably the single biggest tax on your day. Not model quality. Not token cost. The steady drip of re-establishing things the system already figured out, because the place it figured them out was a conversation, and conversations end.
It doesn’t feel like a big cost because it never arrives as one bill. It arrives as a thousand small re-explanations, each cheap enough to absorb, adding up to a large fraction of your attention spent telling agents what they, in some sense, already knew.
Two different losses that get called the same thing
“Losing context” covers two failures that behave differently and need different fixes.
The first is loss within a session, when the context window fills and compacts. A long run gets summarized to fit, and summarization is lossy on purpose. Handling that boundary deliberately is its own discipline, managing the context window on long work. The model keeps a compressed gist and drops specifics. The specifics it drops are frequently the ones that mattered least to the summary and most to you: the exact reason you rejected an approach, the invariant you agreed to protect three hours ago, the edge case you explicitly told it to handle. The transcript still reads fine. The agent just quietly stops honoring a constraint it can no longer see. This is close cousin to the reason agents will drift: the specification it’s working against has silently changed, and nothing flagged the change.
The second is loss between sessions. A new session starts cold. Whatever wasn’t written down somewhere durable is simply gone. The code survived, because code is a file. The reasoning behind the code did not, because reasoning lived in the chat. You reopen the project and the agent knows what the code says and nothing about why it says it.
Both are the same underlying mistake: treating the conversation as if it were memory. It isn’t. It’s a working surface that gets erased.
within a session
- window compacts
- summary drops specifics
- constraint vanishes
between sessions
- session starts cold
- nothing durable persists
- the why is gone
What actually disappears
It helps to be concrete about what you lose, because “context” is too vague to defend against. When a session compacts or ends, the things that reliably evaporate are:
- Decisions and their reasons. Not just what you chose, but what you rejected and why. The rejected option is the expensive knowledge, and it’s the first thing a summary throws away.
- Invariants. The things that must stay true. “Never block the main thread here.” “This table is append-only.” An agent that can’t see the invariant will break it and pass its own review, because from inside the window there was no rule to violate.
- The negative space. Edge cases you agreed to handle, scope you agreed to leave out. Absence is impossible to reconstruct from a diff. Nobody can look at code and see the case it was told not to worry about.
- The thread of intent. Why this task exists, what behavior it’s meant to install, how it connects to the thing three tasks over. This is the first casualty of a cold start and the hardest to rebuild.
Notice none of these are the code. The code is the one thing that survives by default. Everything that gives the code meaning is exactly what gets lost.
Why a bigger window doesn’t save you
The obvious answer is a larger context window, and it helps at the margin, but it doesn’t solve the problem, for two reasons.
First, more window is more room to fill, not a guarantee of keeping the right things. A long enough run compacts eventually regardless of window size, and when it does, the same lossy summarization decides what to keep. A bigger window postpones the loss. It doesn’t change its character.
Second, and more fundamental: the window is per-session. It cannot carry anything across the boundary where a session ends and a new one begins. Between-session loss is not a capacity problem. No window, however large, persists after you close it. This is the argument I made at length in context engineering for coding agents: the useful move is not stuffing more into the window, it’s being deliberate about what enters it and what survives outside it.
The fix is to stop using the chat as storage
The durable things, decisions, invariants, intent, have to live somewhere that isn’t the conversation. That’s the whole move. Everything else is detail.
Concretely, that means a decision gets written down when it’s made, in a form a future cold agent can load, not left implicit in a transcript nobody will reopen. It means invariants live in a rules file the agent reads at the start of every session, not in your memory of having said them once. It means the intent behind a task travels with the task as an artifact, not as your recollection of a chat.
This is exactly what memory for coding agents is about: deciding what should persist outside the chat, and in what shape. Context loss is the disease. Deliberate, external memory is the treatment. The two articles are the same problem viewed from the wound and from the cure.
There’s a product-side version of this too, and it’s worth seeing the parallel. Teams lose the same things between people that agents lose between sessions: the reason for a decision, the constraint someone knew and never wrote down. That is product memory, what a team forgets and the system shouldn’t. The answer is the same in both cases, a system that remembers on the team’s behalf, which is the idea behind the product brain that maintains itself. Human forgetting and agent context loss are the same failure at two scales.
What good looks like
You’ll know you’ve fixed it when a cold session isn’t a cold start. When you open a new agent on a project and it loads the decisions, the invariants, and the current intent before it writes a line, because those things live in the repo and the model reads them, not in a chat you closed on Tuesday.
That doesn’t happen by accident, and it doesn’t happen by prompting harder each morning. It happens by refusing to let durable knowledge live in an ephemeral place. The chat is where work happens. It is not where memory lives. Keep those two straight and the productivity tax quietly disappears, because you stop paying for the same decisions twice.
That refusal, made systematic, is a large part of what it means to stop being the runtime by hand. And it’s why running several sessions in parallel only scales if each one can load the shared context on its own, instead of routing every remembered fact through the one human who was there when it was decided.
How much of your first hour with an agent goes to re-explaining what it should already know? Tell me on the forum.
Frequently asked questions
Why does my AI coding agent lose context between sessions?
Because the reasoning lived in the chat, and the chat is a working surface that gets erased. The code survives as a file; the decisions, invariants and intent behind it don’t, unless they were written somewhere durable. A new session starts cold and knows what the code says and nothing about why it says it.
Is losing context mid-session the same as losing it between sessions?
No, and they need different fixes. Within a session, the window fills and compaction summarizes lossily, dropping the specifics you cared about most. Between sessions, nothing carries over at all, because the window is per-session. One is a compression problem, the other is a persistence problem.
Will a bigger context window fix context loss?
Only at the margin. A larger window is more room to fill, not a guarantee of keeping the right things, and a long run compacts eventually regardless of size. More fundamentally, the window is per-session: no window, however large, persists after you close it. Between-session loss is not a capacity problem.
How do I stop re-explaining the same decisions to a coding agent?
Stop using the chat as storage. Write decisions down when they’re made, keep invariants in a rules file the agent reads at the start of every session, and let a task’s intent travel with it as an artifact. When those live in the repo instead of a closed transcript, a cold session stops being a cold start.