Karpathy's Wiki vs. Open Brain. One Fails When You Need It Most.

Everybody is going nuts about the wiki idea that Andre Carpathy posted a couple of days ago. 41,000 people have bookmarked it. And on the surface, it

bookmarked it. And on the surface, it sounds ridiculously simple. You use your AI to build and maintain a personal wiki. As someone who launched something

wiki. As someone who launched something somewhat similar with OpenBrain, I have gotten hundreds of DMs and emails saying, "Nate, is this the same thing?

Nate, is this different? Nate, does this make OpenBrain obsolete? Nate, is the wiki better?" I want to actually step

wiki better?" I want to actually step back and give you a different answer than you expected. We are going to go through, we are going to talk about what

the wiki approach gets right, why Andre put it together, the principles underlying this wiki approach versus the open brain approach. And I want to be honest about why we're doing that. We're

not doing that just for giggles. We're

doing that because deciding how you organize your context layer is one of the single most important things you can do in 2026. It is a really big deal. And

Karpathy's approach is really different from OpenBrain. It's not the same thing

from OpenBrain. It's not the same thing at all. And there are specific reasons

at all. And there are specific reasons why he went with his decision and why I went with the decisions that I made to construct open brand. And I'm going to be really open about both. I'm not going to give you a steelman. I'm not going to

say one is better than the other. So

just get that out of your head. We're

going to talk about where each one breaks, the scale issues that each have, and where each one is strong. And then I promise you, I am going to help you solve the problem because I know that

what most of you are going to say is, "I want the best of both worlds." We are going to get there. I put a plugin into OpenBrain that will help you have the best of both worlds. So you can have the

wiki approach Carpathy takes with the structured data that OpenBrain brings.

And by the end of this video, you'll understand why it matters to be able to do both and you'll feel equipped to make that decision. So let me explain a

that decision. So let me explain a little bit about what's under the surface that is a little bit more complex than it might appear at first glance. Because on the surface,

glance. Because on the surface, Carpathy's implementation is very simple. It's just folders and it's text

simple. It's just folders and it's text files. That is the big idea for him. And

files. That is the big idea for him. And

you might wonder why did he go so simple? Well, his insight is the idea

simple? Well, his insight is the idea that everybody uses AI with their documents today all day, right? You

upload files to chat GPT, you use notebook LM, you use cloud, and you always end up in a place where you have bunches of documents everywhere and then you ask a question and the AI has to go

and find relevant chunks of documents, previous chats, reads them, gives you an answer. It's all hyper fragmented all

answer. It's all hyper fragmented all over. This works okay, but it's actually

over. This works okay, but it's actually not ideal because what's happening under the hood is that AI is effectively rediscovering your knowledge from scratch every single time you ask a question. So, if you ask a question that

question. So, if you ask a question that requires connecting five different documents across six different chats, the AI has to find all five, read the six chats, figure out how they relate, and produce some kind of a synthesis. If

you ask a similar question tomorrow, it does the whole thing over again. Nothing

was saved about that synthesis. It

doesn't inherently preserve connections between documents, even if you're in the same chat application, let alone if you're in two or three different AIs like so many of us are. In other words,

the AI did real cognitive work and then threw it all away. And that is what bothered Carpathy enough to put together a different solution. What he asked is, what if instead of just finding relevant

chunks and answering questions, the AI actually wrote down what it learned?

What if every time you added a new source, the AI read that source, figured out what mattered and updated a set of organized notes that already contained everything it learned from the previous

source? In other words, what if it

source? In other words, what if it started to auto update based on its own synthesis? What if those notes already

synthesis? What if those notes already included cross references, flagged contradictions, tracked how your understanding evolved? If you're trying

understanding evolved? If you're trying to learn how you think and evolve over time, that's what this wiki idea is for.

It essentially becomes not just a clever file organization system, but actually a persistent artifact as a whole where

you're capturing the AI's evolving understanding of your thinking over time. So the AI might read a paper you

time. So the AI might read a paper you give it on Monday, write up what it learned, and link back to it what it learned the previous week from some other thread that you were working on.

The next Friday when you ask a question, the AI doesn't have to reread everything from scratch. Instead, it looks at the

from scratch. Instead, it looks at the synthesis that is already sitting there, the cross references that are already built, the contradictions that have been flagged. And in Carpathy's own words,

flagged. And in Carpathy's own words, the knowledge is compiled once and then kept current. It's not rederived on

kept current. It's not rederived on every query. And that is really the key

every query. And that is really the key here. Most AI knowledge tools spend

here. Most AI knowledge tools spend compute and tokens to rederive. whereas

his wiki compiles. That's a

fundamentally different relationship between AI and your information and it has different strengths and weaknesses than a lot of other predominant memory paradigms including OpenBrain. He

