The 7 Levels of Claude Code & RAG

Study Guide

Overview

This video presents a structured roadmap of seven progressive levels for managing memory and retrieval in Claude Code. The core problem: AI systems struggle to reliably answer questions about past conversations and large document collections. The typical answer has been RAG (Retrieval Augmented Generation), but the video argues that most people should start simple and only escalate complexity when genuinely needed.

Each level covers what to expect, the skills to master, the traps to avoid, and what triggers the move to the next level.

Level 1: Automemory

Claude Code ships with an automatic memory system that creates markdown files on its own, stored in .claude/projects/memory/. These are essentially Post-it notes about things Claude thinks are important based on your conversations.

  • The problem: Automemory is not enough. Most users stay here forever, relying on bloated context windows instead of taking an active role in memory management.
  • Context rot: The more you talk within a single session, the worse Claude gets. At 256k tokens (about 25% of the 1M context window), effectiveness can drop from 92% to 78%. Keeping sessions open endlessly wastes tokens and degrades quality.
  • The trap: Never clearing sessions because you fear losing context. This fear is inherited from chatbot habits (ChatGPT, Claude web app) where there was no real memory between conversations.
  • To advance: Recognize that automemory is insufficient and begin taking explicit control over what Claude remembers.

Level 2: CLAUDE.md

The CLAUDE.md file is injected into essentially every prompt Claude Code executes. It feels like the holy grail for setting rules, conventions, and things you want Claude to always remember.

  • Template structure: Typically includes an "About Me" section, file system structure, and operating conventions.
  • The research: Studies (like "Evaluating agents.md") found that these instruction files can actually reduce LLM effectiveness when bloated. Because the file is injected into every prompt, irrelevant content becomes noise.
  • Less is more: Only include information relevant to virtually every single prompt. Context pollution is real.
  • The trap: A bloated rule book. People stuff everything into CLAUDE.md instead of keeping it high-signal.
  • To advance: Think of CLAUDE.md as an index that points Claude in the right direction, not a dumping ground for all memory.

Level 3: State Files and Multi-Markdown Architecture

Instead of one monolithic CLAUDE.md, create multiple specialized markdown files. The GSD (Get Stuff Done) orchestration tool exemplifies this approach with separate files for project.md, requirements.md, roadmap.md, and state.md.

  • How it works: CLAUDE.md serves as an index pointing to specific files. Claude follows the path: CLAUDE.md tells it "here are your five options," then it navigates to the right file.
  • Why it helps: Fights context rot by not injecting everything into every prompt. Creates a crude version of the chunking and similarity search found in true RAG systems.
  • Skills to master: Structuring docs with clear hierarchy, updating state at every session, leveraging orchestration tools (GSD, Superpower).
  • The trap: Project-specific context that does not transfer easily between codebases.
  • To advance: Bring in external tools that let you share context across projects.

Level 4: Obsidian

This is the level the video recommends most people should aim for. Obsidian provides a free, low-overhead system for building an LLM knowledge base, following the pattern Andrej Karpathy popularized (nearly 20M views on his approach).

The Vault Architecture

  • Vault: The top-level folder Obsidian manages, functioning as a quasi-RAG system.
  • Raw folder: Staging area for ingested data (competitive analysis, research, scraped content).
  • Wiki folder: Structured data organized as Wikipedia-style articles, each in its own subfolder with index files.
  • Master index: A markdown file listing everything in the wiki, giving Claude a clear hierarchy to navigate.

Why Obsidian Works

  • Clear hierarchy means Claude can efficiently find information even across hundreds or thousands of documents.
  • Human-readable: you can click through documents and see connections visually, which arguably gives better insight than peering through embeddings in a graph RAG database.
  • Free, no overhead, and scales surprisingly far for solo operators.

The Scale Question

Research shows RAG can be up to 1,200x cheaper and faster than textual LLM approaches (though this was measured in 2025 with older models). The gap has shrunk, but the point stands: at some scale, Obsidian's approach becomes more expensive and slower than a proper RAG system. The exact crossover point depends on your documents and use case, and you will only find it through experimentation.

  • The trap: Jumping to RAG before trying Obsidian. Always start with the simpler option.

