---
title: "Karpathy wiki: the parts that map"
url: https://memory.wiki/glqi_Xjw
updated: 2026-05-14T18:15:49.480Z
hub: https://memory.wiki/hub/demo
bundle_count: 1
concept_count: 12
source: "memory.wiki"
---
# Karpathy wiki: the parts that map

> Expansion of demo-karpathy-llm-wiki. That doc is the public summary; this is the internal "where it lines up with us and where it doesn't" working note.

## The Karpathy quote that started this

> "Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase."

He was sketching a personal-knowledge-management shape for the AI era. The premise: AIs are most useful when they have access to a structured corpus of your own thinking; that corpus should be a wiki shape (interconnected pages, not a doc tree).

## What maps directly

- **The user is the author.** Karpathy explicitly says the wiki is *hand-curated*. The AI is the programmer reading it, not the writer.
- **Markdown is the substrate.** Every example he gave is markdown.
- **The "wiki" word.** Both his framing and ours land on it.

## What doesn't map

Three structural differences:

1. **Local file vs URL.** Karpathy's Obsidian example is a vault on disk. mdfy is a URL. The URL shape lets the wiki be addressable from any AI tool simultaneously; the Obsidian shape requires that the AI run on the same machine as the vault (or have access via MCP/file-sharing).
2. **One wiki vs N scopes.** Karpathy frames it as one unified wiki per person. mdfy splits the same surface into Doc / Bundle / Hub — three URL scopes that map onto the per-project AGENTS.md / CLAUDE.md / .cursor/rules world AI dev tools already understand.
3. **AI as reader-only vs AI as collaborator.** In the Karpathy frame, the AI reads the wiki to inform answers but doesn't extend it. mdfy treats the AI as a co-author at the boundary — it suggests related docs, flags orphans, builds the concept index. The author still owns the canonical text; the AI does the assistive work around it.

## Where I think Karpathy is right

The deepest claim — that a personal knowledge layer is the missing piece between you and the AI tools you use every day — is exactly right. The disagreement is purely about shape and surface area.

## Where I'm betting differently

Per-project context (bundles) and per-person context (hubs) compose better than a single monolithic wiki. AGENTS.md and .cursor/rules already enforce per-project scopes. Our shape matches; the Obsidian shape doesn't.


---

## Concepts in this document
- **mdfy** _(entity)_
  A tool that stores project context and decision history, integrated into Cursor via custom rules.
- **Knowledge Management** _(tag)_
  Domain of organizing, storing, and retrieving information for human and AI use.
- **Obsidian** _(entity)_
  The primary subject being tested for import functionality and markdown compatibility.
- **llms.txt** _(concept)_
  Plain-text discoverability standard for AI agents at site root, analogous to robots.txt and sitemap.xml.
- **Letta** _(entity)_
  Extracted memory system that infers behavioral patterns and work-shape preferences from conversation history with loose but contextually interesting extraction.
- **Multi-hop reasoning** _(concept)_
  GraphRAG's capability to answer comparative questions across documents by traversing graph structure; advantage over vector-only retrieval.
- **Mem0** _(entity)_
  Extracted memory system that produces factual, direct summaries from conversation history with strong extraction quality but limited stylistic or contextual nuance.
- **Community detection** _(concept)_
  Graph clustering technique (Leiden algorithm) that GraphRAG uses for structural priors; identified as improvement candidate for mdfy.
- **RAG Systems** _(tag)_
  Broad category of retrieval-augmented generation approaches for enhancing AI with external knowledge.
- **GraphRAG** _(entity)_
  Microsoft's knowledge-graph-based retrieval system that uses community detection for multi-hop reasoning; primary subject of analysis.
- **Extracted memory** _(concept)_
  AI-generated user profiles automatically inferred from conversation history without direct user authorship, central to both Mem0 and Letta approaches.
- **Knowledge Graphs** _(concept)_
  Structured representations of information as interconnected entities and relationships, enabling multi-hop reasoning.

## Concept relations (within this doc's concepts)
- **Knowledge Graphs** enables **Multi-hop reasoning**
- **Community detection** analyzes structure **Knowledge Graphs**
- **Mem0** implements **Extracted memory**
- **Letta** implements **Extracted memory**
- **GraphRAG** implements **Knowledge Graphs**
- **Mem0** is type of **Extracted memory**
- **Letta** is type of **Extracted memory**
- **mdfy** should adopt from **Community detection**
- **GraphRAG** enables capability **Multi-hop reasoning**
- **GraphRAG** uses for clustering **Community detection**

## Bundles containing this document
- [AI memory research: the public frontier](https://memory.wiki/b/wpwVCSDF)
  > Side-by-side notes on Mem0, Letta, Microsoft GraphRAG, Karpathy's LLM Wiki, llms.txt adoption.

_Hub canonical:_ https://memory.wiki/hub/demo
_Concept digest:_ https://memory.wiki/raw/hub/demo?digest=1&compact=1