described his working setup as having the AI agent on one side and Obsidian which is just a note viewing app on the other side. And so that allows the AI to

other side. And so that allows the AI to make edits based on their conversation and he can browse the results in real time and follow links and check the graph view and read the updated pages and kind of have an evolving

conversation with the agent. And of

course being a programmer the way he talks about it is the LLM is sort of the programmer for the codebase of the wiki which means in plain English the note app is where he actually reads and the

AI is the one writing in the notes app based on a collected series of built documents. Some of them are raw sourced

documents. Some of them are raw sourced that he inputs from previous chats. Some

of them are docs. Some of them are synthesis the AI puts together. Think of

it like most AI tools are like having a brilliant research assistant who reads your entire filing cabinet every time you ask a question and then it gives you a really great answer and then immediately forgets everything that it

figured out. Andre Carpathy's wiki is

figured out. Andre Carpathy's wiki is like that same assistant keeping a running set of notes that are organized and cross-referenced and updated so that each question builds on the last one

instead of starting over. I think that idea of being able to build on your learnings is why 41,000 people jumped on it and bookmarked the post. Right? It's

not because the folders and the text files themselves are exciting. It's

because an AI that builds understanding over time instead of starting from zero is something we're all hungry for right now. It's the thing everyone's been

now. It's the thing everyone's been waiting for. It's what made people

waiting for. It's what made people really excited about OpenBrain. But

there's a catch that almost nobody in these 41,000 bookmarks is thinking about yet. Every time the AI turns a raw

yet. Every time the AI turns a raw source into a wiki page, it is making editorial decisions. It's making

editorial decisions. It's making decisions about how to frame the connections between ideas that may be right or wrong, but those are the AI's choices, right? They're not the human's

choices, right? They're not the human's choices. It's making synthesis choices

choices. It's making synthesis choices somewhat independently of what you may or may not think. And so important nuance could get dropped that m might matter a few months from now and you would literally never know. You wouldn't

know what's missing because the wiki reads so cleanly. This is sort of the same trap as dashboards and analytics. A

dashboard is so much easier to read than a spreadsheet, but it is a condensation of data, right? It can hide exactly the thing you need to see because it just shows only the thing that it thinks you

want to see in the moment. And to his credit, Andre Carpath has been very honest about this, right? His

architecture keeps all the raw sources untouched in their own folders. So he

can always go back to the originals, which is a really smart design. But to

be honest, most people building on his pattern are not going to maintain the discipline to go back to raw sources. In

practice, I think the wiki will become the thing that is trusted as this open source project rolls out. And the source of truth is quietly going to shift from

raw material to an AI summary of that material, which may be correct 80% of the time. maybe 90% of the time, but

the time. maybe 90% of the time, but where it misses something or where it frames something slightly wrong, there are going to be issues that arise and that errors will now be baked into our

understanding if that is the only way we're approaching memory. And you won't get in the habit of questioning it because the whole premise of this when I started this video is that we are lazy people. It's really nice to have a wiki

people. It's really nice to have a wiki where you can just chuck stuff in and it sort of automatically organizes, learns, and comes back with written artifacts.

And so this is where open brain enters the picture and things get really really interesting. Every knowledge system with

interesting. Every knowledge system with an AI at its core has to answer one question. When does the AI do the hard

question. When does the AI do the hard thinking? Is it when information comes

thinking? Is it when information comes in or is it when you ask about that information you got to pick that's the fork everything else follows from that.

Carpathy's wiki is a right time system.

So when a new source arrives like an article, a paper, a set of notes, the AI does not just store it. The AI actually actively works against it. It reads the

source. It extracts what matters and it

source. It extracts what matters and it writes that understanding into the wiki.

It will update topic pages for you. It

will write relevant summaries for you.

You get the idea, right? It's going to actively work to add links between related ideas, develop concepts, note where new data contradicts something

that was filed last week. It will do a lot of that thinking at input, right?

The hard work then happens one time at the beginning, the moment the information comes in the door. After

that, you can browse the wiki and get pre-built understanding without the AI doing virtually any work at all. It's

just retrieving. Open brain is different. It is a query time system.

different. It is a query time system.

When new information arrives, OpenBrain is designed to store it faithfully. It

tags it. It categorizes it. It makes it searchable. But we're not assuming that

searchable. But we're not assuming that you need to synthesize that information yet. Nobody's synthesizing. Nobody's

yet. Nobody's synthesizing. Nobody's

doing work. The data is sitting in structured tables waiting. When you or your AI agent asks a question, that's when the AI goes to work. It reads the

relevant entries. at that point at query

relevant entries. at that point at query time. It does the thinking fresh and it

time. It does the thinking fresh and it produces an answer on the fly. So the

