What an agent remembers between sessions
Dennis Zaiser, technical founder
Close a session with a coding agent, open a new one, and the agent knows nothing of what you did together. Not the decision you reached after a long afternoon, not the approach you tried and dropped, not the reason the obvious fix was wrong. The model is the same; its context is empty. What carries over is exactly what someone wrote down and what the new session is handed. Getting that right is most of what people mean when they say an agent has memory.
A session's context is its only memory
A coding agent works from its context window: the instructions it was started with, the files it has read, the commands it has run and everything you have typed. Nothing in a session changes the model itself. When the session ends, the window is gone, and the next session starts from its instructions and whatever it is told to read.
Transcripts are usually kept on disk, but a new session doesn't read them unless someone points it there, and even then a transcript is a poor source. It is long, it holds every dead end beside the answer that worked, and it records questions as faithfully as conclusions. An agent that reads one has to work out again which parts still hold.
Long sessions add a second gap. When the window fills, the agent compacts: it summarises the conversation and continues from the summary. The summary is written in a hurry by the agent itself and keeps what seemed important at that moment. Reasoning that was never written down anywhere else is the first thing to thin out.
What gets lost, and why it costs more than tokens
Three things go missing most often. Decisions and their reasons: without the reason, a choice that looks odd gets reversed by the next session, which means well. Failed attempts: the agent tries the approach that failed yesterday, and it fails for the same reason. Conventions: where things go, what things are called, which helper to use. Without them the agent invents its own, and the codebase drifts.
Re-explaining costs time and tokens, but the larger cost is quiet regression. Nobody notices that a constraint was dropped until something breaks that was fixed before.
Remembering wrong is worse than forgetting. A note that says “ask before starting the migration work” outlives the reason it was written, and ready work sits idle. A note that says a function lives in one module survives the refactor that moved it, and the next session edits the wrong file with confidence. Memory that isn't kept true becomes an instruction to make mistakes.
A transcript is not a memory
It is tempting to solve this with storage: keep everything, index it and let the agent retrieve what it needs. Published benchmarks of memory systems on coding tasks point the other way. Handing an agent raw past trajectories, or letting it pick its own past context, often scored no better than giving it no memory at all.
What helped was short, curated experience: a distilled lesson with the evidence it rests on, checked before it was handed over. One well-chosen item tended to beat several loosely relevant ones, and the most common way retrieved memory hurt was its form: long, vague or misleading text that sent the agent the wrong way.
So the work is curation, not capture. The useful question at the end of a session isn't what happened. It is what the next session must know, and where it will find it.
Write the decision, not the conversation
The practice that works is plain. Durable things go into the records they belong to at the moment they happen: a decision into the plan or design doc it changes, with its reason in one line; a deferred option into a tracked issue, with what would trigger a revisit; a convention into the rules. The record is where the next session meets it, because that is where the work is.
At the end of a session, write a handoff: what is decided, what is in flight, what to do next, and which records hold the detail. Rewrite it in place rather than appending to it, and keep it to about a page. A handoff that grows into a log is a transcript again.
A good test: if the handoff were lost, could a fresh session continue from the records alone? If not, something durable is living only in a note.
The same test tells you when to start fresh and when to compact. If the records and the handoff hold the state, a fresh session is cheaper and starts clean. If the next step leans on reasoning not yet written down, write it down first, or compact and accept what the summary loses.
Memory has to be kept true
Everything an agent remembers goes stale at some rate. Code moves, decisions get reversed, a rule is replaced. A remembered claim should carry what it rests on and when it was last checked, so that a change to the code or the decision it depends on flags the claim instead of leaving it quietly in place.
Forgetting matters as much as recall. Remove what is done. When a note and a record disagree, the record wins and the note is fixed. And be careful who approves what becomes durable: an agent that writes its own memories and accepts them is checking its own work. A person, or a check that runs, should accept a lesson before other sessions rely on it.
Where ctxflows fits
ctxflows is the context layer and the workflows for agent-built software, and what an agent remembers is the context half, kept across sessions. On the Memory & search page: decisions, items, runs and the history of every change outlive the session that made them. A knowledge graph links them and flags a link when what it relies on has changed. Search finds them by meaning, or by exact text and names.
In practice, a new session asks over MCP why an approach was chosen and gets the decision, the item it belonged to and the run that built it, instead of a transcript. Workflows add a context step before each node, so a session starts with the rules and records its task needs. Datasets keep what runs write for the runs that follow, such as a ledger a scheduled workflow reads each morning.
What is remembered is the record of what the product must do and why, not a copy of your repository. Your code never enters ctxflows.