How to build a second brain that is compatible with artificial intelligence

You're driving to a car dealership. Along the way, you start talking to yourself about an article you've been thinking about. The AI asks you a question. As you merge onto the highway, you improvise for two minutes. It distills what you said into a well - structured article, files it in the appropriate document, and then moves on to the next part. You don't need to touch any screens throughout the process.

By the time you pull into the parking lot, three new sections have emerged that didn't exist when you left home. When you get home, a draft is quietly waiting in your document editor, with the correct format, clear organization, and a complete title, even though you never opened it. You've written an entire article without ever really sitting down to write.

This is how I wrote the article you're currently reading. Capturing inspiration, organizing thoughts, and retrieving information - these three tasks usually consume most of the time from the moment an idea is born to the final completion of a document. These tasks are carried out quietly throughout the day.

Now, imagine another scenario. You have the same idea while driving, but your tool can't hear you. So you have to wait until you get home. You open a document. You stare at the blank page. You try to recall what you wanted to write, but the inspiration is long gone. In the car, the idea seemed alive. Now, it's just work. You write a few sentences, then get distracted and close the tab. Three weeks later, you find the draft, realize it no longer makes sense, and delete it.

This is the gap between AI - compatible systems and AI - driven systems. One system can capture your thoughts anytime, anywhere, while the other requires you to sit down and go through the writing ritual. One system can promote the development of your ideas, while the other causes them to be lost in various frictions.

This article will explore the differences between the two - and why almost all the tools you use fall on the wrong side.

Coordination is Always a Problem

All note - taking apps on the market claim to help you organize your notes, but in the end, they make you exhausted with filing work. Naming, filing, adding tags, links, descriptions, and searching - these are all coordination tasks disguised as "note - taking organization." Once you stop inputting, these tools do nothing.

This is not a new problem since the emergence of AI. It was a problem that no one wanted to admit. The so - called "gap between knowing and doing" that people often complain about is actually a "gap in knowledge retrieval." You've acquired the information, but you can't find it six weeks later because the system transfers the responsibility of retrieval to you the moment you close the tab.

Autonomous agents are not the root cause of this problem. They just conduct stress tests until the problem breaks out in the open. All existing tools are based on the assumption that humans make decisions:

When to create a document

What name should it have?

Where to file it

When to look for it again

This assumption holds true when knowledge workers write only about ten documents a week. The artificial friction caused by slow organization is annoying but manageable.

Agents don't have this kind of friction because they don't require human intervention, avoiding questions about backlogged files. If an agent creates fifty documents a day, within a week, these tools will turn into a junkyard - pages are nested layer by layer with no retrieval path; file names are random, just the agent's thoughts at that time, and three days later, they are useless to anyone trying to find specific content.

AI doesn't break knowledge management tools. They've always had flaws. Humans have always played the role of the coordination layer - responsible for filing, maintaining the structure, and remembering where information is stored. Once humans are removed from this cycle, or when AI runs faster than humans can manually maintain, the whole system reveals its true nature: a storage container lacking a coordination mechanism. AI agents don't expose new flaws. They just generate documents so fast that the original flaws become impossible to ignore.

AI - Driven vs AI - Compatible

Major productivity tools are competing to add AI features. Notion has an AI summarization function, Google Docs has Gemini, and Obsidian has a plugin to connect to language models. They are all AI - driven, but none of them are truly AI - compatible tools.

"AI - driven" means transplanting a language model crudely into a tool originally designed for humans. The screen layout, folder structure, and data organization method - everything is built on the assumption that users click menus and drag and drop. AI has to overcome all these obstacles. It runs in a system that has never considered its way of thinking.

This is why AI in most tools feels like an intelligent assistant trapped in a room, unable to move freely. The tool says, "Here's a search bar. Find what you need." The AI searches and gets seventy - five results but can't tell which one is truly important and finally has to guess or let you choose. The tool also says, "Here's a page." The AI can read the page content and maybe summarize it, but it can't transfer the information elsewhere, can't associate it with relevant content, and can't perform any operations without your manual coordination. The intelligence is there, but the architecture hinders it everywhere.

"AI - compatible" means that the system is designed from the start to allow information to flow smoothly - whether between tools, between tasks, or between humans and AI working on the same task. The data structure is optimized so that the language model can read, process, and restore data without browsing drop - down menus or nested folder hierarchies. The operations are simple enough for the AI not to have to guess your intentions.

