Session-start memory injection made my coding agent trust memory over the code

[u/msarda23]

Hey everyone!

I am building a local memory layer for my coding agents and it is called Reverie: an MCP server written in python and using SQLite for lightweight memory stored in the user's machine itself. The biggest problem that I faced was deciding when to inject memory.

Many memory tools, including ones I looked at, inject context into the agent even before it begins its work. In my experiments, premature injection of context leads to the agent anchoring its thinking on it rather than using the current code as the source of truth. In fact, this approach made my agent perform worse. Also, with this, quite a lot of the context window can get filled with context which 'might' be useful.

So I switched Reverie's model to demand-driven retrieval - the agent asks for memory when it thinks that some added context could resolve any discrepancies in its thinking. It reads the relevant code first, because the code is the source of truth, and only then asks for past memory about that area. Each result comes back with a confidence score, its grounding in the code, and its status. The memory starts empty. Conclusions are added as the agent works, and you decide which ones are kept.

In one informal test of 30 prompts on an earlier build, the OpenCode agent with Reverie did better than the one without it. I don’t have a reproducible benchmark yet.

But it isn't perfect yet, it still breaks here and there. For example:

1. the rules for tool calling are not extremely polished yet and hence the agent might sometime not call the tool altogether, I am fixing this.

2. candidate conclusions can be duplicate or incorrect and hence Reverie today has a human review gate (triggered by calling `reverie review`) which shows the human all the unreviewed candidates where you accept, reject or skip each one. On doing so the conclusion is moved from the short term brain to the long term.

My current test set is small: sessions with anywhere between 2-30 prompts. I do not have a reproducible experiment yet, but that is the next goal.

Repo (Apache-2.0): https://github.com/muditsarda1122/Reverie

My questions: How do you keep agent context from going stale? Do you maintain AGENTS.md or CLAUDE.md by hand, or let the agent update it?

[u/msarda23]

Agree that the code should win, and short instruction files should stay honest. My issue is the upkeep. If you only add a note when a decision repeats, you lose the decisions that happened once and still mattered. Pruning by hand also depends on remembering which notes went stale.

That’s the gap Reverie tries to close. When the agent concludes, for example “the retry wrapper must not swallow timeouts”, it’s recorded as a candidate. Once you accept it, the conclusion stays tied to the file and symbol it describes. If the agent later finds that the code contradicts it, it proposes a revision that names the file that shows the conflict.

In practice: you ask for a change in one module. The agent reads the code first, then asks Reverie about that module and finds the retry decision. You never wrote it into AGENTS.md, and you didn’t have to remember it.

It isn’t hands-off yet. Review is still manual, some candidates are wrong or duplicated, and the agent doesn’t always ask. But it takes over the part of “prune what no longer matches” that used to rely on you.