Turn 10,994 Notes Into Your Agents' Memory

Paul Iusztin spent 18 months turning his second brain into a research memory. He reports more than 5,000 notes in Obsidian, another 5,000 in Readwise, material scattered across Notion and Google Drive, and roughly 250 new files each month. Accumulation was working; bringing the right information into an article, project, codebase, or feature was the harder problem.

The missing piece sits between the archive and tools such as Codex, Claude, or NotebookLM. Saving an interesting X post, article, YouTube video, or GitHub repository does little good if, when work starts, you cannot remember that it exists. Searching manually can recover it, but finding the useful subset takes time. The goal is to retrieve high-signal research for the work in front of you, while preserving the personal notes, values, and taste that made the collection worth building.

That is the purpose of AI Research OS, the system Iusztin and Louis-François Bouchard introduce with accompanying code. Iusztin, founder and CEO of Decoding AI and co-author of The LLM Engineer’s Handbook, uses it in his daily work. Bouchard introduces himself as Towards AI’s co-founder and CTO, the creator of What’s AI, author of Building LLMs for Production, and a former PhD student. His research now feeds courses, videos, company training, and lessons drawn from client implementations. Their workflows differ, so the repository is designed to be adapted to an existing research practice.

A research operating system is unnecessary for many questions. If you need a quick answer—the kind of thing you would otherwise Google—use search or a chat assistant. The extra structure becomes useful when the work requires a long sequence of questions, a growing source collection, and decisions you will revisit.

For a small repository change or a one-off article, Bouchard recommends an agent such as Codex or Claude Code. Persistent research becomes more valuable when the next session must continue improving the same work, refer to previous sources, or digest them more deeply. His video workflow supplies a concrete requirement: a new video should take earlier videos into account, avoid duplicating them, and refer back to useful prior content.

Bouchard finds NotebookLM powerful for digesting research, but describes its browser-based workflow as a poor fit for the agent integration and coding work he wants. A vector-database retrieval pipeline is attractive for production products, yet checking or editing its knowledge by hand requires surrounding infrastructure. For personal use, the desired result is closer to an editable Wikipedia: sources, comparisons, implementation knowledge, and new topics that remain available to other projects and agents. Building that system gives more control, at the cost of more setup than simply opening Claude Code.

Consider the repeated work around a research session. You give an agent links, PDFs, and background material; it creates temporary structure and runs scripts to make sense of them. In the next session, you paste the material again or explicitly ask it to reuse a growing collection of skills. The bottleneck is no longer supplying information. It is preserving enough organization to use that information later.

Without durable storage, the context window is asked to serve as database, filesystem, memory, and reasoning space at once. Ending the conversation breaks that continuity. The proposed remedy is memory and context management built around plain files, mostly Markdown: humans can inspect them, agents can read them, and neither needs the original conversation to remain open.

Bouchard began with a few hundred notes, hundreds of previous videos, and knowledge from team and client meetings. He consolidated Claude Code skills, Granola meeting recaps, Apple Notes, and saved browser tabs into local files viewed through Obsidian. Codex helped configure automatic saving from Granola. Obsidian provides the interface he likes across phone and desktop; the underlying requirement is local files, not that particular application.

The AI Research OS workshop repository packages this workflow as skills and plugins for agent harnesses. Its research tool can begin with a new video topic and draw on local Obsidian notes, Readwise, NotebookLM, GitHub repositories, YouTube links, web pages, and documents. Users install the plugin and tune the sources and behavior to their needs. Bouchard describes adding YouTube transcript support with a single prompt in a few seconds. Beneath those integrations are three durable layers: raw content, an index, and synthesized wiki pages.

The first version had a narrow job: prepare research for lessons in an agent engineering course. Its input was a topic plus manually selected golden links; its output was one research.md file. Scraping the trusted links first gave the system enough context to frame better questions than it could generate from the topic alone.

The research loop then worked in stages:

1. An orchestrator generated questions from the topic and scraped seed context.
2. Separate agents investigated those questions using Gemini grounded in Google, collecting links and executive summaries.
3. The orchestrator aggregated the results into a compact representation before another round of questions.
4. The system ranked discovered sources against the original topic, fully scraped the top K, and retained summaries for the remaining links.
5. It compiled the selected material into a flat research.md report.

Paul reports that three rounds of six queries produced approximately 40–50 links. Ranking mattered because discovery generated enough material to introduce substantial noise; selective full scraping kept that noise from becoming an equally large reading burden.

Paul reports quickly generating 35 lessons with this approach. It served the course workflow, but its useful output was still a static file, and the initial high-quality sources still had to be selected by hand.

