I wanted a solution checked in one project to remain useful when I moved to another project with a different agent. The useful part was the reasoning: what failed, what was checked, and which conditions could change the answer.
In the first article, I described how Research Brain turns research and checked project findings into a local wiki. This time I wanted to test the next step: could another agent recover that knowledge and use it in real work without inheriting the earlier conversation?
Key takeaways
- Fresh Claude Code, Codex and Copilot sessions read the same saved notes through MCP. They did not need the earlier conversation.
- In a separate comparison of four tasks, neither direct reading nor MCP added a distinct decision or check to the adopted fixes. Direct reading supplied reminders; MCP returned no candidates.
- Before building more retrieval machinery, check whether reading a relevant note changes the work at all. A shared library and a useful consultation are different results.
Jump to: Shared setup · CI case · Four-task comparison · Next test
Shared records, separate conversations
A project still needs its own instructions and architecture decisions. Research Brain keeps reusable notes with the problem, response, sources, checks, conditions and open questions. The notes are Markdown files in a local Obsidian vault.
An optional adapter exposes two read-only tools through the Model Context Protocol, or MCP. search_knowledge returns candidate notes; get_concept opens a selected record. Each client starts its own local adapter process against the same files. Conversation histories remain separate. The adapter guide explains the connection and its limits.
The diagram shows access to shared records. Whether a record changes the next task is a separate question. Saving uses a separate owner-approved workflow.
For the first trial, three fresh command-line sessions received the same continuous integration (CI) and deployment-review task in separate copies of one project's starting state. Each was asked to consult Research Brain, without note identifiers, prepared queries or earlier answers. They used the same nine-note private test vault, including five records from earlier GitHub Actions and Vercel work elsewhere.
The tool logs confirmed that all three read notes before editing. They kept their normal instructions and used different models and permissions. Claude reached its turn limit after preparing a patch and report; Copilot needed a reporting continuation after its time limit; Codex completed, with sandbox-related test failures checked separately. This established three working client paths through one task, not a ranking of the clients.
What the CI lesson helped us check
One CI case shows the gap between reading a lesson and using it correctly:
- The saved lesson. A job had been cancelled near its configured time limit. That duration did not show when it would have finished. Choosing another cap required checking completed runs, interrupted work and signs of progress in the current environment.
- The new proposal. After reading the note, two agents still proposed a 15-minute cap based on local test durations plus headroom.
- The review. The current project had no hosted timing observations to justify that cap, so review rejected the proposals. The earlier reasoning was available; it still needed to be applied to the current evidence.
A separate CI decision concerned cancelling older validation runs. It needed its own policy check. The selected patch grouped runs by workflow, event type and ref, allowing a newer run in the same group to cancel an older one. GitHub documents the interaction between grouping and cancellation in its concurrency guide. This policy suits a workflow where superseded validation may stop; it would need reconsideration if every run must finish.
Existing triggers and validation steps were preserved. Local tests, health checks and lint passed after integration. No hosted Actions run was started during the trial, so neither actual cancellation behavior nor CI-minute savings was measured.
The deployment review needed the same care. A Vercel CLI-upload remedy did not justify upload-setting changes for a project documented to use GitHub import. Copilot also dismissed retention on that basis, but Vercel's retention documentation includes Git branch deployments. Retention settings were left alone because no current retention problem had been established.
The records made earlier sources and checking questions available in another client's work. Review still had to correct their interpretation. This trial had no equivalent run without memory, so it could not show which decisions the agent would have reached anyway.
Comparing consultation with ordinary project work
To examine that gap, I compared four real unfinished tasks across two projects. For each task, fresh agent contexts produced plans under three conditions: current-project evidence alone, direct access to the same approved notes, or access through the existing MCP tools. The agents did not see one another's answers. Their plans were frozen before each fix was implemented and checked once.
The available bank contained 21 concept notes. Here is what each condition produced across the four tasks:
| Access to knowledge | Observed result |
|---|---|
| Current project evidence only | The plans already identified the core repairs. |
| Project evidence plus direct note access | Nine note reads supplied reminders about boundaries and checks. |
| Project evidence plus MCP | Five searches returned no candidates. No notes were read. |
The core repair plans were compatible across all three conditions. Review found no additional decision or check from either way of consulting memory in the adopted fixes.
One task made the result concrete. A check on timestamp-bearing entries lived inside a sort comparator. With a single entry, the comparator might not run, so an invalid value could escape the check. The plan based on project evidence alone already identified input validation before the sort. The notes reinforced that reasoning without adding a step to the fix.
These four tasks came from already localized defects, and their briefs often pointed toward the mechanism. The contribution review was not blind. How consultation would perform on less localized or history-dependent work remains open.
What consultation cost in this comparison
Four tasks under three conditions produced 12 fresh plans, with no plan retries. The recorded effort was:
| Mode | Median plan time | Total input / output tokens |
|---|---|---|
| Project evidence only | 68 s | 643,557 / 6,999 |
| Direct note access | 92 s | 954,030 / 8,814 |
| MCP | 74 s | 659,785 / 7,461 |
The MCP condition returned no candidates, so its shorter planning time than direct reading does not show efficient use of knowledge. These small-sample timings do not establish a speed advantage. Implementation, full review effort and historical capture and maintenance costs were not measured by condition; no end-to-end savings can be inferred.
A pause to check the direction
We kept working on search, but one question kept coming back:
Were we drifting from useful work into infrastructure again?
By then, the conversation included semantic search, summaries, knowledge graphs and increasingly detailed rules for transferring a method. These were relevant engineering questions. I kept returning to the original purpose: recover something useful when another project needs it.
I had also asked for an approach that could work on new tasks and be useful to other people. A better answer to a familiar test query could help diagnose a search defect. It could not, on its own, establish the value of the memory. The ordinary-work comparison gave us a way to ask what a note actually changed.
Four questions I now keep separate
A stored record can be missed. A retrieved record can be inapplicable, or repeat something the agent already knows. Those are different outcomes, even when the task is eventually solved.
I now check the path in four stages:
| Question | What would count as evidence? |
|---|---|
| Does the library contain something useful? | A passage supplies a method, a concrete partial procedure or a relevant limit. A related topic alone is insufficient. |
| Did the agent find and read it? | Actual tool requests and returned content, including misses. Knowing the note's path afterward does not count as discovery. |
| Does it apply here? | Part of the task matches the source procedure and its conditions. Work that the note does not cover stays explicit. |
| Did it change the work? | The fix uses a fact, decision or check from the note that the initial plan did not contain. |
A partial procedure can be useful without solving the whole task. A restriction can prevent an unsupported claim without providing an implementation. I keep those contributions separate from a complete method, and from general reminders.
These trials used different small knowledge banks and different protocols. Their counts cannot be combined into a general accuracy rate.
Why keep developing this workflow?
Shared notes through MCP are already an established idea. Basic Memory offers a Markdown knowledge store for different clients. QMD offers local document search through both a command line and MCP. They are relevant alternatives to compare; these trials do not establish that my implementation is better.
Research Brain grew from a research wiki I was already developing. I wanted a project finding to retain its source, checked result, conditions and open questions, then become available elsewhere through an approved save. Building that path let me inspect capture, retrieval and later use together. For someone starting with the same need, I would include existing tools in the comparison before building a custom reader.
Conclusion
The shared library worked across three clients. The four-task comparison also gave me a reason to keep consultation optional: the agents could already diagnose those localized defects from the projects themselves.
I would carry three lessons into another attempt:
- Save what is hard to reconstruct. A rejected remedy, the reason for an exception, or a checked project constraint may carry more distinctive information than generic coding advice. That is the next hypothesis to test.
- Keep a plain-reading comparison. If reading the relevant note changes nothing, reconsider the knowledge or the task before tuning search. If it does help, check whether normal lookup can recover it.
- Keep the evidence available. The receiving agent still needs to check conditions in its own project. Retain the source, the actual passages it used and what needed another check.
Some of the search work answered engineering questions without answering the larger question of usefulness. I do not want to turn every retrieval miss into a reason to add another component. The practical outcome so far is a working access path and a clearer decision about where to look for value, rather than a reason to require memory for every defect.
What's next
The useful test now is narrower: can a fresh agent recover a past project decision that the current code does not explain, and use its limits correctly? That would test the part I wanted to preserve from the beginning.
Choose the real task before consulting the notes, and keep the agent's initial plan. Let a fresh session search without the desired note identifier. Record which decisions and checks change, what needs local verification, and the effort of consultation and maintenance. If ordinary project inspection already supplies the answer, keep that outcome too.
The public Research Brain repository includes the adapter, a record template and the approved saving workflow. It does not reproduce the private trials described here. New project findings remain outside retrieval until their exact proposed package is approved. Choose which clients and projects may access a vault: retrieved text can reach a hosted model, and source content remains untrusted input.
Top comments (0)