At the beginning of the year, when I switched from Logseq to VSCode + Foam, the first thought I had was: the nature of a knowledge base has changed. Storage has become cheaper; judgement has become more expensive. That's why I upgraded PKM into Agentic Brains: it's no longer merely a storage system, but a knowledge system that continuously evolves under constraints.

As Logseq updates became fewer and slower, I initially wanted a place that integrates Copilot more conveniently. I found the issue wasn't the tool itself but the whole workflow. Although VSCode + Foam is less convenient than Logseq for queries and task management, it allowed me to weave AI naturally into writing, organizing, and distillation workflows.

The shift is straightforward. In the past, knowledge management focused on storage, retrieval, and linking; now, with AI driving acquisition costs toward zero, the emphasis shifts to thinking, distillation, and decision-making. Previously I manually excerpted, organized, and built backlinks; today many raw sources can be kept as links, dialogues, or drafts — what truly requires my attention is deciding whether they deserve promotion into the knowledge layer.

Karpathy's “LLM Wiki” recently gained attention in the community and precisely filled the gap I had: explicitly making "compilation" part of the knowledge update process. Web pages scraped from around the web, AI chat logs, or content generated by agents from a single prompt are all input-layer materials; they must be compiled into knowledge-layer outputs under clear rules. That way the knowledge base becomes more accurate with use, rather than messier.

Minimal Brains Architecture

flowchart TD
  subgraph I[Input Layer]
    raws[raws/]
    journals[journals/]
  end

  subgraph K[Knowledge Layer]
    pages[pages/, pages/OKR/]
  end

  subgraph O[Output Layer]
    outputs[outputs/, outputs/blogs/]
  end

  subgraph R[Rules Layer]
    agents[AGENTS.md]
    soul[SOUL.md]
  end

  raws --> synth[organize / distill / select]
  journals --> synth
  synth -->|compile & promote| pages
  pages --> outputs
  agents -.boundary.-> synth
  soul -.style.-> outputs

I currently split the knowledge base into four layers so responsibilities are clear:

• Input layer: raws/, journals/. Stores raw information, quick notes, and unprocessed materials. Emphasize fidelity, not structure.
• Knowledge layer: pages/, pages/OKR/. Stores long-lived knowledge that has been distilled, merged, and deduplicated. Agents are allowed to edit here only under authorized rules.
• Output layer: outputs/, outputs/blogs/. Contains outward-facing content for writing, sharing, and reuse.
• Rules layer: AGENTS.md, SOUL.md. The former defines global boundaries; the latter defines personalized preferences so agents know what they can do, cannot do, and what voice to adopt.

Following Karpathy's idea, I separate raw data from knowledge and specify that agents may only modify authorized items in the knowledge zone. The goal is to put guardrails on evolution and prevent the system from being undone by its own automation.

flowchart LR
  raw[raw material: web / chats / drafts] --> compile[compile under rules]
  compile --> evidence[evidence layer]
  evidence --> page[long-lived knowledge page]
  rule[AGENTS.md / SOUL.md] -.constrain.-> compile
  agent[agent] -.write-only.-> page

How Rules Are Implemented

A directory structure alone is insufficient; the key is to encode "who may change what" as rules. My approach is simple: preserve the input layer as much as possible, allow authorized modifications within the knowledge and output layers by workflow rules, and centralize those rules in dedicated files.

To keep rules maintainable, I split the agent framework into three types:

• Role / instruction: defines role boundaries — what can and cannot be done.
• Command: defines workflows — how to do things and what the inputs/outputs are.
• Skill: defines reusable capabilities — which abilities an agent can invoke in which scenarios.

This split yields concrete benefits:

• To change input/output formats, edit a command.
• To change governance for knowledge pages, such as adding expire rules or conflict records, edit an instruction.
• To add retrieval, writing, or analysis capabilities, edit a skill.
• To update global constraints or personalized preferences, edit AGENTS.md or SOUL.md.

I also extended the framework to include OKR management and blog writing, so the knowledge base, planning system, and content production all live within the same Brains but on different surfaces. For me, this separation clarifies boundaries rather than blurring them.

Why This Fits the AI Era Better Than Traditional PKM

Traditional PKM assumes humans do the curating and tools handle storage. Brains flips that assumption: storage and preliminary processing get cheaper, while judgement, connection, and iteration become the expensive part.

First, when AI reduces implementation cost, thinking becomes more valuable. Previously an idea required research, organizing, and prototyping before validation; now many steps can be drafted by AI. Your job is to quickly decide whether a direction is worth pursuing and how to iterate. The bottleneck is no longer "can it be done" but "what should be done."

When a new idea appears, I usually drop it into journals/ or raw notes and let AI do a first-pass filter; only when it repeatedly surfaces in OKRs, writing, or projects do I promote it into pages/. Storage actions get lighter, but judgement grows heavier.

Second, raw storage is depreciating. We used to laboriously excerpt and archive because absent retrieval meant loss; now incomplete archives can often be reconstructed through search, dialog, and context. The scarce ability is connecting seemingly unrelated items.

This is why cross-domain linking gains importance: AI won't proactively create long-term, preference-aware connections for you. It can explain "what this is" or suggest "next steps," but it won't inherently understand why I place OKRs, blog writing, and governance in the same system, nor why a raw note deserves promotion to long-lived knowledge. Humans still must define the connection rules.

That said, storage still matters for research, compliance, and archival use cases where preserving originals is crucial. My claim applies where continuous distillation, production, and iteration are required.

Ultimately, Brains clarifies one thing: AI lowers implementation cost; humans decide what to keep, what to connect, and what can be changed. Rules preserve the knowledge base's sense of direction.