Maybe Coding Agents Don't Need a Bigger Memory. Maybe They Need Continuity.
Santi
SubscribeSign in
Maybe Coding Agents Don't Need a Bigger Memory. Maybe They Need Continuity.<br>A practical reflection on why coding agents lose the thread between sessions, and why the repository itself is the right place to preserve it.
Santi<br>Jun 05, 2026
Share
I used to think the problem was memory. That was the obvious diagnosis.<br>Every new coding-agent session started with the same ritual. Open the repository. Read the README. Inspect the project structure. Search for the files that looked important. Reconstruct the task. Guess which commands mattered. Ask again what had already been tried. Then do the actual work.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.
Subscribe
Sometimes.<br>Because a lot of the work was not work. It was orientation.<br>A coding agent can have a large context window and still lose the operational thread. It can have chat history and still fail to know what happened in the last run. It can retrieve semantically similar notes from a vector store and still miss the one fact that mattered:<br>this command already failed.
the previous session stopped here.
this file looked relevant, but it was a dead end.
the validation was not actually run.
One day I stopped thinking about the problem as “agent memory”. That word was too broad. Too attractive. Too dangerous.<br>Because once you say memory, the temptation is to build a bigger one.<br>A bigger context window. A bigger note store. A bigger vector database. A bigger archive of everything the agent has ever seen, said, touched, generated, or vaguely implied.<br>That sounds powerful, but it is also how you build a very expensive junk drawer.<br>Context is not continuity
Context is what the agent has available now.<br>Continuity is what lets the next execution continue from what actually happened before.<br>Those are not the same thing.<br>Long context helps while a session is alive. It gives the model more text to work with. More files. More prior messages. More implementation details. More room. Although it is really useful it does not automatically produce continuity.<br>When the session ends, gets compacted, moves to another tool, switches from one coding agent to another, or simply starts tomorrow from a fresh prompt, the problem comes back, and the same questions are there:<br>What was active?
What changed?
What failed?
What was validated?
What was only assumed?
What did the previous run leave unresolved?
A larger context window can hold more text, but it does not turn execution history into structured project state.<br>The problem is not only loading enough information. The problem is preserving the right kind of information.<br>The wrong abstraction: “remember everything”
The straightforward version of agent memory looks something like this:<br>repository<br>chat history<br>large prompt<br>agent execution<br>summary<br>next large promptIt works for a while. Then it starts to rot.<br>Summaries become too broad and notes become stale. Old assumptions remain mixed with verified facts while failed approaches sit next to successful ones with the same visual weight.<br>The agent retrieves something that sounds related, but nobody knows whether it is current, useful, contradicted, or just a nice-looking hallucination from three sessions ago.<br>This is where “more memory” can be worse than no memory because the agent needs operationally trustworthy information and not only related information.<br>The general idea may be the same, but the difference between a memory item and a continuity record is huge if we talk about usefulness. One is a recollection. The other is a handoff.<br>A memory item like this is weak:<br>We probably fixed the parser by changing the tokenizer.A continuity record like this is much stronger:<br>Task: fix parser edge case<br>Files edited: src/parser/tokenizer.py, tests/test_parser.py<br>Command run: pytest tests/test_parser.py<br>Result: passed<br>Known failure: full test suite still not executed<br>Next action: run full parser test group before extending scope<br>Evidence quality: partialInstructions, vector memory and chat history are not enough
Repository instruction files are useful because they can tell a coding agent:<br>how to run tests<br>which style to follow<br>where the main modules live<br>what conventions matter<br>what not to touchThat is good project context. But instructions are mostly static.<br>They explain how to work in the repository. They do not usually know what happened ten minutes ago.<br>They do not know that a task is paused or that the last validation failed. They do not know that a previous attempt edited the wrong layer. They are not aware of a user interrupted the session and narrowed the scope.<br>A coding agent needs both: stable instructions and changing work state.<br>One without the other is incomplete. They have different job.<br>Instructions make the agent behave better in the repo and Continuity makes the agent continue better in the repo.<br>Vector databases are good at...