This is what it looks like in practice. I wrote, organized, and revised this article without opening any document editor. It should be noted that this doesn't mean the AI did the writing - it just took care of the format and organization. It actually did the following:

Extracted the entire text within seconds

Listened carefully to the revision instructions written in plain language and immediately put them into practice.

The applications don't support copy - paste, manual filing, or tab switching

Information flows to where it needs to go because the underlying system is designed for this kind of information flow.

This is the gap. "AI - driven" means implementing more intelligent functions within an existing flawed architecture; "AI - compatible" means that the architecture itself has been reconstructed so that intelligence can truly operate within it.

To understand why, just look at the stack that goes wrong every time someone tries to integrate AI into an existing product. Most teams never question this because software has always been built this way. The order is as follows:

• User Interface - including screens, buttons, modals, and drag - and - drop interactions. It's designed for people who read, click, and think about the operation steps. Every design decision here assumes human operation.
• Data Model - how the underlying data is organized to support the interface. If the user interface has nested pages, the data model has nested objects. If the user interface supports drag - and - drop sorting, the data model tracks the sorting index. The interface shapes the data.
• API - the program layer built on top of the data model. Since the data model is built to serve the interface, the API also inherits all the same assumptions. For example, nested structures, required fields that only make sense in a modal context, and ID lookup tables that humans will never see but that language models now have to access.
• Language Model - added last, like an afterthought. It has to reverse - engineer all the embedded UI assumptions in the upper layers one by one. Every step goes against the data model.

This is why Google's Gemini can't convert a Google Doc into a Google Slide without human intervention. The AI doesn't handle these cumbersome conversion tasks - you do. You need to copy the output of the Google Doc, paste it into the slide, and then tell the built - in AI in the slide how to handle the content.

Two products developed by the same company, in the same ecosystem, can't communicate with each other without an intermediary as a messenger. If you directly ask Gemini if it can do this, the answer is: no - but here are six steps that require the use of third - party tools. The opening sentence:

Although Google Docs doesn't have a native "Convert to Slide" button, you can use some reliable third - party extensions and AI tools to automate this process.

Google is not an exception. This has become the industry standard. The architectures of all PKM tools on the market - Notion, Obsidian, Roam, Mem - are all the same: design the interface first, then build the data model around the interface, add the API later, and finally add the AI. They don't take into account the era when intelligent agents can generate hundreds of documents per day without human intervention.

At this scale, a user - interface - first technology stack will not only run slowly but also crash due to its own overload. Each document created by an intelligent agent without human intervention only has a title and a timestamp, no description, and no retrieval path. With a thousand tasks per month, the knowledge base will be gone. All you get is a pile of junk with a search bar that doesn't work.

Theoretically, this reverse operation is simple, but almost no one does it. When designing, you should first consider how the language model actually thinks.

Use a flat JSON instead of a nested hierarchical structure - because nested structures cause tag inflation and traversal errors, and these errors accumulate as the scale increases.

The operations are simple, and the states are clear. The parameters are clear and easy to understand, and there is no room for misunderstanding.

There are no modal assumptions, no necessary lookup steps, and no data structures that can only be understood on the screen.

Once the API is clear and the data model is flat, the interface becomes optional. It's a viewing window built around the API's return results - not the data source and not a necessary step in the workflow. You can write 21 permanent notes, enrich 143 metadata fields, and improve the search function without opening an editor. The editor is only used for reading and polishing. All coordination work is done at the API layer, running at machine speed through tasks and agents.

When the user interface takes precedence, the API inherits all the user - interface assumptions. When the API takes precedence, the system can run without anyone's intervention.

Why is Metadata Useless and the Search Function Ineffective?

The filing cabinet is indeed an excellent solution to a tricky problem:

• You have a document that needs to be stored somewhere.
• You create folders, add labels, and put the paper in them.
• You file them in a drawer.

This system works because there is a natural limit to the amount of paper a person can actually produce. Your writing speed is limited, and the filing cabinet can only keep up.

After the advent of computers, no one stopped to think whether the filing - cabinet model was still applicable. They simply copied it:

• Folders became electronic folders
• Files got names
• The hierarchical structure became deeper

The organizational logic of the entire physical world was mapped onto a medium without any of the same limitations - and no one noticed because for a while, the data volume was still within control. A person who creates only a small number of documents per week can still maintain the illusion that the system is working properly.

But think about what's actually stored on an ordinary person's hard drive. If you print out all the files, emails, and downloaded documents and try to file them all in a physical filing cabinet, you'll need several rooms. The digital information accumulated by a person over ten years is enough to overwhelm any existing filing system because the filing - cabinet model is designed based on human reading and writing speeds and is not designed for hard drives.

However, this is still the current model. Each folder on your desktop is like a filing cabinet. Each tag in Notion is like a label on a physical folder. The metadata attached to each file - creation date, modification date, last opened date - is like stamping a date on a piece of paper before filing it. It tells you the time but not the content.

The most important thing about a file is its content - and that's the only reason you open it. Every piece of metadata attached to a file, whether on the desktop or in a cloud - based note - taking tool, tells you everything except the content.

Keyword Search will find documents that contain the words you enter, but it doesn't understand the actual content of these documents. Searching for "coordination" in a Google Doc will yield 75 results. It could be just a passing mention or an entire paper. The system can't tell. For humans, this is annoying. For an intelligent agent that needs the correct context to make decisions, this is a reliability issue that affects every downstream task.

Semantic Search works differently. It converts each document into a mathematical representation of its meaning, so when searching, you're matching concepts rather than characters. You don't need to remember the name of something; you just need to know what it refers to.

This is what it looks like in practice. My reading notes accumulated over the years are integrated into a knowledge base. I ask, "What articles have I read about building a brand voice with AI?" It will find notes that I haven't looked at for months - not because they contain the exact same words, but because their meanings are similar. Tools like Readwise take it a step further: its chat function allows you to have a conversation with the content you've marked and extract the most semantically relevant paragraphs from all the content you've saved. This is not keyword search but retrieval based on meaning.

A filing cabinet can never do this. Neither can anything built in the image of a filing cabinet.

No existing tool is designed for this world.

Do you often switch note - taking apps, hoping that the new one will solve the problems that the previous one couldn't? Each migration feels like a fresh start - the system is cleaner, the structure is clearer, and this time it will definitely work. As Tiago Forte wrote in "Building a Second Brain," every new productivity app promises a breakthrough, but in the end, it often just becomes another task to manage. The problem is never the tool itself but that each tool transfers the burden of coordination back to you the moment you finish inputting.

AI is about to significantly worsen this cycle of abandonment.

These tools are all designed for the same user: a person who creates a small number of documents per week and files them independently. Before the emergence of autonomous agents, this assumption was already untenable for knowledge workers with heavy workloads. But at least humans will eventually stop working. Humans get tired, distracted, and find it too labor - intensive to maintain the system, and then quietly stop adding content. It's this friction that prevents the landfill from being completely filled.

This is what it looks like when agents work at scale in practice. Twenty - one documents, including writings and notes, are completed within an hour, and each document lacks:

• Description
• Tags
• Semantic content
• Any background information about the internal content

There's only a document ID and the name given to it by the agent. Now, imagine asking the AI to find one of these documents three days later - not scanning the list like a human but as a language model that needs to retrieve the correct context to complete the task. You search and get a list of titles, but these titles are almost meaningless. The model either guesses wrong or wastes a lot of tokens trying to infer what it really needs.

This is not a retrieval problem but a coordination cascade problem. The absence of a metadata field during creation will lead to a series of wrong decisions in the subsequent process. The language model is not only affected by the lack of metadata, but its reliability also drops sharply as the underlying knowledge system's description of the content becomes more insufficient. Each document without a description adds an extra burden to the task of finding it later.

No amount of AI added to existing tools can solve this problem. Microsoft and Google have made the same mistake - adding intelligence to their separate products without a shared coordination layer. The AI itself is intelligent, but its underlying architecture is flawed, and in the end, the architectural flaws always win.

What Your Tools Look Like from the AI's Perspective

All discussions about AI tools focus on what AI can do for you. Almost no one asks what your tools look like in the eyes of AI.

We asked Claude to review two Python scripts he uses daily - one encapsulates an external tool designed for humans, and the other is a native document editor