hard work happens at the moment you need it, not before you need it. So think of it this way. Carpathy's wiki is like a study guide that a really good tutor writes for you as you learn the subject.

Every time you cover new material, the tutor will update the guide for you so you don't get lost along the way. The

tutor will add new sections, revise old sections, connect ideas across chapters, and really help you dig in so that when exam day comes, you just read the guide, and you're good to go. Which is exactly

kind of how that wiki is supposed to work. Ideally, the thinking has been

work. Ideally, the thinking has been done for you. The tutor has prepared everything so perfectly, you can't fail.

Open brain is like a perfectly organized filing cabinet with a brilliant librarian standing next to that filing cabinet for you. Every document is filed. It's indexed. It's searchable. So

filed. It's indexed. It's searchable. So

that when you need an answer, the librarian can very quickly pull the relevant file, read through that relevant file for you, and then pinpoint exactly what you need to find in that

file. It will tell you what you're

file. It will tell you what you're looking for. The filing is really clean

looking for. The filing is really clean and pristine, and that enables the metaphorical librarian to do the thinking fresh in a very efficient way every time you ask, so you get exactly

the synthesis you're looking for. To be

honest with you, I'm not here to compare and contrast and give you an easy winner. Study guides and filing cabinets

winner. Study guides and filing cabinets can both be useful, but they're good at different things, and I don't want them compared inaccurately. And that's really

compared inaccurately. And that's really important. So, why does this matter for

important. So, why does this matter for you? This is the way to think about it

you? This is the way to think about it that's not about architecture. If you

only store stuff, your AI has to figure out what it all means every time you ask. You've been feeding it articles,

ask. You've been feeding it articles, meeting notes, and research for months and months and months and months. You

ask a question that requires connecting a bunch of different sources together.

And the AI has to go and burn tokens. It

has to find those sources. It has to make sense of them. It has to read them.

It has to think through them. It has to understand what's going on, figure out how they relate together. And

ultimately, it has to produce a synthesis that actually works from scratch. And it has to do that every

scratch. And it has to do that every single time. Nothing has been pre-built.

single time. Nothing has been pre-built.

Now, here's the other side. If you only build a wiki, your AI can read the summary, but it cannot do anything precise with the raw data underneath.

You want to pull every deal over $50,000 from the last quarter. You want to filter all your meetings by client name.

You want to have three different AI tools that query your knowledge base at the same time. A folder of text files cannot answer complex questions like that. The understanding is there in

that. The understanding is there in synthesized form, but the detailed structured data to make meaningful decisions just isn't there. And it isn't

there by design. It's just not going to be there. In addition, if you have three

be there. In addition, if you have three or more agents, that's just going to break when they're all trying to write Markdown files at once. The wiki

structure presupposes a single agent working for you that just writes in one place. Whereas the open brain structure

place. Whereas the open brain structure assumes you may want to hook in multiple agents at multiple points to contribute to or pull from a structured database.

Let's move on from structured data to talk about a different kind of challenge with AI. It is difficult right now to

with AI. It is difficult right now to actually trace how an AI learns or improves over time when there is no memory architecture under the system.

And I want to talk about a distinction between remembering detailed facts which open brain is designed to do and remembering narrative or synthesis which

the wiki is designed to do. And I want to help you understand how that plays out for a team because it's really important to understand that our storage architectures shape the futures that we

are unlocking for teams because that we're effectively choosing a context layer that you need to make sense of, use, input information into, believe,

trust, and depend on for decisions. The

stakes could not be higher. Most

organizations are generating enormous volumes of AI touched knowledge right now. We're generating meeting summaries.

now. We're generating meeting summaries.

We're generating strategy documents touched by AI. We're generating research outputs. We're generating Slack threads.

outputs. We're generating Slack threads.

And almost all of it is write once, read never because nobody is maintaining any of it. Nobody is synthesizing across any

of it. Nobody is synthesizing across any of those documents. Nobody is flagging that the Q2 strategy deck contradicts what the CEO said in last week's all hands. Your company's AI generated

hands. Your company's AI generated knowledge right now is either a compounding asset or it's just a growing pile of noise. And so the choice between the two memory structures here is a lot

more than a design decision. It's

actually the thing that most teams are making by accident that determines how reliable their northstar compass in product decisioning is. And the subtlety that matters here is that sometimes

contradictions are the most valuable thing in your knowledge base. And one of the things that you worry about is that you're going to lose the distinctions that you need to make good decisions in a wiki format. So engineering might

think the timeline for the build is 12 weeks and sales promise the client 8.

And something like a smart wiki might resolve that contradiction into one coherent narrative rather than flagging that you have a fundamental misalignment. And that is a strategic

