PowerUp Coaching — Living Knowledge Base

Your Knowledge Base Has Three Jobs and One Tool — The Hot-Cache, Wiki, Semantic Stack

5 min read

Topic

Why a single knowledge base (Obsidian, Notion, Roam, whatever) breaks somewhere between 500–2,000 entries — and the three-layer architecture (hot cache for grep, wiki for graph, semantic store for embeddings) that scales past that wall.

Target Reader

Knowledge entrepreneurs and AI-first solopreneurs who have invested heavily in a single knowledge base (often Obsidian or Notion), are now hitting friction as it grows, and suspect the problem is the tool — when the problem is actually the architecture.

The Fear / Frustration / Want / Aspiration

The frustration: knowledge base saves are getting slower, search is missing the entries that would have been most useful, and adding a new note feels heavier than it should. The fear: the second brain is becoming a liability. The want: a stable architecture that scales to 10,000+ entries without performance collapse. The aspiration: a knowledge stack where Claude can answer “what do I know about X?” reliably no matter how much you have accumulated.

Before State

The reader has one tool doing all three jobs (recent context, structured medium-term knowledge, long-term archive). It worked when they had 200 entries. It is breaking at 800. They are considering switching tools — which won’t fix the underlying architecture mismatch.

After State

The reader has a three-layer stack with explicit promotion and demotion rules. Hot cache for what is actively in motion. Wiki for structured medium-term knowledge. Semantic archive for the long tail. Claude reaches each layer with the right retrieval mechanism. Adding content is fast at every layer because no single layer carries the full load.

Narrative Arc

Open with the size-collapse failure mode — at what point Lou’s own 800-entry wiki started feeling slow, and why. Diagnose the structural issue: one tool, three access patterns, inevitable failure. Introduce the three layers — hot cache (grep-fast), wiki (graph-traversable), semantic archive (embedding-searchable). Explain why each layer has its own retrieval contract with the AI agent. Walk through promotion rules (hot → wiki) and demotion rules (wiki → archive). Close with the implementation path — what to set up first, what to migrate, what to defer.

Core Argument

A single knowledge store cannot serve all the access patterns an AI-augmented workflow needs. Recent context wants grep-speed and zero latency. Medium-term knowledge wants link-traversal. Long-term archive wants semantic search. Trying to make one tool do all three causes the failure that every growing knowledge base hits eventually. The three-layer stack assigns each access pattern its own tool — and the promotion and demotion paths between layers are what make the architecture scale.

Key Evidence / Examples

  • Kasimir’s exact setup from the AIM call — local Obsidian → Notion → Pinecone, three skills handling promotion automatically.
  • Lou’s friction point: his Karpathy-style LKB starts feeling slow around 800–900 entries; he is now considering moving the knowledge graph off document frontmatter into a meta-layer that just points at documents.
  • The Pinecone product Lou flagged — wiki-style retrieval over a semantic backend — as one possible single-tool implementation of the stack.
  • The promotion-rule heuristic: anything referenced 2+ times from outside the hot cache, or in the cache 2+ weeks, graduates to the wiki. Anything not linked/queried in 90 days demotes to archive.
  • The retrieval-contract framing — the agent does not just store in different layers; it queries them differently. Grep, graph-traverse, embed-and-rank. Three contracts, three skills.

Proposed Structure (5–7 beats)

  1. The size-collapse moment. Open with the friction point. ~800 entries, the wiki gets slow. Diagnose what is actually breaking.
  2. One tool, three jobs. The structural mismatch. Why even better tools won’t fix it.
  3. Layer 1: The hot cache. What it is, what it’s for, how Claude reaches it first. Grep-fast, flat, small.
  4. Layer 2: The wiki. Cross-linked, structured, where the graph matters. The promotion rule from hot cache.
  5. Layer 3: The semantic archive. Long-tail safety net. Why demotion is not deletion. Vector retrieval as the safety net.
  6. The retrieval contracts. The non-obvious point — agents query the layers differently, not just store in them differently.
  7. How to start. Don’t migrate everything. Create the hot cache today. Define promotion/demotion rules. Defer the semantic layer until the wiki actually needs it.

Editorial Notes

The trap to avoid: making this read like a tool-stack recommendation (“use Obsidian for X, Pinecone for Y”). The architecture is the point; the tools are interchangeable. Lead with the access pattern, not the product.

The retrieval-contract beat (step 6) is the highest-leverage idea in the piece — most existing “three-layer second brain” content stops at storage tiers and misses the retrieval-mechanism distinction. Surface this early enough that the reader internalises it.

Watch out for overlap with the existing Brief - Your Second Brain Has Three Layers and You Are Only Using One. The differentiator for this brief: previous angle was about capturing in three layers; this one is about retrieving through three layers with three different mechanisms. Make the distinction explicit so the two briefs do not blur.

Next Step

  • Approved for drafting
  • Needs revision
  • Deprioritised

Graph View