Hi! There were more useful sources than I could read carefully. Saving every promising link would only move the pile into a reading list. I wanted to choose what deserved attention and keep the ideas I would need again.
That raised another question: when I returned to a problem, what should I be able to recover from my own research? A useful note would give me the idea, the source behind it, and enough context to judge whether it applied to the task in front of me.
This became Research Brain: a workflow for collecting material, turning selected sources into linked notes, and consulting those notes later. I wanted that knowledge to be available in other projects, where my agent and I were making development decisions.
From a research wiki to a working workflow
I started by trying Karpathy's LLM Wiki pattern and an Obsidian setup using the Model Context Protocol (MCP). They gave me a starting point: keep research in a wiki that an agent can maintain and consult.
I judged the result by whether I could reuse what I had learned. For that, I needed rules around the wiki: how a source gets in, what evidence a note retains, when it needs another check, and what the agent may change. I also needed to notice when collection or delivery failed. Working through those requirements, and fixing what failed in practice, shaped my own implementation.
The knowledge store is an Obsidian vault—a local folder of Markdown notes. A concept note keeps an idea together with its sources, limits, and open questions. I can read and edit those files directly; the optional MCP adapter lets an agent in another project retrieve them. Source collection and the configured model can still use external services.
The digest and the adapter serve different moments in the same workflow. The digest surfaces new material and note updates for reading; retrieval brings existing notes into a current task.
How material becomes a note
The full workflow runs inside an agent runtime. It collects candidates from configured sources, including feeds, official pages, and search results, then selects material for the configured topics. URL and text deduplication reduce repeated material before it moves further through the pipeline.
Before the agent curates or synthesizes article text, a sanitizer removes known prompt-injection patterns and flags others. Curation then applies the topic's inclusion and exclusion rules and a minimum text length. The selected material becomes the input for synthesis into concept notes.
The full agent workflow supports reading and reuse. The reduced RSS-only fallback builds a digest without synthesizing concept notes.
These steps filter different kinds of problems. A duplicate is repeated material. An off-topic article does not belong in this collection. A hidden instruction should not become a command to the agent. None of those checks establishes that an article's claims are true.
The security boundary also continues after ingestion. The MCP adapter labels retrieved notes as untrusted data and exposes read-only retrieval, with no shell or arbitrary-file tool. Filters can miss attacks; the connected agent still needs appropriate tool permissions. This follows the concern described in OWASP's guidance on indirect prompt injection: instructions can arrive inside material the agent was only meant to read.
To check the facts, I need the source trail to survive synthesis. Notes carry source records, and a mechanical health check flags missing citations, broken links, and other maintenance issues. Several publishers can repeat one upstream story, so counting sources is not enough to establish independent confirmation.
Asking the notes from another project
Once the notes existed, the next step was to make them available where a question arose. The local MCP adapter provides two tools: search_knowledge finds candidate notes, and get_concept opens a selected note in more detail.
The current search uses weighted word matches. It breaks the query into words, removes common English query words, and checks the note's title, filename, tags, vault-index context, and body. An optional topic filter narrows the candidates; problem-and-solution notes can also be filtered by programming language and problem type. Title matches count more than body matches; the adapter returns up to two notes with excerpts, recorded sources, freshness information, and open questions.
The search finds candidate context. The agent still has to decide whether that context supports the current task.
There are no embeddings or semantic search in this adapter. Freshness is reported from the note's recorded verification date and review interval; it does not improve the match score or certify that the source is still correct. Generic words can produce irrelevant hits, and a useful note can be missed when the query uses different wording.
When the vault has no useful answer, I want that gap to stay visible. In vault-only mode, the lookup stops and offers further research. In research mode, it tells the host agent to carry the retrieved context and gaps into the existing research workflow: check local material first, then ask before external research. The MCP server itself does no web research. Project findings go through a separate write workflow with explicit approval; the weekly workflow can ingest eligible research notes unattended.
Closing the loop between projects
Retrieval left another question open: could a solution found during project work become useful knowledge for the next project? I tested that path with an agent on real unfinished tasks, using a private evaluation vault.
In the first project, an HTTP collector ignored the server's Retry-After hint and used its fixed retry delay. The agent checked RFC 9110, section 10.2.3 and corrected the retry loop: wait the full requested pause when it fits the local budget, otherwise stop. Offline regression tests reproduced the problem and passed after the change.
The agent then prepared an update to the existing note. It kept the problem, the rule and source, the checked result, and the conditions another project would need to reconsider. I approved the exact change before it entered Research Brain. Saving used a separate reviewed workflow; MCP remained read-only.
From a second project, the agent retrieved the saved note through MCP. That collector shortened server pauses to its own limit and used a total deadline rather than the first collector's cumulative sleep allowance. The note supplied the rule and questions; the agent still had to inspect the local code, clocks, error handling, and callers. It adapted the fix and checked it with offline regressions. The result was then proposed back to the note and saved with my approval, including the remaining limits.
Project findings use a separate write workflow. Reuse can lead to another proposal; each save needs direct owner approval.
This completed a coordinated loop of saving, reuse and another approved update. The agent kept earlier context, and the faults were chosen before lookup. Offline tests used simulated responses and clocks. They did not test discovery by a new agent, automatic note synthesis or live traffic. They also did not show that separate jobs would respect the same wait, or that the changes were ready to release.
When the notes did not help
A school-class comparison task gave a different result. The agent queried a separate working vault of 39 notes. Broad wording returned unrelated matches; a more specific admissions query returned nothing. The agent set those results aside and completed the change using the project's own rules and retained data.
Matching familiar words could make irrelevant notes look promising. Improving retrieval and growing useful coverage are both necessary; one does not automatically solve the other.
What I would keep testing
What I found useful was having sources, limits, and questions for further checking together. These recorded trials do not establish time savings or better decisions. The longer-term question is whether recurring collection and retrieval justify the effort of preparing, verifying, and maintaining the notes.
For someone trying the idea, I would start with one recurring question. Keep a note with the rule, its supporting source, and the conditions that could change the answer. When the question returns, check whether the note helps you decide what to inspect next—and count the effort needed to verify and update it.
The public Research Brain repository now includes the project-solution capture workflow, its record template, and tests alongside collection and retrieval. The problem-and-solution guide explains how to validate a finding, review the exact proposed change, and save it after direct owner approval.
A disposable synthetic example exercises saving a finding and retrieving it from another project. It checks the workflow, not the private application runs described here. The MCP setup guide covers connecting the adapter.
When you return to something you researched earlier, what do you usually have to reconstruct?
Top comments (0)