misalignment. And that is a strategic signal in the system that you would not want to synthesize across with an estimate of 10 weeks. The gap between what engineering knows and what sales

promised is exactly the problem your leadership would need to see in that situation. A database that stores both

situation. A database that stores both views without resolving them preserves that tension and a well-meaning wiki might smooth those all away. So those

are some of the structural differences.

But if we go past the structural differences in these two memory systems, the open brain system and the wiki system, I want to talk a little bit about the job that the AI does in each

system and why it's important to name the AI job description really clearly.

One of the sharpest practical differences between these approaches is what the AI will spend its time doing.

And you need to decide like where do you want to invest in your AI. In Karpathy's

system, the AI is primarily a writer.

The job is to maintain a document. And

when you add a new source, you have to write to that, right? You have to read the raw material, synthesize it, write what you think about it. Update wiki

pages, connect new links, make sense of it, add concept explanations, cross reference it, create an index. There's a

ton to do. It's effectively doing editorial work. It's making judgment

editorial work. It's making judgment calls about what's important, about what connects to what, and where those contradictions might lie. Whereas in

open brain, we think of the AI as primarily a reader. Its job is to answer questions by pulling from the structured data and when you or an agent will ask something, the AI will just search the

database that has been carefully read and carefully organized, read the relevant entries and come back with a precise, fresh synthesis based on all of

the available data. So effectively, it is doing the analytical work on the fly, but it's able to produce more detailed results because all of the detail is immediately available in the database.

And so those different job descriptions have real consequences. When the AI is a writer, you interact with it intensively when new information comes in. Is that a job that you want to do? Do you want to

interact with it a lot when the new information comes in? it does adding a single research paper trigger updates across a dozen wiki pages and is that something you're comfortable doing as you think through and and figure out the

connections? It's a somewhat heavy

connections? It's a somewhat heavy operation on the front end, but afterward you end up getting answers that are very cheap because all of your thinking is captured in that wiki. The

thinking has been done. When the AI is more of a reader, as in open brain, what you get is adding new information is lazy and cheap. That's sort of why I did

it because I'm a lazy person and I want my stuff autocatategorized as cheaply and easily as possible. We just write a row, we tag it and we're done. The heavy

operation is when you ask a question because the AI has to reconstruct understanding from the data each time.

So simple lookups can be fast and complex lookups will take time as the AI does deep synthesis because it's actually interrogating the raw data.

That cost is going to recur every time if you ask something similar. But on the other hand, you are not going to lose detail if you need to get into the grounds and really understand what is going on. The difference between these

going on. The difference between these approaches raises a question that that I think most of us aren't asking yet.

Whose understanding matters here? When

your AI maintains a wiki, what you are effectively saying is that when a colleague asks you about a topic, you are willing to check the wiki and trust what the AI says before answering. And

you are trusting that the AI's capture of your understanding or your thinking or the article you gave it is good enough to share with your colleagues as yours. Whereas if you have an open brain

yours. Whereas if you have an open brain style database, the providence is very clear. These are facts from identified

clear. These are facts from identified sources with timestamps. You can trace any claim back to where it came from.

What you know, you know, and you know why you know it. And you can come back with a fair bit of authority and say, "I'm not just trusting the AI's ability to synthesize information. I'm actually

saying this is the raw material I got.

This is the facts that I'm basing this on, and this is a considered opinion based on a query across all of the data that I've collected over the last few months or the last few weeks or whatever it is for you." That is a deeper and

more consequential kind of trust. It

also means the instructions you give the AI that tells it how to organize your wiki becomes the highest leverage document in the whole system. Because if

you're building a wiki, I want you to think about this for a second. If you're

building a wiki, you basically are telling in one markdown file the AI to organize and synthesize in a way that's profoundly useful to you and profoundly

accurate. and you're betting your career

accurate. and you're betting your career that it will get it right or you're going to invest time on every single ingest to make sure it's correct and to doublech checkck it. Most people will underinvest in that and the wiki will be

worse than it should be as a result. Not

because it can't be good, but because we're lazy. If we were to talk about

we're lazy. If we were to talk about what each approach is good at and where the advantages are, I would say that Carpathy's wiki wins when you're deep in research mode, when you're reading 10 papers on a topic over a couple of

weeks, which sounds a lot like what Andre does, right? like it's written for him. You could tell, right? And each one

him. You could tell, right? And each one might build on. It might contradict the last. It's a thinking person's tool. The

last. It's a thinking person's tool. The

wiki approach is going to be dramatically better in that situation because by paper five, you're continuing to wrestle with it. You're continuing to read. You're giving input. The wiki

read. You're giving input. The wiki

contains a synthesis of the first four.

You've read all of the primary sources.

You have them in your head as well. And