The next version aimed the same research loop at the personal archive. A saved collection already reflects choices about what is interesting, trustworthy, or relevant. Searching it lets those choices supply golden links organically, instead of requiring a fresh list for every task. The input can therefore be just a topic, with explicit seed links still available when needed.

The topic seeds query generation, and those queries reach both the second brain and the public web. The described sources include Obsidian, Readwise, NotebookLM, and GitHub; Gemini Deep Research is another suggested extension. Ranking and selective full scraping still follow discovery, and the output is still research.md.

This solves source selection but exposes a different limitation. Research rarely ends when a report is written: another question appears, information becomes stale, or the project needs a different comparison. A flat report does not preserve a convenient update process. Repeating the whole discovery and compilation loop costs tokens and time, so the third version adds a wiki above the research process.

V3 combines deep research with an LLM knowledge base. Sources go in and a wiki comes out. Custom URLs can also enter the pipeline; Paul mentions Bright Data as a way to parse web content, including single-page applications. Instead of folding everything into one report, the system stores source files individually, creates an index, and generates wiki pages above them. Queries can then use both the index and the wiki.

For this lightweight personal system, Paul deliberately avoids making vector databases, knowledge graphs, or dedicated search infrastructure prerequisites. Files and references supply the retrieval structure. The entry point is index.yaml, a catalog containing source summaries and metadata. His displayed catalog contains 10 sources and 38 derivative wiki pages. An entry can identify the original file, origin, title, authors, publication date, and summary; its references lead to raw material and generated pages.

A minimal catalog entry for a sandboxing source illustrates the file-reference mechanism:

sources:
  - id: sandboxing-note
    title: Sandboxing research note
    origin: local-note
    raw_path: raw/sandboxing-note.md
    summary: Notes on sandboxing and its role in an agent harness.
    source_page: wiki/sources/sandboxing-note.md
    derivatives:
      - wiki/concepts/sandboxing.md

The summary helps an agent decide whether the source is relevant. The paths tell it where to read more without embedding the complete source in every prompt. The metadata can grow with the workflow while the basic operation remains following references.

The wiki can contain comparisons, entities, concepts, notes, repository analyses, and open questions the agent could not answer. A repository need not collapse into one summary: it can produce several pages about different architectural concerns. Obsidian can display the connections created by these references. Concept pages might cover a tool registry, context compaction, or sandboxing; entity pages might describe OpenCode, Claude Code, or MCP.

Retrieval follows a hierarchy:

1. Read index.yaml to select promising sources from their summaries and metadata.
2. Open the source wiki page, an expanded executive summary of the underlying material.
3. Follow relevant references into concept, entity, note, or comparison pages if more synthesis is needed.
4. Read the full raw article, paper, or video source when those layers do not contain the required detail.

For the sandboxing entry above, a broad question may be answered by wiki/sources/sandboxing-note.md; a more specific one may require wiki/concepts/sandboxing.md or the raw note. Paul describes this progressive reading as token efficient: the agent can stop once it has enough information instead of repeatedly loading full sources. The talk supplies no measured token reduction.

In the workshop’s design, questions leave a durable trace. A question is logged and can lead to a new concept, note, or comparison page, so the wiki develops through use as well as ingestion. Custom links and additional deep-research rounds supply two other ways to extend it. The resulting collection can reflect both what you have researched and what you have struggled to understand.

This evolving wiki does not sit over the entire personal archive as an unrestricted editing layer. Paul organizes his second brain with Tiago Forte’s PARA method: Projects, Areas, Resources, and Archives. In his implementation, saved notes, PDFs, and articles enter a flat resources collection and are referenced from projects and areas. The global Obsidian collection remains his own material; the LLM does not edit his manually written notes.

A new project draws a relevant subset from that global second brain through research or direct ingestion. Skills inside the agent harness then work with the project’s scoped wiki. The project might be an article, video, slide deck, book, course, or codebase; Paul used the technique to prepare this presentation. The boundary is practical: the second brain holds accumulated research, while the project is where that research becomes work.

The workshop packages the required skills as a Claude Code plugin, with adaptation to other harnesses possible. The repository README covers installation and dependencies, including the service-specific CLIs and authentication needed for personal sources such as Readwise and NotebookLM. The demonstration moves past setup into a prepared article-research example.

The first input is a brain dump for an agentic-engineering article, accompanied by references Paul definitely wants included. He opens a Claude session, invokes the research skill, and points it at the brief. The skill infers the intended topic—agentic harness engineering—and scrapes the supplied references before generating research questions. Paul then enables auto mode, explaining that he trusts this workflow after hundreds of uses; that confidence is specific to his setup, rather than a general safety guarantee for unattended agents.

