@Hannah Stulberg built a Claude Code repo at DoorDash that 20 people use daily. Root CLAUDE.md under 500 tokens. Nested indexes in every folder. Each function owns its context. Data scientists pull metrics without asking. Strategy leads grab call summaries. Engineers check analytics without filing tickets.
She calls it a Team OS. It is the most production-ready multi-user AI knowledge architecture I have seen documented publicly.
Here is the problem she will face within six months.
@Andrej Karpathy's LLM Wiki works beautifully for one person. You dump messy notes, the LLM compiles them into a wiki, every query makes the wiki better. The loop compounds because one mind, one vocabulary, one namespace. No ambiguity about what "revenue" means when you are the only person defining it.
@Siddharth Shah studied what happens when you scale this to teams. Four failure modes appeared in every enterprise knowledge graph project since the Semantic Web era. Ungoverned documents that make the graph a liability. Nobody owning the ontology so definitions drift silently. Semantic ambiguity where the same label means different things across functions. Maintenance decay where the system was created once and maintained never.
Stulberg's Team OS solves the first two with folder ownership: PM owns /product, data scientist owns /analytics, strategy owns /customer. Each function maintains its domain context. That is governance through file structure.
But folder ownership does not solve semantic ambiguity. When the PM writes "conversion" in /product and the data scientist writes "conversion" in /analytics, those reference different metrics. When engineering references a "service" and strategy references a "service," those are different entities. The file system has no way to express that two identical labels point to different concepts. Flat markdown cannot represent typed relationships between entities.
The missing layer is a graph ontology.
Entities need types. Relationships need labels. Definitions need namespaces. A graph where "conversion" is a node with typed edges to its definition, its owner, its data source, and its measurement methodology prevents the silent drift that kills knowledge systems at team scale.
GraphQLite makes this practical. A single SQLite file with Cypher queries, schema-free node creation, and built-in algorithms like PageRank and Louvain community detection. No server. No configuration. Drop it into the Team OS repo alongside the CLAUDE.md files. When the agent needs to disambiguate "conversion," it queries the graph instead of guessing from context.
LightRAG takes this further for retrieval. Its dual-level system searches entities by vector similarity AND traverses their relationships in the graph. Legal document retrieval with graph-enhanced search scored 84.8% versus 15.2% for naive vector search. The graph does not replace the wiki. The graph makes the wiki queryable at the relationship level.
The architecture that compounds at team scale has three layers. Markdown files for human-readable context, like Stulberg's folder structure. A graph ontology for entity disambiguation and relationship tracking. And a compile step that periodically re-synthesizes both into consistent, current knowledge.
Karpathy gave us the compile pattern. Stulberg gave us the multi-user architecture. Shah gave us the failure modes to avoid. GraphQLite and LightRAG gave us the graph layer. The pieces exist. The team that assembles them first builds institutional knowledge that improves with every query instead of decaying with every hire.
Resources:
- Agentic Graph RAG (O'Reilly): oreilly.com/library/view/agentic-graph-rag/9798341623163/
- GraphQLite: github.com/colliery-io/graphqlite
- LightRAG v1.4: github.com/HKUDS/LightRAG
- Shah on Enterprise Failure Modes: linkedin.com/pulse/i-want-context-graphs-work-siddharth-shah-zxsec
- Karpathy LLM Wiki: x.com/karpathy/status/2039805659525644595
- DoorDash Team OS (via Aakash Gupta): linkedin.com/in/aagupta
- Sequeda WHAT-WHY Ontology Framework: linkedin.com/in/juansequeda