본문으로 건너뛰기
Back to blog
PKM

A Second Brain That Only Accumulates Is Already Dead: Building a Self-Evolving Knowledge System in a Day

Notes pile up but become useless because there is no circulation. I spent a day with AI grafting four circulation loops and automated health checks onto a knowledge vault, and the first checkup found 22 silently broken files. A hands-on build log.

10 min readPKM
second brainPKMClaude CodeObsidianAI knowledge managementself-evolving system
A Second Brain That Only Accumulates Is Already Dead: Building a Self-Evolving Knowledge System in a Day

For: solo workers who use AI tools and stockpile knowledge in Obsidian or Notion  ·  Format: build log  ·  2026-07-02

Key Summary · TL;DR

Q. My second brain keeps accumulating notes, so why does it keep getting less useful?

Because there's no circulation. If knowledge only flows in, with no path back from being used in execution to becoming a lesson learned, that's a warehouse, not a living thing. Over one day, working with AI, I wired four circulation loops and an automated health check into my vault, and the first check-up turned up 22 files that had been silently broken.

Three takeaways you can use today

  • Pick a single source of truth for each piece of knowledge, and make everything else point to it.
  • Break retrospectives down into atomic units, "[trigger] [instruction] (source)", instead of leaving them as one big document.
  • Add measurement before you add more rules. Let the system report its own pain points.
Contrast between a mounted, pinned butterfly and one alive and taking flight, navy background with an orange accent

Image: What separates a mounted specimen from a living thing isn't the wing pattern, it's circulation. A knowledge warehouse that only accumulates is the mounted specimen.

"Do I have brand documents on my site?" That question lit the fuse

It was a Wednesday afternoon. I was tinkering with my personal website and tossed a casual question at the AI: "Do I have any brand documents in my repo? If so, organize them into the knowledge vault."

Here, "the vault" means the knowledge warehouse I run in Obsidian, a note-taking app built around linked markdown files. Marketing principles, writing rules, and about 150 project retrospectives sit stacked in folders, and the AI reads this warehouse every session it works in. What people call a second brain.

I wrote in a previous build log about making the AI find its way through hundreds of notes quickly. This post is the next chapter. Once it could find things, the knowledge it found turned out not to be alive.

Organizing the documents took thirty minutes. The problem came after. In passing, the AI doing the organizing mentioned, "There's a marketing agent team that takes these brand documents as input. Though it's never actually been run."

Never actually run. That line caught my attention, and that's where the twelve hours began.

Diagram showing the only link between the knowledge vault and the 17-agent team is a single line granting read access

Image: I didn't know this gap existed until I ran an audit. This was, in effect, the system's first map.

The warehouse and the factory didn't know the other existed

My system had two buildings. One was the knowledge warehouse, the vault. The other was the execution factory.

The factory houses seventeen agents, AI workers each assigned a single role, running a conveyor-belt pipeline from brand analysis to market research to copywriting to ad creative production.

Each one was built with care. But when I set two dedicated inspector AIs loose in parallel to audit the system, it turned out the only thing linking the two buildings was a single line of access permission: "can read the warehouse."

The factory's copywriter agent was about to write however it pleased, with no idea my writing rules even existed in the warehouse. The warehouse, for its part, didn't know the factory existed at all. Knowledge and execution were two completely separate worlds.

I thought of that mounted butterfly again. Perfect down to the wing pattern, but it doesn't fly. A second brain that only accumulates is in exactly that state. Once I named the problem, the fix became obvious too. What a mounted specimen lacks is circulation.

To be alive is to circulate

I went back to the definition of a living organism. It eats, digests, absorbs, excretes. When that cycle stops, it's dead. Translated to a knowledge system, that becomes four loops.

LoopBiological equivalentIn the system
Learning loadIngestionReads lessons from past retrospectives before starting new work
Knowledge injectionDigestionThe execution side treats the warehouse's rules as the single source of truth
FeedbackAbsorptionWhat's learned from execution flows back and accumulates in the warehouse
Promotion and retirementMetabolism and excretionRecurring lessons get promoted into formal rules, stale ones get marked deprecated

My system only had half of the second loop. Everything else was severed, and nobody knew it.

What was more unsettling was the necrotic tissue. The audit turned up things like this: four documents referencing a "web designer" colleague who didn't exist. A worker whose name had changed while every reference to the old name stuck around, ghosts, essentially.

The copywriter agent took it a step further. It was configured to wait on an approval file as a required input, but no worker anywhere in the system actually produced that file. Wiring that would have stalled the moment the factory ran.