paper 5 can get integrated into that existing picture and help you evolve your thinking. contradictions get

your thinking. contradictions get flagged at the moment of ingest and you can see them really quickly. Cross

references get built automatically. It's

basically an academic researcher's dream. And so by paper 10, you have a

dream. And so by paper 10, you have a really rich navigable artifact that represents the current state of your understanding of a very difficult subject. It's sort of like notebook LM

subject. It's sort of like notebook LM on steroid. It's not just the current

on steroid. It's not just the current state of your files. It also wins because your personal knowledge evolves over months and you can actually see it grow. Right? So if you're thinking about

grow. Right? So if you're thinking about your health over months about self-improvement about competitive analysis for any domain where the value is in the connections between the

sources rather than in any single source alone then that's where Carpathy's approach is going to win right because you're really looking at how it can help

you understand a complex synthesis problem but open brain wins when you need precise structured operations across your knowledge base. If you want to ask, "Show me every meeting note from

Q1 where pricing was discussed," that's an open-brain type question. If you want to pull the three most recent competitor updates and compare them, that's an open-brain question. Or find all

open-brain question. Or find all actionable items assigned to me in the last two weeks, open brain. Again, these

are database queries, right? You are

digging in for specific facts. They

return exact filterable results. A

folder of text files can approximate this with some keyword search, but it's not going to be perfect, right? It's

going to miss stuff. it's going to break fast and it's not really what that whole wiki system was designed for, especially when you need to combine filters, sort by date, or work across hundreds of

entries. OpenBrain also wins for multi-

entries. OpenBrain also wins for multi- aent access when you have clouded code and chat GPT and cursor and a scheduled automation all working against the same data source at once, all needing to read from and write to the same knowledge

store at the same time. Well, you need a database that handles simultaneous access in that situation, not a directory of files where two agents editing the same page creates a complete mess. And OpenBrain wins on volume, too,

mess. And OpenBrain wins on volume, too, right? OpenBrain can handle thousands of

right? OpenBrain can handle thousands of entries across dozens of categories with search, with metadata, with relational queries. And and Carpathy absolutely

queries. And and Carpathy absolutely acknowledges this. It works best at

acknowledges this. It works best at roughly 100 to 10,000 high signal documents. It is not corporate level

documents. It is not corporate level memory. And I hear corporations saying

memory. And I hear corporations saying we should just use this for for our company level context layer. And that

will not work. And at the upper end, 10,000 documents, you already need extra search tooling just to stay manageable.

And so when you're dealing with thousands of contacts and transactions and events and tasks and documents on top of all of that, structured storage is the only sane option that scales. But

to be fair, we should look at where both systems break, right? Every system has a load where it starts to break. They just

tend to break in different ways. So as

I've called out, the wiki approach tends to break at scale. So, if you have a team that's using it where you are starting to hit that wiki structure from multiple directions, well, now the wiki doesn't know how to autooptimize, right?

If person A has an understanding that's evolving differently than person B or or agent A and agent B all have different approaches and they're trying to update the same wiki page. One, you have a conflict and that's going to be a

problem. But two, the wiki is going to

problem. But two, the wiki is going to look like a weird merge of these different approaches that doesn't reflect deep personal understanding.

Fundamentally, the semantic understanding that you're evolving with the wiki is designed for a world that's kind of like Andre's world where he's a researcher and he's thinking deeply about a problem and it's for him and

it's his evolving understanding with the agent. So for a solo practitioner, you

agent. So for a solo practitioner, you don't get issues here. But for a team, this becomes a really serious problem.

If your knowledge changes daily, if you are an operation where you have project status, you have competitive positioning, you have live deal flow, the cost of reynthesizing the wiki every time something comes in becomes really

punishing because every change potentially ripples across multiple pages in ways that you can't control.

And it should not, right? It should just be another data point in the row. And

so, think of the wiki system as being optimized for like papers and articles speed, not Slack message and ticket update speed. And that's the thing that

update speed. And that's the thing that worries me the most is that people don't recognize that a particular knowledge system is designed to work at a particular speed of business. And if you don't think about it that way, you might

implement the wrong one. A neglected

database has gaps, but the old facts are still true. as opposed to a wiki. A

still true. as opposed to a wiki. A

neglected wiki tends to drift because old syntheses become increasingly wrong as new information is not integrated, but they still read with the confidence that comes from well-written pros. And

so database staleness can look like ignorance. It can look like you're

ignorance. It can look like you're missing something. I forgot to put stuff

missing something. I forgot to put stuff into my open brain. But wiki staleness looks differently. It actually looks

looks differently. It actually looks like active misinformation because you don't know that you're wrong because the page reads like it knows what it's talking about because that is the entire purpose. It's supposed to synthesize

