The other day the Brain said something like, "Over the last month, we have been..."
My wife asked how it knew that.
The answer was immediate: was the response related to something she had been working on at the time? Yes.
The Brain had found the relevant memory and included it in the request. The model could talk about the ongoing work because the application had given it the right slice of history.
That is the other side of the memory story. A model cannot act on a preference that never enters its context. It can sound remarkably aware when retrieval does find the context that applies.
The model did not discover a hidden past
The previous article explained why a stored preference can be absent from a later response. Storage alone does not change what the model sees. Retrieval and prompt assembly carry the stored fact into the current request.
The successful case follows the same path.
The model received the current question alongside a compact set of memories about the work in progress. It had enough evidence to connect "over the last month" to the active project, recent decisions, and the thread of work the user was continuing. The response felt like recall because the context had been assembled well.
The model itself had no private view of the full memory archive. The application did the work of locating the relevant material first.
flowchart LR
Request[Current request about active work] --> Retrieve[Retrieve relevant memory]
Store[Memory records] --> Retrieve
Retrieve --> Context[Compact context for this request]
Context --> Model[Local model]
Model --> Answer[Response about the ongoing work]
That boundary is worth keeping clear. It makes a correct response easier to trust and an incorrect response easier to investigate. The system can show what was retrieved, why it was selected, and which facts actually reached the model.
Reranking made the earlier system useful
The earlier memory path relied on reranking.
The system gathered candidate memories, compared them with the current request, and ranked the candidates by relevance. A record about the project the user was currently discussing rose above older or unrelated records. The top results entered the context window. The model then had enough information to make the connection.
Reranking is a practical way to work with a memory store that is mostly prose. It can recognize that two descriptions concern the same project even when they do not use exactly the same words. It can distinguish an active task from an older discussion that happens to share a term.
That capability is useful. It also asks a model-shaped component to infer relationships that may already exist in the system as explicit structure.
For example, a current request may concern a file, symbol, branch, task, or dependency. Those are not vague semantic relationships. The system can often name them directly.
Syntax turns part of retrieval into a graph walk
The memory system now uses AST and syntax-based relationships alongside reranking.
An abstract syntax tree gives the system a structured view of source code: files, symbols, imports, references, calls, and declarations. Syntax-aware analysis can connect a current edit or question to the code around it. Those relationships create a graph that can answer concrete questions without asking a language model to infer everything from text similarity.
If a user is working on a function, the graph can find its file, callers, imports, tests, related symbols, and nearby decisions. If the current task is attached to a project or branch, those links can narrow the search further. The retrieval system begins with a smaller and more relevant candidate set.
flowchart LR
Request[Current request] --> Scope[Identify project, file, or symbol scope]
Scope --> Graph[AST and syntax graph]
Graph --> Candidates[Structurally related memories and code]
Request --> Rerank[Rerank for language and intent]
Candidates --> Rerank
Rerank --> Context[Selected context]
Context --> Model[Local model]
Reranking still has an important job. It can decide which of several related records best answers the human question. A graph can establish that a test is connected to a symbol. It cannot always decide whether the user wants the implementation detail, the historical decision, or the operational warning. Language and intent remain part of retrieval.
The combination makes the system more disciplined. Structure narrows the search. Reranking chooses among the candidates where semantic judgment adds value. The model receives a shorter, more coherent context.
Faster retrieval changes the interaction
The hybrid path seems faster and more accurate because it avoids treating the entire memory store as an undifferentiated pile of text.
The graph can remove distant candidates before reranking starts. That reduces the amount of text that needs comparison and lowers the chance that a broadly similar but irrelevant memory wins a high score. The resulting context also uses fewer tokens, which leaves more room for the current request and the response.
Accuracy improves for a different reason. Structural relationships are stable. A symbol reference, file ownership boundary, and dependency edge mean something specific. They give retrieval a reliable starting point before language-level similarity gets involved.
The claim needs measurement, not folklore. The system should retain the candidate set, graph edges, reranker scores, selected memories, prompt budget, latency, and final answer. Those records make it possible to compare the hybrid path with reranking alone on the requests people actually send.
A response like "Over the last month, we have..." is a good anecdote. It is also a useful test case. Did the selected context contain the relevant work? Did the model summarize it accurately? Did unrelated history enter the prompt? Was the answer faster than the earlier path? The system can answer those questions when retrieval is observable.
Memory starts to feel reliable when it has structure
People naturally treat a response about ongoing work as evidence that the model knows them. The feeling is understandable. The useful technical explanation is more grounded.
The model received the current request plus a small, selected record of the work that mattered. A retrieval system found that record by combining explicit code structure with language-level relevance. The model then did what it is good at: reading the assembled context and producing a coherent answer.
That is enough to make a local system feel continuous across days and projects. The continuity comes from durable records, explicit relationships, disciplined retrieval, and a prompt assembly path that can be inspected when it gets the answer wrong.
The one-line version
A model can speak accurately about ongoing work when retrieval finds the right evidence, and AST plus syntax relationships give reranking a better place to start.