What I'd believed was an organic system turned out to be a tangle of severed wires. That day I reconnected them one by one. I deleted dead references, matched every file's producer to its consumer, and declared the warehouse's rules the single source of truth for the factory.

Diagram centered on the knowledge vault showing three of the four loops, learning load, knowledge injection, feedback, promotion and retirement, severed

Image: The most painful cut was loop 3, feedback. There was no path for what was learned to return to the warehouse.

The brain doesn't keep an address book

While reconnecting the wiring, the AI made a mistake. This is my favorite part of the whole story.

The AI organized where sessions could open into three categories: inside the vault, the factory, and other dev folders. It wrote connection rules for each, and on the surface it even looked clean.

I asked, "That's not all the folders I have. Why did you assume it was?"

When I actually counted, there were twenty drive roots alone, 163 dev folders, and 142 more on the backup cloud side. And multiple computers besides. The AI had mistaken the three folders it happened to see that day for the entire world.

A design built on registering addresses starts going stale the instant you register them. The brain doesn't work that way. When a new stimulus arrives, it doesn't ask "is this a registered address," it decides the path by asking "what type is this."

So I flipped the rule. Three questions are enough for any session to find its way. Is this the warehouse? Is this a registered factory? If neither, fall back to the default: treat it as a limb connected to the warehouse.

The beauty of this design is in the third line. Even if I create a new folder on a new drive tomorrow, it's connected to the system from the moment it's born, no registration needed. I decided that if a new folder ever forces me to rewrite the rule, that's a signal the design itself is wrong.

Flowchart of a new session being classified by checking whether it's inside the vault, then whether it's a registered system, falling through to the default connection to the vault

Image: Everything that fails both questions falls to the orange floor. That floor holds up the entire world.

Food swallowed whole doesn't get absorbed

With the circulation paths open, I needed to look at what actually flows through those pipes: the shape of the knowledge itself.

When a project wraps, I write a retrospective. But how does the AI on the next project actually use it? Rereading the whole document from scratch isn't digestion, it's just rumination.

Nutrients get absorbed at the atomic level. Lessons are no different. So I nailed the format down to a single-atom unit. Here's one lesson that actually went into the warehouse that day, verbatim.

[Trigger: When using agent A's output filename as agent B's input]
[Instruction: Verify the producer's actual filename by searching for it.
      There's precedent for a required input pointing to a filename that doesn't exist]