purpose. It's supposed to synthesize stuff and write confident pros that helps you understand a situation and you might not question the gap that you do not see. Now, let's get at some of the

not see. Now, let's get at some of the scale breakpoints for OpenBrain. And by

the way, yes, I am launching fixes for these because that's what we're all about with AI. We make things better over time. In the past, Open Brain has

over time. In the past, Open Brain has really cracked around deep synthesis quality. If you try to synthesize 15

quality. If you try to synthesize 15 different facts at once, the AI can do it, but it tends to do it in slightly unpredictable ways because it has no previous map of how that worked in the

past to do it well. It's essentially

searching the shelves of the database every single time from scratch. Now, the

answer is usually good because the AI is good, but it's rarely as good as a pre-built synthesis that had the time to integrate everything deliberately from the beginning. And that is something

the beginning. And that is something that we're addressing. Browsability is

another area that we can think about here. Open brain is deliberately

here. Open brain is deliberately headless. There's no artifact you open

headless. There's no artifact you open and wander through. And I built it that way because it gives you the flexibility to decide how you want to access it.

Now, the nice thing is it's very very easy to build the right head over the top. There are people who have added

top. There are people who have added Obsidian to OpenBrain. There's a plugin for that already. So, if that's something where you're like, I just I just can't browse the database, you're absolutely right. Just pick the plugin

absolutely right. Just pick the plugin of your choice and you can browse it.

whether that's Obsidian or something else. Here's another one we're building

else. Here's another one we're building to improve in the wiki. Contradictions

surface when new information comes in as long as your initial markdown file deliberately says look for contradiction because the AI is actively integrating against existing pages following your

prompt. But in a database environment,

prompt. But in a database environment, the contradiction might just sit silently in adjacent rows unless you specifically ask the right question to expose that contradiction. I'm building

a plugin that helps with that. If you

are interested in essentially running audits that check for contradictions in your data set, we're launching a plug-in that helps you use OpenBrain as a

contradiction surfacing tool. You can

actually build out and understand a map of the contradictions in your team or your org data sets really, really easily because you can look through the raw material and see it right away. Yes,

databases store facts. they're not

contradiction aware by default, but it's relatively easy in the age of AI to extend something like open brain and make it aware of those contradictions.

That's what I did. And I know I've spent a lot of time talking about differences, but one of the things I want to call out is that there are a lot of common principles that these systems share.

They might disagree on implementation details, but a lot of the underlying thesis or principles about AI and about data they agree on. They agree that you own the artifact, not the tool. So,

Carpathy's files are text in a folder you control. Open brains data is in a

you control. Open brains data is in a database you own. It's the same principle. Neither system hands your

principle. Neither system hands your knowledge to a platform that can repric or lock you in. Carpathy calls this file over app. I've called it building with

over app. I've called it building with no SAS middlemen. It's a very similar mindset. It's the same conviction at

mindset. It's the same conviction at root. In the age of AI, we should own

root. In the age of AI, we should own our own context layer. Right? There

should not be someone who is out there whom we are paying just to own our context layer. Also, in both systems,

context layer. Also, in both systems, the human's job is curation and questioning. We have to ask what sources

questioning. We have to ask what sources go in. We have to figure out what

go in. We have to figure out what questions to ask. We humans retain a big job in both cases. There's no substitute for thinking carefully about how to

organize your personal context layer.

And yes, the AI has lots of work to do.

It has to understand the facts that you put in an open brain. It has to be able to effectively synthesize on the wiki side. It's effectively a similar

side. It's effectively a similar division of labor. It's just timing that work differently because on the carpathy wiki approach, it's doing all of that up front and on the open brain approach, it's doing all of that at query time

when you ask. In both cases, memory compounds through intentional structure, not just through random accumulation.

The only difference is how that structure is positioned and where that structure lives. So it might live in a

structure lives. So it might live in a wiki in Karpathy's case and it lives in a SQL database in OpenBrain's case. But

in both cases, the structure is intentionally framed to enable a certain kind of connection to occur. And so for wiki work where you might want the

connections to be between documents, that makes a ton of sense, right? You

want all of the documents there. You

want the AI thinking it through. And

that's an intentional structure. Whereas

for OpenBrain, the intentional structure is a SQL database that you know can scale and it is designed to hold operational facts and make sure that they are in a neat place where you can reason against them and get audit ready

results from day one. Both systems

assume that the primary user of the knowledge base isn't you reading in a browser. It's an AI agent working on

browser. It's an AI agent working on your behalf. And I think increasingly

your behalf. And I think increasingly that's going to be the assumption of all of these memory systems. Human readability is a bonus. Asian

accessibility is actually the requirement. So now we come to what I've

requirement. So now we come to what I've built because let's be honest, we want a mature system that gives us the strength of both approaches. It's not either of those alone. And so the specific

