You know the feeling. You've been in the same agent session for an hour. The code works, mostly. Then you ask for one more tweak.
This time it's different. It renames a thing you told it to keep two turns ago. It suggests an approach it already rejected. It breaks a test that was green ten turns back, and then fixes it by weakening the assertion.
The session has rotted.
What's actually happening
It's not that the context window filled up. It's that the agent is now reconstructing decisions from a long, messy conversation instead of working from a stable artifact. Every prior turn is competing for attention: code you deleted, approaches you argued against, a tangent about database indexes that has nothing to do with the file you're touching now.
By turn 15–20, the signal-to-noise ratio in that transcript is bad. The agent starts averaging across contradictory instructions. It remembers the gist of what you said, not the specific constraint. It re-opens settled questions because it sees both sides in the history.
More context doesn't fix this. It just gives the noise more room.
The pattern I've stopped fighting
I used to keep nudging the session: "no, keep the name," "we already decided that," "don't touch that file." Each correction adds another turn the next agent has to wade through. The session gets worse, not better.
Now I cut it. When I feel that re-litigation start, I end the session.
What I do instead
Before closing, I write one paragraph:
- what was built,
- the two or three decisions that actually matter,
- the command that proves it works,
- and the one thing I want next.
Then I open a fresh session and paste that paragraph. That's the entire handoff.
The new agent reads the code on disk, runs the command, and continues. It doesn't carry the argument history. It doesn't re-suggest the approach we ruled out. It works from the current state of the repo, not from the ghost of an hour-old conversation.
This sounds like a small thing. It isn't. The fresh session consistently makes fewer unrelated changes, doesn't re-open settled choices, and runs the verification command without being reminded.
When to actually stay in the session
There's a real cost to restarting: the agent has to re-explore the repo. For a tight, focused task — one function, one bug, one test — the session is fine. Restarting mid-task is its own kind of churn.
The line I watch for is the first time the agent contradicts something it already did in this session. Once that happens once, restart. If it happens twice, the session is already too far gone.
The underlying bias
We treat the conversation as the project state. It isn't. The repo on disk is the state. The transcript is a log of how we got here, and logs go stale.
The cheaper mental model: the agent should read the code and the runnable command, not your chat history. When the history becomes load-bearing, that's a sign the project isn't well-enough captured in the repo yet.
That's the same reason a short AGENTS.md or a runnable test beats a long prompt. The agent's job is to read the current truth, not remember what you argued about.
What's your cutoff? At how many turns do you notice the session going sideways?
Top comments (0)