(Source: the copywriter's broken-wiring incident, 2026-07)

The key is putting the situational condition up front. "Double-check things" is good advice, but it's not searchable. Only when you attach a trigger like "when using an output as an input" will the machine surface it automatically the next time that exact situation comes up.

I gave lessons an expiration date too, because knowledge rots. A two-year-old lesson about an ad algorithm, injected without a label, does harm rather than good. Old lessons now automatically get tagged "needs re-verification," and instead of deleting stale ones, I leave a record of why they were retired.

Diagram breaking a full retrospective document down into a single lesson atom with three fields: trigger, instruction, source

Image: Like the stacked capsules behind it, a single retrospective yields several atoms.

Limbs can die, but if the core survives, it's reborn

In the game StarCraft, there's a race called the Zerg. At its center is a core entity called the Overmind, and as long as it survives, the Zerg can regrow their entire swarm even if every other unit is wiped out.

When the conversation reached this point, the picture I wanted clicked into place. The warehouse needed to be the Overmind. Even if the factory vanished entirely, having the warehouse should be enough to rebuild it.

The test for this comes down to one sentence. "If this folder disappeared entirely, could the warehouse alone let me rebuild a functional equivalent?"

Running the test, the factory's skeleton turned out to be non-regenerable. The role definitions for all seventeen workers, the approval process, and the hard-won know-how all lived only inside the factory.

So I planted a regeneration spec in the warehouse: the system's structure, one line of essence per worker, and a list of know-how files that absolutely had to be preserved. A genetic blueprint, in effect.

I drew the line like this: principles, know-how, and the reasoning behind design decisions are DNA, and they must live in the warehouse. Agent files and scripts are the body, and it's fine to lose them. The body can be regrown from the DNA.

I settled on a single method for backup: cloud sync. A developer would probably reach for Git, the code version control tool, but I chose to keep the number of tools I manage as small as possible instead. What I did record in the warehouse was this decision and the reasoning behind it. As long as the reasoning survives, I can always reverse the call later.

Hub diagram centered on the knowledge vault (DNA) connecting to the execution system, blog work, and dev folders, with a regeneration arrow reviving a dead system

Image: The test comes down to one sentence. "Would this regenerate even if the folder vanished entirely?"

Memory forgets, but immunity doesn't

Once I'd built this much, I asked the AI: what's the weak point in this system?

The first answer stung. "All of this stands on the assumption that I'll read the rules and follow them. If I forget, nothing happens, and nobody notices."

A rule written in prose is a memory. And memories get forgotten. What a body truly relies on is immunity, because when a pathogen shows up, it reacts automatically, no thinking required.

So I wired in hooks, a reflex that fires automatically when a specific event occurs. The moment a knowledge file in the warehouse is edited, without relying on anyone's memory, the index rebuilds itself and the file's format gets checked. A broken format gets bounced straight back to the AI.

Next I wrote a health-check script. Is the index fresh? How many days has the inbox backed up? How many broken links are there? Are the circulation loops actually running?

The results of that first check-up were the climax of the entire day. Here's part of the raw output.

[WARN] 22 frontmatter violations: closing delimiter stuck to the last
       field, parsing fails, silently dropped from the index
[WARN] inbox processing overdue: 19 items, oldest 106 days
[WARN] 4 OneDrive conflict copies: risk of knowledge diverging
[WARN] 153 broken wikilinks

Twenty-two files had been silently broken. The frontmatter (the metadata block at the top of a file) had been subtly corrupted, and they were quietly falling out of the index. The system had been treating those files as if they didn't exist for over six months.

A 106-day-old inbox backlog and four conflict copies created by two different computers also surfaced that day for the first time. The instant I switched measurement on, the system started reporting its own pain points.

One measurement beat a hundred lines of added rules. Just arriving at that sentence made the whole day worth it.

Diagram of the first health-check results: 22 broken files, a 106-day-old inbox, 4 conflict copies, 153 broken links

Image: All four numbers surfaced for the first time that day. Things nobody had known about for over six months.

In the end, the sage said "don't add more"

Late into the night, I asked one last question. "What else does this need? Just don't turn it into a mess by bolting on random extras. Think like a sage who's attained the Tao."

What came back wasn't a list of additions, it was a list of rejections.

What looks good to haveWhy it was rejected
Auto health-check on every session startAdds latency every time. A blood pressure cuff you check daily is just noise
"Capture a lesson" nudge on every turnFrequent nudges get ignored fast. It just produces junk lessons
A scheduled recurring auto-auditMore machinery means more failure points
An extra automated backup systemStacking machinery on top of a decision you've already made is just anxiety
A metrics dashboardA text report is enough. Pretty gauges stop getting looked at
More agentsThe existing seventeen haven't even run once in production. Adding more units to an unproven army just adds ranks

Every one of these just increases the part count. More parts means more failure points, and disorder grows in proportion to the number of parts. In the end, the last thing added that day was a single six-line rule.

Before adding anything, answer three questions. What specifically breaks without it? Can an existing piece be modified instead? What will you remove in exchange?

There's a line in Laozi's Tao Te Ching: wei xue ri yi, wei dao ri sun, roughly "the pursuit of learning means adding daily, the pursuit of the Tao means subtracting daily." The days spent building this system were days of adding. From here on, maturity gets measured by what I remove.

Let me be honest here. This organism hasn't taken its first breath yet. The factory pipeline still has zero production runs, those 153 broken links are still broken, and the inbox backlog is still unprocessed. Whether the circulation loops actually work will only be proven by the first real run.

Story's over, now hold it up against your own vault

Whether you use Obsidian or Notion, if notes are piling up in there, you can ask yourself the same question: is my warehouse alive, or is it a mounted specimen?

5 Levers, a Practical Checklist
  1. Single source of truth: Is the same piece of knowledge written down in two places? Pick one as the canonical version and turn the rest into pointers.
  2. Startup load: Is it defined what an AI session reads when it starts? Nail the startup procedure to the very top of your rules file.
  3. Atomize lessons: Are your retrospectives sitting dormant as monolithic documents? Break them into single lines: "[trigger] [instruction] (source)."
  4. Measure first: Can you actually measure whether the system is alive? Write one health-check script before you add another rule.
  5. Subtraction principle: Want to add something? Answer "what fails without it" first. If you don't have an answer, don't add it.

If you only take away one thing, let it be this.

A system's maturity is measured not by what you've added, but by what you've removed.

Sources

The figures in this post (22 broken files, 153 broken links, a 106-day inbox, etc.) are actual measurements from that day's health-check script. The system itself was just built, so it has zero production cycles and no performance numbers yet. The AI tool used was Claude Code, and the gaming analogy is borrowed from StarCraft's Zerg.

Found this useful? Share it

Related posts

Related projects

Get new posts by email

Insights on marketing, analytics, and dev, delivered to your inbox.