those alone. And so the specific architecture that I'm putting together and proposing is the next major open brain extension.

You want to keep openrain as your permanent store. Don't change that. It's

permanent store. Don't change that. It's

a great spot for fax. Everything goes in there. That's fantastic. Every meeting

there. That's fantastic. Every meeting

note, every article clip, every research finding, every task, every contact, it's all tagged. It's all searchable. It's

all tagged. It's all searchable. It's

all queryable. That makes sense. That is

your durable memory layer right there.

And it can handle high volumes. It can

handle precise query. It can recall across multiple domains in your life. It

can be the source of truth. And a wiki layer can act as a compiled view on demand. And and so I'm launching a new

demand. And and so I'm launching a new process, a new plug-in where a compilation agent can run on a schedule daily, weekly, on demand. And the agent can read from open brain structured

data. Effectively, it becomes an open

data. Effectively, it becomes an open brain graph. It can synthesize across

brain graph. It can synthesize across entries. It can produce wiki pages on

entries. It can produce wiki pages on demand. It can produce topic summaries.

demand. It can produce topic summaries.

All driven by the idea that if you form a graph of your knowledge base, you can get the advantages of the wiki approach with the solidity and the factuality

that comes from an open-brain SQL database. And so these pages can be

database. And so these pages can be generated artifacts for you. Think of

them like a daily briefing that a really good chief of staff writes by reading everything in your files and distilling it into something you can browse. The

graph approach allows you to follow Karpathy's patterns for synthesis to cross reference to link related topics to flag contradictions to maintain an

evolving synthesis but it works from structured data not raw files and that means it can do things Carpathy's ingest can't like filter entries by date or category before synthesizing. It can

wait by confidence. It can exclude outdated items. In other words, the synthesis is richer because the underlying data is more detailed. The

wiki pages are an easy to read layer and you can browse them in Obsidian. You can

browse them in a note app, but they're all powered by a pre-built context graph that lives on your structured data that would not exist without your structured data. They end up being your hot

data. They end up being your hot reference for when you're actively working on a topic. And the structured data ends up being like the raw files that Carpathy uses when he wants to look

at the raw material in his wiki. But

unlike the raw files, these are easily queryable and organized in a SQL database. So you can scale them in a way

database. So you can scale them in a way that you can't with raw files. You do

not have a 10,000 file limit with OpenBrain in the same way. So the

database stays the single source of truth. New information always goes into

truth. New information always goes into the core SQL open brain first. The wiki

is never edited directly and this prevents the error compounding problem that several commenters on Carpathy's post flagged. If the AI writes something

post flagged. If the AI writes something slightly wrong into the wiki and it stays there, the next answer will build on that wrong thing and you start to get drift and errors start to accumulate.

Whereas in the hybrid model that I'm proposing with OpenBrain, the database is always authoritative. The wiki is generated from a graph built off of that

database. So if the wiki has an error,

database. So if the wiki has an error, well, you fix the source data and you regenerate. You're not dependent on the

regenerate. You're not dependent on the wiki as a source of truth. The wiki

never drifts from reality because it's always rebuilt from ground reality in the SQL database. In open brain terms, this is like a recipe. It's a composable workflow that reads from the database

and produces an output based on a graph.

A wiki compiler recipe can query relevant tables, synthesize pages through AI, and effectively develop a network of relationships and write that output to a wiki directory. And if

you're wondering, yes, it can run on an automated schedule. It can get better

automated schedule. It can get better every cycle because the underlying data hopefully, if you're committing to it, grew since last time. It becomes a compounding loop as long as you are good

at putting data in. And so what you end up with is OpenBrain for structured storage and Asian access and a Carpathy style wiki over the top for compiled understanding and human browsability.

The database ends up feeding the wiki and the wiki never contradicts the database. You can query either one

database. You can query either one depending on what you need, whether it's a precise fact or a synthesized narrative, and you can decide which you want to go for depending on the kind of

problem that you're solving. And so just to be really really blunt about which of these because I know I'm going to get asked which do I build? If you are going deep on a single research topic, if you're a solo user, if you don't need

precise queries, if you don't need multi- aent access, if you want to think by reading and by browsing, you want something running in 30 minutes with zero infrastructure. In those

zero infrastructure. In those situations, then it absolutely makes sense to use straight up Carpathy's wiki that he posted on the GitHub because the AI will build the whole system for you

and it's designed for exactly that kind of solo use case. But you should build with open brain if you need multiple AI tools accessing the same memory. If you

are assuming that you have a team working with this information, if you're capturing high volume information across many categories, if that information is not necessarily narrative based, if it's numbersbased,

