I asked the agent whether this post was ready to publish. It checked the memory setup and came back with conversations from June.
It is September. A fair amount has happened in between. Some of it is the reason I am writing this post.
The search had found text about memory and persistence. The results had sources and dates attached. What they did not establish was which parts of that work were running here now. I had asked for a check of the current setup, and the agent had found a place to begin looking.
That is a useful example to walk through. I want memory to save me from explaining the same decisions every time I open a task. I also want to avoid paying an agent to carefully reconstruct a system I have already replaced.
What survives a session
There are several places to keep things in my setup. Drafts live in Eden as Markdown files. The coding tools keep session histories. Vesper’s memory system provides shared memory and code search, backed by a database outside the model session.
The model gets some of that information in its current context: the text and tool results available for the answer it is producing. Closing a session does not necessarily delete its transcript. Compaction does not necessarily erase the original conversation either. The problem is that a later model call does not automatically receive everything the previous one saw.
A transcript can sit safely on disk while the next agent has no idea which part of it would help. Persistence keeps the material available. Retrieval gets a relevant portion back into the work.
I have already written about the earlier memory system. Much of that layer has since been retired. The old posts still explain what I built and learned. Here I am describing the shared memory system V uses now.
Follow the search result
The agent searched the shared collection for records about persistent memory and project-specific sources, requesting two results.
V’s memory system supports keyword and semantic search. Keyword search helps with an exact name or error. Semantic search helps when the question and the stored explanation use different words. Either can return something relevant that still needs checking.
In this check, the two results were coding-session transcripts labelled 18 and 19 June. The response included a source identifier, a document location, an excerpt, and a date associated with each record. Those dates came from the filenames. They were enough to show which conversations had been found; they were not proof that the described features remained current.
The search also labelled the matches as weak semantic evidence. I would rather have that qualification than a result that quietly turns a resemblance into an answer.
At that point, the agent could use the document location to read more of the old conversation. To check where V’s memory is stored now, it read the configuration on disk and confirmed a database backend. That check answered a narrower question. It did not certify every integration mentioned in the June transcripts.
This is the route I want an agent to take with remembered information: find the candidate, read enough to understand its scope, and check the current source when the next action depends on it. When I know which project I am working on, I ask for that project's source rather than beginning in the shared collection.
An old result does not need deleting
The June transcripts can stay. They may explain a design decision or a problem that comes back later. I do not need to remove a conversation because it failed to answer this particular question.
I do need the agent to stop short of turning it into a current instruction.
An old note might describe a temporary workaround. A newer configuration might make the workaround unnecessary. A task can use the old note to understand the history, then follow the current configuration. If the two disagree and the cause is unclear, that is something to investigate before editing files.
There is no automatic expiry demonstrated by this example. The date helped the agent recognise a limit in the evidence. It still had to choose the next check. Search did not decide on its own that a memory had finished being useful.
The same restraint applies to writing new memory. I want durable decisions and reusable fixes kept with their project and rationale. The rest can remain in a transcript or a task report. Looking up an old note should not, by itself, rewrite it or promote it into a rule for future work.
A request that lasted longer than the conversation
The return posts gave me a small practical example of persistence outside search.
I asked for my post and Vesper's to go out a day or two apart. The publication task kept a separate release record with the selected drafts, the first post's verified publication time, and the earliest time for the second. A later run could read that record and decide whether anything was due.
Once both posts were verified live, it recorded completion and paused the automation. An older message saying “waiting for Vesper's post” could still exist in the conversation. The completed release record supplied the answer to whether there was more publishing to do.
That record was a file used by the publishing task. It did not require a semantic search or a new permanent memory about my preferences. It needed to stay available until the next run, and it needed to say which action had already happened.
This helps when I have several things open. A worker on an unrelated repository can retrieve the project's conventions while the publishing task keeps its own dates and status. They do not both need the entire conversation. They still need explicit ownership when both want to edit the same file; shared memory does not resolve conflicting writes for them.
For this post, I have kept the old search results as history, used the current configuration for the database claim, and corrected the sentence that said a session ending made its contents disappear. The transcript can survive. The next agent needs a way to find the relevant part and check whether it still applies.