The next decision is research depth. The skill offers light, deep, and fast settings that govern the number of rounds and questions. Paul generally recommends light or fast because broad research consumes substantial tokens.

Paul selects light and estimates 10–20 minutes to search his Obsidian, Readwise, and NotebookLM sources. When following along with a newer checkout, use its research skill specification: the version inspected in August 2026 instead defines fast as one round of three queries and light as two rounds of three then two queries. It also defaults existing-wiki queries to read-only, with optional save-back, rather than making the workshop’s question-driven updates automatic.

To inspect the result, Paul opens an already generated wiki in Obsidian. It has raw copies, an index, and a graph of linked wiki pages. The source pages contain executive summaries computed during ingestion, so later queries can reuse that work. The derivatives include comparisons such as agentic RAG versus filesystems and compaction versus recursive language models. Concept pages extract ideas from the source collection; the agent-loop page combines explanatory text and graphs. The output is therefore both a retrieval surface for an agent and something a person can browse to learn the subject.

The second example skips discovery. Paul wants to learn how harnesses work by ingesting OpenCode, Pi, and Hermes. The repository-ingestion prompt supplies the selected repositories and explicitly asks for no deep research. Its requested topics are general architecture, agent architecture, subagents, memory systems, and permission flows.

The workflow clones the repositories and investigates those topics in each codebase. First it creates repository-specific Markdown analyses. Higher-level wiki derivatives can then compare the architectures or synthesize recurring patterns across them. This ordering matters: a cross-repository comparison is built above individual repository analysis, so the reader can move between a broad claim and the implementation it describes.

Paul again opens previously generated results. The familiar raw/index/wiki structure remains, with per-repository pages about topics such as OpenCode’s permission flow and memory system. Comparisons expose architectural differences, while concept pages collect the decisions and mechanisms worth understanding. This makes the same workflow useful for learning from existing code before designing a harness of your own.

The third example reduces the input to three custom links. Paul starts a fresh session and pastes a prompt asking the system to ingest them. Neither this example nor the repository example needs an Obsidian, Readwise, or other personal-note integration. As presented, they use the plugin with Git and curl; Obsidian is a convenient viewer for the resulting files, not a required storage service.

The generated wiki still has an index, an executive summary for each source, extracted concepts, and entities. The displayed index is titled “Agentic AI systems: agent memory, agentic coding, and GraphRAG.” This is the smallest entry point into the workflow: ingest a bounded source set, inspect what it produced, and then ask questions that make the collection more useful.

The final demonstration returns to the wiki built from GitHub repositories. The presenter invokes the research skill, points it at that existing wiki, and asks how remote sandboxing works and how it plugs into a harness. The source set is already available, so the new task begins with querying accumulated knowledge rather than repeating repository discovery.

The intended next step is to answer from the wiki and, where useful, create notes, comparisons, or newly identified entities. The recording introduces that query and describes the possible additions; it does not walk through a completed sandbox implementation or a finished answer. The mechanism is the important distinction from a static report: a follow-up can become durable project knowledge instead of remaining only in a conversation.

The project remains deliberately incomplete in places. Google Drive, Notion, and Slack are proposed connectors, not implemented integrations in the workshop account, despite appearing earlier among possible source destinations. The authors had not needed them in their own workflows. The repository’s purpose is personal usefulness and teaching memory and context management, with users adding the connectors their work requires.

A deeper limitation is deciding which sources have become outdated and which are weak or strong. File visibility makes inspection possible, but it does not automatically establish source quality. The system also remains a terminal-oriented builder workflow through Claude Code or Codex, rather than a polished consumer product. That is an intentional scope choice.

The planned improvements address the maintenance burden:

• Stronger linting: improve the checks applied to the growing knowledge collection.
• Better memory compaction: manage accumulated information as the wiki develops.
• Better source provenance: make sources easier to trust, rank, reuse, and assess for relevance.

These are the problems that remain after retrieval works: keeping a living memory coherent and making its evidence understandable to the person using it.

The educational continuation is Agent Engineering: Building Multi-Agent Systems at Towards AI Academy. Bouchard describes a related system with research and writing agents, incorporating further improvements beyond the workshop project. He estimates around 60 hours to complete the course, whose final project is a multi-agent system learners build themselves. The workshop’s files-and-references architecture provides a smaller starting point for the same practical discipline: preserving research so an agent can use it again when the work changes.