if you need structured queries, if you're building automated agent workflows off of this, if you're thinking about this as infrastructure that lasts for a long time and needs to

scale and not just for a single project.

In a sense, a lot of what the wiki feels like is a better, cooler version of Notebook LM, which is an amazing tool, but not a tool that you can use for an

entire team. And so, right now, I tend

entire team. And so, right now, I tend to say have it both ways. Have your open brain running, and if you want a browsable presynthesized understanding layer, just grab the graph plugin and

add that over the top. And then neither replaces the other, and you get the benefits of both. None of this is to say that Andre Carpathy isn't right about what he built. He built a phenomenal tool for himself and for other researchers in a similar position. And

regardless of which system you end up going with, there are two ideas from Karpathy's post that are worth adopting right away. The idea file as a

right away. The idea file as a publishing format is one of those. And

one of those is really simple. It's the

way he shared it. The idea file is his publishing format. Carpathy didn't ship

publishing format. Carpathy didn't ship a tool. He published a high-level

a tool. He published a high-level description of an idea that was designed to be pasted into an AI agent that would build the specifics with you. This is

what I have been saying when I tell you to take my YouTube transcript and feed it to an AI. It is a genuinely new way to share technical knowledge. It is a great blueprint for an AI to execute.

And I think we're going to see more of it because it's much simpler than just having to give an exhaustive step by step that a human has to follow. It ends

up respecting the reader's agency because they can give their own commentary on the idea and then them and the agent can decide the details together while giving them a proven pattern to start from. And yes, if

you're wondering, you can absolutely take the transcript from this YouTube video and get started on your own memory project as we've been going through this video together. Just plug it into your

video together. Just plug it into your agent and go. But the deepest insight here is that Carpathy is moving the AI from Oracle to maintainer. The role AI plays is starting to change. Most of us

have treated AI as something you ask questions to. Whereas Karpathy correctly

questions to. Whereas Karpathy correctly treats it as something that has an ongoing job, maintaining a knowledge artifact that gets better over time. The

AI isn't here for magical pie in the sky one-off answers from the clouds. It's

here for building sustained work that compounds. And the question that we're

compounds. And the question that we're all facing is just is this the right interface for that maintenance role.

Right? I don't want to lose the fact that underneath that there is a profound insight here about moving from an answer engine mindset to moving to a mindset

where AI is a maintainer of thinking systems that allow you to think deliberately and do your work better. I

think that's a profound insight because it allows us to be the ones who curate, who think, who select, who explore, and it allows the AI to support us, right?

As we ask the right questions, the AI can help us by doing so much of the grunt work. And isn't that what we

grunt work. And isn't that what we wanted in the first place? Didn't we

want that division of labor in the AI dream world to be the AI doing more of the grunt work and human judgment being relevant? That's the dream. What Andre

relevant? That's the dream. What Andre

Karpathy is describing is one way to get there, especially if you are in a deep solo research project. And OpenBrain

describes another way to do the same thing. It's just focused on more

thing. It's just focused on more scalable structured data. And yes, you can have the best of both worlds because we can build a graph over the top of OpenBrain. This is exactly why I built

OpenBrain. This is exactly why I built it Extensible because I knew that we would have more stuff coming out around memory in 2026 and I wanted to build a foundation we could build on. So here we

are. It's our first major test and we

are. It's our first major test and we can build something over the top that allows us to have the best of this wiki approach as well as the best of the structure data that open brain gives us.

Ultimately, I think the lesson that we get from Karpathy's wiki is that we need to become thinkers about how we want our

memory and our context layers to work in order to be effective builders of agents and effective partners with AI over the second half of 2026 and into 2027. None

of what I am describing excuses us from doing that thinking. In fact, it's the opposite. What I've been spending time

opposite. What I've been spending time telling you in this video is that there is no substitute for making really clear distinctions and really clear decisions

about the way you want your knowledge structured. Whether that's just you in

structured. Whether that's just you in your room with a laptop and it's your personal knowledge base or whether it's for your team or whether it's for your org. It is up to you to say I want

org. It is up to you to say I want structured data because I know that I need to query against structured data and get reliable results above 10,000 artifacts. Or it's up to you to say you

artifacts. Or it's up to you to say you know what I want the best of both world.

There's going to be some stuff where I'm going to actually want to query with multiple agents and get structured results for three different reports at the same time. But over the top of that, I want a graph database that allows me

to think in connections between materials. That would be a little bit

materials. That would be a little bit more difficult to do if I was just querying structured data by itself. It's

up to you. It is not up to me. We all

have to wrestle with this. And if you are an engineer thinking about this or a product manager thinking about this in an org, you cannot substitute for that level of thoughtfulness. I'm sorry. You

got to do the thinking. And so I hope this video has helped give you the tools to make that decision clearly.