This analysis organizes the evidence behind design the Knowledge Base, Not the AI Tool, then explains the practical implications, trade-offs and current limits.
Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.
I spent a whole day investigating the mainstream Agent architecture, thinking that I would choose the best solution. During the process, I asked three questions of my own, pushing the proposition from "Which architecture to choose?" to "How to design a personal knowledge system that is not tied to AI tools." This article explains how these three cognitive shifts occurred, what the four-layer architecture I summarized looks like, and why I think the bottom layer should really be spent time on.
I originally wanted to choose the best Agent architecture
The starting point of this day is simple: in order to solve the problem of "the process of writing an article every week is not smooth", I want to study which mainstream Agent architecture should be chosen in 2026. Claude quickly listed four mainstream practices - flat delegation, Supervisor + Specialists, Pipeline, Knowledge Hub + Stateless Workers - and then put them into stress testing.
This is where I hit the brakes for the first time. Before the discussion is over, a stress test is required. What is to be tested? And the problem I'm worried about is not architecture selection at all - what I'm really worried about is that the longer the database grows, the tokens will explode and the models will be messed up. There is no solution to this basic problem. It doesn’t matter which architecture you choose.
As soon as I asked, the direction of the whole day changed.
The four-layer architecture I summarized
Let me state first: this is not an established term in the industry. This is what I found this time, plus my own thinking, and summarized it into a framework that I can understand. But the general foundation — MCP as a cross-tool protocol, Markdown as an open materials format, Obsidian as a presentation layer for de facto standards — these are things that are already happening in 2026, I’m not making this up.
Four levels from bottom to top:
- Layer 1 — core data layer: Pure Markdown + your local hard drive. Open format, structured, not tied to any tools. You will really die only if you die on this level.
- Layer 2 — Presentation and operation layer:Obsidian or similar tool. Turn Markdown into a browsable, linkable, and editable interface. Obsidian is not the only solution, but I have observed that it is close to the de facto standard in 2026.
- Layer 3 — Protocol layer: MCP (Model Context Protocol), an open protocol promoted by Anthropic. It allows AI tools to directly read and write Layer 1 data without manual copying and pasting. This layer is the key to making the entire system "tool-agnostic".
- Layer 4 — AI tool layer: Claude Code, Claude Desktop, ChatGPT, Gemini, OpenClaw, or whatever in-house AI the company gives you. This layer will come and go, die and change, and that’s okay.
Three design goals address these four layers:
- "Database is the core asset" → Layer 1
- "Minimizing the loss of organization" → Layer 3 (MCP allows AI to directly read and write the database, eliminating manual synchronization)
- "Tool interchangeability" → Layer 1, 3 open format + open protocol, Layer 2, 4 interchangeable
It is worth mentioning Layer 3. Many people will think of MCP as an advanced feature when they hear it, but in my opinion it is the key to unlocking the "tool-agnostic" nature of the entire system. Without MCP, "you can change models in the future" is just a vision; with MCP, you can run it today. According to public information from Anthropic and various tools, MCP-compatible clients currently include Claude Desktop, Claude Code, ChatGPT Desktop, Cursor, Windsurf, Gemini CLI, OpenAI Codex, IntelliJ - the list is still long.
My point of view: What really needs to be practiced is the ability to see "structure vs. shell"
What struck me most about this discussion was not the conclusion itself, but the fact that I derived the three turns myself.
I originally thought this was a task of "research → selection → application". Later I discovered that it was actually a task of "Every time the AI gives me a seemingly complete answer, I have to stop and ask: Is this a real question?"
The three turns correspond to three levels of redefinition:
- The first time: retreating from specific pain points to the underlying mechanism (expanded knowledge makes it difficult to understand, and architecture selection is meaningless)
- The second time: retreat from tool evaluation to design philosophy (should I use OpenClaw vs. what am I designing)
- The third time: retreat from current needs to long-term judgment (can be used before September vs can be used in the next ten years)
I'm not an engineer. I rely on Claude Code to drive all execution. But no matter how powerful the AI tool is, it will get stuck in one place - it will not take the initiative to help you take a step back and ask, "Are you solving a real problem now?" This can only be done by humans.
This is also what I have been thinking about when I switch to AI PM: tools will continue to change and be replaced by new ones. In this environment, the value of PM is not "which tool I can use", but "I can see which is the structure and which is the shell". The structure is worth spending time designing, and the shell is worth replacing at any time.
The article itself is evidence of this judgment. When the system is built, what I can talk about in job interviews in the future will not be "I learned how to use MCP" or "I tried a certain Agent architecture", but: In 2026, when AI tools are rapidly being renovated, I personally designed a personal knowledge system that makes the coming and going of tools painless, and verified that this design philosophy holds true in the scenarios of self-media, job hunting, and changing companies in the future.
If you want to start, what is the first step?
The four-layer architecture sounds complicated, but it can actually be broken down into three low-threshold actions. What is given here is direction, not complete teaching.
The first step is to convert your data into Markdown and store it locally.Whether you use Notion or Evernote now, first select a small piece (such as the work notes of the past three months), export it to Markdown, and store it in a folder on your own hard drive. This step will solve Layer 1. Open format, local storage, searchable, you won’t lose these things.
The second step is to try an MCP connection.Find an AI tool you are currently using (Claude Desktop or Claude Code are both acceptable), and follow the official documentation to run it and "let this tool read the Markdown folder you just created." Run through it once and you'll know what Layer 3 is doing. This step doesn't require any coding, it can be done at the profile level.
The third step is to develop the habit of "writing AI discussion results back to the local computer".Every time you discuss something with AI and reach a conclusion, copy and paste it back to your Markdown folder. This habit is a prerequisite for the entire system to accumulate - otherwise every discussion you have will disappear from the conversation record.
After completing these three steps, you will have a minimum operational version. After that, we need to change Obsidian, build a more complex MCP server, and evaluate OpenClaw. These are all incremental matters. If you don’t do these three steps, it will be useless no matter how many tools you buy.
Three times I was pushed by my own questions to turn around.
The first turn: from "selecting architecture" to "solving knowledge expansion"
I went back to ask Claude to search for practical solutions to "knowledge inflation". This search revealed 5 overlay technologies: Progressive Disclosure, Hot Cache, Sub-Agent isolation, Handle Pattern, and Lint mechanism. According to the implementation cases found, after the superposition of these five methods, the token consumption can be reduced to 1/15 of the original value.
At this time, I realized the first thing: the "architecture" I originally wanted to choose was secondary to the more basic issue of "how to manage knowledge expansion". Only with data management methods in place can the architecture have room to develop.
Second turn: Is what I’m doing OpenClaw?
After solving the problem of knowledge expansion, Claude simulated my "writing an article every week" process, listed 8 specific pain points and gave corresponding solutions. It looks complete.
I stopped here again: "Wait a minute, are what we are doing now rebuilding OpenClaw?"
OpenClaw is a setting that has popped up recently - what it wants to do is a cross-channel, always-on AI operating interface. After I asked this question, Claude admitted that the previous round of plans was "just right for now" - it solved the immediate pain points, but did not consider that the demand would grow on its own. After comparison, it was confirmed that OpenClaw overlaps 70% in direction with the system I planned, but the scale and purpose are different.
At this point, I may still choose OpenClaw, or I may choose to do it myself. The question hasn’t really been asked right.
The third turn: the tool is the shell and the database is the asset
Claude gives me X / Y / Z three situational multiple choice questions using OpenClaw. At this time, a sentence came to my mind and I typed it out:
"My problem is that self-media is long-lasting, not stopping in September. The pain point of the database is the loss of organization, not cross-device. OpenClaw will die in the future, and we have to protect the relationship between the lobster and the database. As long as the database is well managed, no matter which model or shell is changed in the future, it can be put on it."
After typing this sentence, the problem was redefined.
The proposition is no longer "should I use OpenClaw?" nor "which architecture to choose." The proposition is:How to design a database so that it can be painlessly connected to any AI tool in the future and the organization cost is minimal.
This is the real problem to be solved. The first two rounds were spent solving secondary problems.
Practical questions and boundaries
I'm not an engineer, can I do this?
Yes. I am not an engineer myself, and most of the system execution is done for me by Claude Code. The key is not the ability to write programs, but whether you have clearly defined what you want. The three thresholds above are all profile levels, and there is no need to write a program. The really difficult thing is to maintain the habit of "writing conclusions back to the local machine", which has nothing to do with technology.
I already use Notion/Evernote, do I need to move them all?
No need. This is not an either/or thing. You can continue to use Notion for collaboration or visual notes, but convert "the core content that you really care about, will check repeatedly, and will be used by AI" into Markdown. My own judgment standard is: If you will need this information in the next ten years, you should put Markdown. If the collaboration is within three months and will expire later, it’s okay to stay with Notion.
What is the difference between MCP and RAG?
Different layers of stuff. RAG is a technical process that finds relevant information and inserts it into context before AI answers. MCP is a protocol that allows AI tools to "connect to external data sources" in a standardized way - it can be used to implement RAG, and can also be used in many other scenarios (such as letting AI directly read and write your local folder, operate your calendar, and query the database). To put it simply: MCP is how to connect, and RAG is one of the things to do after connecting.
What to take away
The article's value is in the evidence and trade-offs behind design the Knowledge Base, Not the AI Tool, not in treating the conclusion as universal.