Level 5: Naive RAG Fundamentals

This level is about understanding how RAG works, not necessarily implementing basic RAG (which has largely fallen out of favor).

How Naive RAG Works

  1. Chunking: Documents are split into pieces (chunks).
  2. Embedding: Each chunk is sent to an embedding model that converts it into a vector (a series of numbers representing semantic meaning).
  3. Vector database: Vectors are stored in a multi-dimensional graph where semantically similar content clusters together.
  4. Retrieval: When you ask a question, your query is also converted to a vector. The system finds the most similar vectors and pulls that information into the LLM to augment its answer.

Why Naive RAG Falls Short

  • Chunking problems: Chunk 3 might reference something in Chunk 1, but the system may not retrieve both. Often the entire document is needed for context.
  • No relationships: Vectors exist in silos. You cannot ask how Topic A relates to Topic B across different documents.
  • Rerankers help but are not enough: They add a second pass with an LLM to rank retrieved chunks by relevance, but the fundamental limitations remain.
  • The trap: Naive RAG essentially creates a "crappy search engine." Many commercial RAG products (Pinecone, Supabase implementations without graph capabilities) deliver roughly 25% accuracy.

Understanding this foundation is critical before implementing anything more sophisticated.

Level 6: Graph RAG

Graph RAG treats everything as connected rather than isolated vectors. The video recommends LightRAG as the lightest-weight open-source option.

How Graph RAG Differs

  • Documents go through an actual embedding system that examines content, sets relationships, and defines entities.
  • You can see descriptions, types, files, chunks, and relationships for each node.
  • LightRAG benchmarks show jumps of over 100% compared to naive RAG (e.g., 31.6% vs 68.4% on key metrics).

Obsidian vs. Graph RAG

Obsidian's graph view looks similar but is fundamentally different. Obsidian connections are manual (bracket links). Graph RAG connections are computed through embeddings and entity extraction. At small scale the performance difference is negligible, but at large scale graph RAG pulls ahead.

  • The trap: Graph RAG (including LightRAG) handles text well but struggles with multimodal content like scanned PDFs, videos, and images.

Level 7: Agentic RAG

The bleeding edge as of April 2026. Two main concerns define this level:

Multimodal Ingestion

  • RAG Anything: Allows importing images and non-text documents (scanned PDFs) into knowledge graph structures like LightRAG.
  • Gemini Embedding 2: Released March 2026, enables embedding actual video content into vector databases, not just transcripts.

Production Architecture and Pipelines

  • Data ingestion pipelines: How does data get into the system? How is it updated when source documents change? How are duplicates handled?
  • Most of a production agentic RAG infrastructure is about data ingestion and syncing, not the RAG query itself.
  • An AI agent sits on top and intelligently routes queries: graph RAG database for unstructured knowledge, SQL/Postgres for structured data, CLAUDE.md for permanent context.

Recommended Stack for Solo Operators

RAG Anything + LightRAG: both open source, lightweight, and low-risk to experiment with. If it does not work for your use case, you have only lost a few hours rather than significant money.

The Mature Memory Architecture

  • CLAUDE.md for permanent, high-signal instructions
  • Codebase markdown files for project-specific context
  • Obsidian vault for cross-project knowledge
  • Graph RAG database for large-scale document retrieval
  • Top-of-funnel AI agent that routes queries to the right source
  • The trap: Forcing yourself into Level 7 when it is not needed. Most people are fine with Obsidian (Level 4). If it is not obvious you need this level, you probably do not.

Key Takeaways

  • Start simple, escalate only when needed. Try each level in ascending order before jumping to complex RAG systems.
  • Context rot is always in play. Every memory strategy must balance ingesting enough context against degrading performance from too much context.
  • Obsidian is the 80/20 solution (really 99% for most solo operators). Free, human-readable, and surprisingly scalable.
  • Naive RAG is largely obsolete but understanding it is essential for making informed decisions about graph RAG and beyond.
  • Experiment. Nobody can tell you where the line between Obsidian and RAG falls for your specific use case. You have to try both.
  • Production RAG is mostly about pipelines, not the retrieval algorithm itself. Data ingestion, syncing, and access control are where systems succeed or fail.
YouTube