The current obsession with Andrej Karpathy’s file-based Wiki approach is a classic case of developer sentiment outstripping architectural reality. On the surface, the appeal is obvious: a low-friction, folder-and-text-file system that leverages an LLM to synthesize knowledge as it arrives. It’s elegant, it’s readable, and it’s immediate.
But beneath the surface, it’s a fragile paradigm. By treating the AI as an editor that writes directly to your source-of-truth files, you are effectively introducing a “lossy” compression layer into your cognitive stack. Once the AI synthesizes a document, the nuance of the raw data is often buried or discarded. If the AI hallucinates a connection or misinterprets a contradiction, that error becomes the new baseline for all future queries. You aren’t just storing knowledge; you are baking in editorial bias.
The Architectural Fork: Right-Time vs. Query-Time
The fundamental engineering trade-off here is timing. Karpathy’s Wiki is a right-time system. It performs the heavy lifting—synthesis, cross-referencing, and contradiction flagging—at the moment of ingestion. The compute cost is front-loaded. The result is a highly navigable, human-readable artifact that feels like a “second brain.”
Conversely, structured data models like Open Brain are query-time systems. They treat the AI as a reader. Data is stored in a normalized, SQL-backed format, keeping the raw facts pristine. The heavy lifting—the synthesis—happens only when you actually ask a question.
The trade-offs are stark:
- Wiki (Right-Time): Optimized for deep, solo research. It excels at narrative evolution but breaks at scale. When multiple agents attempt to write to the same markdown files, you hit concurrency hell.
- Open Brain (Query-Time): Optimized for precision, auditability, and multi-agent access. It handles thousands of records without breaking, but it lacks the “pre-baked” synthesis that makes a Wiki feel intuitive.
The Hybrid Bridge: Graph-Based Compilation
The solution isn’t to choose one, but to decouple the storage from the presentation. By implementing a compilation agent that sits atop a structured database, you can achieve the best of both worlds.
In this architecture, Open Brain remains the immutable source of truth. A secondary process—a “Wiki Compiler”—runs on a schedule to query the database and generate a graph of relationships. This graph is then rendered into the Wiki format.
This approach solves the primary failure modes of the pure Wiki model:
- No Drift: Because the Wiki is a generated artifact, not the source, you never suffer from “misinformation creep.” If the synthesis is wrong, you fix the underlying row in the database and re-run the compiler.
- Scale: You aren’t limited by file system performance or agent-write collisions. The database handles the concurrency; the Wiki handles the human consumption.
- Filtered Context: Unlike a static folder, the compiler can apply logic—filtering by date, confidence score, or category—before the AI even begins the synthesis process.
The Shift from Oracle to Maintainer
The industry is currently transitioning from treating LLMs as “Oracles”—black boxes you query for one-off answers—to “Maintainers” that manage persistent state. Karpathy’s Wiki is a proof-of-concept for this maintenance role, but it is a prototype, not a production-grade memory architecture.
For solo researchers, the file-based approach is sufficient. But for any system requiring multi-agent access, audit-ready data, or high-volume throughput, the “file-over-app” simplicity of a Wiki is a liability. The future of AI-augmented knowledge isn’t just about storing files; it’s about building a robust, queryable data layer that can compile its own narrative on demand. If you aren’t building for that separation of concerns today, you’re just building a more sophisticated way to lose your data.