Turn 10,994 Notes Into Memory - Paul Iusztin, Decoding AI & Louis-François Bouchard, Towards AI

Paul Iusztin and Louis-Francois Bouchard introduce their innovative AI Research OS, a system designed to transform disparate research assets—notes, documents, videos, and code repositories—into a persistent, personalized memory for AI agents. They emphasize the necessity of such a system to overcome common research challenges and the limitations of existing AI tools.

The Problem: Losing and Managing Research

Paul Iusztin highlights the personal challenge of managing a vast “second brain” with over 5,000 notes in Obsidian, Readwise, Notion, and Google Drive, growing by 250 files monthly. The core issue is retrieving high-signal notes for current work, stating, “I’m always losing my research.” Reading lists become a “graveyard,” and saved content is rarely recalled when needed. Critically, he seeks a system anchored to personal values and thoughts, reflecting his unique perspective. Louis-Francois Bouchard echoes this, emphasizing the need to leverage years of content from videos, meetings, and client work for efficient research and content creation.

Why Existing Tools Fall Short

While tools like ChatGPT, Claude, NotebookLM, or Codex Cloud are useful for quick answers, they are insufficient for complex, long-term projects due to several limitations:

• Context Window Limitations: Agents often lose context when conversations end, treating the context window as the sole memory, database, and reasoning space.
• Lack of Personalization & Ownership: Users don’t own the data or infrastructure, limiting personalization and integration with personal knowledge.
• Agent Native Support: Many tools are not designed to be inherently agent-native, hindering seamless integration with other AI agents.
• Specific Task Weaknesses: NotebookLM, for example, is noted as “weak for coding tasks” because it’s browser-based.
• Infrastructure Overhead (RAG): While RAG pipelines with vector databases are powerful at scale, they require significant infrastructure and are “not really human-friendly” for daily, inspectable use.

The AI Research OS: A Personalized, File-Based Wiki

The proposed solution is a personalized research assistant that functions as a “Wikipedia that compounds over time,” easily inspectable and usable. The core philosophy is to build a system based on plain files, primarily Markdown, leveraging the local file system rather than complex infrastructure like vector databases or knowledge graphs, which “add a lot of complexity.”

System Evolution: From Static to Dynamic

Paul details the three iterative versions of their system:

1. V1: Simple Lesson Creation (Static Research MD)

   • Input: Topic + manually handpicked “golden links.”
   • Algorithm: Deep research algorithm (orchestrator agent creating questions, sub-agents using Gemini/Google for queries), aggregation of summaries, three rounds of query generation, and a ranking algorithm to filter high-signal information.
   • Output: A single, static research.md file.
   • Limitation: Generic, required manual golden links, static output meant re-running the entire process for new questions.

2. V2: Deep Research on Second Brain (Static Research MD)

   • Enhancement: The deep research loop now targets personal sources (Obsidian, Readwise, NotebookLM, GitHub) in addition to the public web.
   • Input: Only the topic (golden links are organically derived from the second brain).
   • Process: Same deep research algorithm, but querying both the second brain and the public web.
   • Output: Still a static research.md file.
   • Limitation: Research remains static; further questions require extensive token consumption and time to regenerate.

3. V3: Deep Research + LLM Knowledge Base (Wiki Layer)

   • Core Innovation: Introduction of a dynamic wiki layer on top of the deep research algorithm.
   • Input: Diverse sources (Obsidian, NotebookLM, Google Drive, YouTube, Notion, custom URLs).
   • Architecture:
     • Raw Folder: Stores immutable raw data.
     • Index: An index.yaml file acts as a catalog of all data, including summaries and metadata. It serves as the entry point for the agent.
     • Wiki Folder: Contains LLM-generated derivatives such as comparisons between concepts, entities, notes reflecting questions, and open questions. This is where the LLM performs analysis on top of the raw data.
   • Token-Efficient Querying: The agent first consults the index.yaml for summaries. If more detail is needed, it checks “source wiki pages” (expanded summaries). Only if information is not found there does it read the full raw source, making the process highly token-efficient.
   • “Alive” Wiki: The wiki is dynamic and evolves over time. Every question asked leaves a trace, potentially creating new concept, note, or comparison files. It’s tracked in a log, ensuring it’s never frozen and continuously reflects the user’s evolving understanding and queries. It integrates new custom links and can run new deep research rounds as needed.
   • Integration with PARA Method: The wiki does not modify the original “second brain” (e.g., Obsidian) but uses it as an immutable snapshot for specific projects, scoping down the vast personal knowledge base to relevant project contexts.

Practical Demonstrations

The system is implemented in a repository called AI Research OS workshop, distributed as a Cloud Code plugin. Paul and Louis-Francois demonstrated its capabilities:

• Example 1: Researching “Agentic AI Engineering”: Ingesting personal notes and references, running a “light” deep research, and generating a wiki with raw files, an index, and extracted concepts (e.g., “agent loop resources”).
• Example 2: Analyzing Open-Source Repositories: Ingesting GitHub repositories (e.g., Open Code, Pi, Hermes) to explore topics like general architecture, agent architecture, memory systems, and permission flow. The system creates individual repo notes, cross-repo comparisons, and architectural concepts.
• Example 3: Ingesting Custom Links: A simple setup ingesting random web links to generate an executive summary, concepts, and entities, demonstrating basic utility without complex external integrations.
• Dynamic Querying: Asking questions directly on a generated wiki (e.g., “how remote sandboxing works in harnesses”) prompts the agent to query the wiki, provide answers, and further update the wiki with new notes, comparisons, or entities.

Future Directions and Improvements

While highly functional, the project continues to evolve:

• Connectors: Expansion to include Google Drive, Notion, Slack, and other services.
• Source Provenance: Enhancing the ability to identify outdated, weak, or strong sources.
• Builder Workflow: The current terminal-based Cloud Code interface is intentional, focusing on AI engineering principles rather than a polished UI/UX.
• Technical Enhancements: Stronger linting, better memory compaction, and improved source provenance for trust and reuse.

For those interested in building similar systems, Louis-Francois recommends the Agent Engineering course on Towards AI Academy, which guides learners through constructing a multi-agent system with a deep research and writing agent.

• Tags:
• AI Agents
• Developer Tools
• RAG
• Context Management
• Memory Management
• Knowledge Base
• LLM Engineering
• Obsidian
• Second Brain
• Cloud Code
• Research Automation