Hi!
An agent was preparing a report about contact details that needed another review. The initial plan already separated an overdue review from a wrong phone number. A saved note confirmed that distinction, but did not add a new step.
That made me ask a more useful question: when an agent finds an old solution, what does it actually add to the current work? I explored that question across several project tasks using notes from a shared knowledge base.
In the previous article, I described how different agents can access those shared notes.
The short version
- In one task, a note confirmed a useful distinction, but the initial plan already included it.
- In another, the search returned two notes that did not fit the task.
- In a separate comparison, a related note prompted one agent to propose an extra check. I supplied the link manually, so this was not a test of automatic discovery.
- These small cases do not establish how often memory helps, or whether it saves time.
The experiment
I used Research Brain, a local collection of notes that agents can read through the Model Context Protocol (MCP). Each note can contain a problem, an approach, sources, and conditions for use. The public repository includes the project and the MCP adapter. The private trials in this article are not included.
For the next checks, I looked at real work across different projects. Some tasks led to code changes. Others asked for an investigation or a plan. I kept those outcomes separate: a useful suggestion is not the same as a tested implementation.
I also tried comparing work with only project files, with direct note search, and with MCP. In one small comparison, three fresh agents considered two tasks. The agents proposed recommendations, but did not implement the fixes. On those tasks, memory did not show a distinct contribution to the proposed solutions.
That result mattered. I wanted to see where the memory helps, not only whether an agent can open a note.
Case 1: A useful warning I already had
One task concerned a help page with contact details. The project recorded when each contact source was last checked. The unfinished task was to flag sources that needed another review after about 90 days.
The initial plan already treated missing dates as unknown. It also noted that an old review date does not prove a phone number is wrong.
Research Brain returned a note about keeping an overdue review separate from its cause. It supported that distinction. The search also returned an unrelated note about authorization, which I did not use.
The task resulted in a local report that lists review dates and marks records due for checking. The report does not contact the sources or claim that a number works. Focused tests passed; the full project type check did not pass because of errors in generated files.
The note confirmed the warning already present in the initial plan. It did not add a new decision, so I cannot count this as a time saving or as proof that memory solved the task.
Case 2: Search returned the wrong neighbours
Another task concerned events collected from several sources. The open question was how to handle source priority and keep the original evidence when records are combined.
The MCP search returned two notes. One concerned navigation state. The other concerned resource cleanup. Neither provided a method for merging event records or choosing between sources.
I did not use either note as a solution. I also did not establish that a suitable solution already existed in the knowledge base. A wrong result and a missing result need different fixes.
This was a useful outcome even though the search did not help the task. It showed why a related word or a plausible summary is not enough. Before applying a note, I need to see whether its actual operation and conditions match the work in front of me.
Case 3: A useful check from a manually supplied link
A third question was how to evaluate a possible map feature without sending data to an external service. I compared two agents working from the same existing note about checking resources in an offline snapshot. I selected that note in advance. One agent also received a link to a second note about a separate synthetic build.
Both agents suggested testing with synthetic locations and watching browser requests. The agent with the extra note also proposed checking the files included in the synthetic build. The other agent did not name that check explicitly.
That extra check is a concrete idea worth considering. But I had selected the first note and supplied the link manually. The map was not implemented in this comparison. I cannot say that MCP discovered the connection or that the check improved a finished feature.
What I would do differently next time
These cases made me more selective about memory. I do not need an agent to search old notes for every small change. I want it to look when the answer may depend on a previous decision, its evidence, or a limit that the current project does not record.
To try this on your own work, save a short plan before reading an old note. Then record what the note says, check its source and conditions, and compare the plan again.
In the contact example, the result was: the note supported an existing warning; it did not add a new step. Another task may produce a different answer.
This is also useful without Research Brain. A team can ask the same questions when reading an old issue, an internal document, or a past incident report.
Conclusion: keep the result, including the miss
The experiment did not give me a general success rate for shared memory. The tasks were few, the methods differed, and some comparisons were not blind. I did not measure the full cost of the work, so I cannot claim time or token savings.
It did give me a better way to use the notes. I can keep a previous decision and its limits available to another agent. I still need to check whether that decision applies to the current task.
Next, I want to use this approach during normal project work, especially when a task depends on a decision made somewhere else. I will keep recording cases where the memory adds nothing, as well as cases where it helps.
How do you decide whether an old solution fits a new task? What information do you wish your team or your agent had saved with it?
Top comments (0)