Jonathon's AI Wiki

Fable 5 Second Brain — A Four-Layer Agentic Operating System (Applications, Routines, Memory, Skills)

7 min read

Source: raw/Claude_Fable_5_Built_Me_My_Perfect_Second_Brain_and_why_you_should_too.md — YouTube video (youtube.com/watch?v=VoKiKvgpk78, fetched 2026-07-06). Creator not named in the transcript or independently identified.

A creator has Claude Fable 5 build a visual “second brain” over their own workspace — a knowledge-graph-style view organized into departments (business, content, personal, community) — and frames the whole system around four components they teach as an “agentic operating system”: Applications, Routines, Memory, and Skills. The video’s central practical claim is a benchmarked speed/cost comparison: the same question answered ~40% cheaper in tokens (roughly 30K vs. 50K) and faster than a default Claude Code session with no such system, verified with the /context command.

Key Takeaways

  • The four-layer “agentic operating system” framework. The creator’s teaching model for what a fully-built agent setup needs: Applications (every tool connected via MCP/API/CLI — Google Calendar, Google Drive, etc., shown as a blue-line graph), Routines (scheduled/background tasks, e.g. a Hermes agent’s daily-log skill), Memory (the accumulated context/files — 35,466 files in the creator’s own workspace, which Fable mapped and linked), and Skills (visible in the same graph, each openable to inspect which files/routines it touches). This is a structural inventory (what’s connected) — distinct from, and complementary to, the wiki’s existing five-level retrieval-sophistication taxonomy (which answers a different question: how you search/recall, not what’s connected).
  • The graph visualization is deliberately more than decorative. The creator’s explicit critique of typical Obsidian graph views: they’re “merely for show,” illustrating that connections exist without telling you anything useful. Their version instead makes the applications layer double as an audit tool — a sparse blue-line graph shows what’s not yet connected to Claude Code (an automation gap) and, just as importantly, what is connected but no longer used (a trust/risk surface worth disconnecting) — using the example that an agent with full HubSpot control could send real marketing campaigns, so unused connections are a live risk, not just clutter.
  • Only ~30% of the value is the visualization; ~70% is retrieval speed and cost. The creator’s own framing: however good the graph looks, the real test is whether the system finds information faster and cheaper than default Claude Code — not whether it looks impressive to a client.
  • The benchmarked claim: ~40% token savings, verified via /context. Two parallel Claude Code sessions (one with the second-brain system, one default) were sent the same prompt; the second-brain session answered first and used ~30,000 tokens vs. the default session’s ~50,000 tokens for the same retrieval task, read directly off the /context breakdown. The creator says Fable ran additional self-tests confirming the pattern, but no independent verification exists beyond the creator’s own report.
  • brain.js — deterministic, non-LLM retrieval. The custom retrieval code Fable built: strip the query to keywords (discarding filler words), score every candidate file for likely relevance without opening any of them, open only the highest-scoring file, check whether a specific section (not the whole file) likely holds the answer, and follow a pointer to another file if the section says to — all via plain deterministic code, not model calls, which is the direct source of the token savings (retrieval doesn’t invoke the model until the final answer is assembled from what was found).
  • Three named inspirations the creator fed to Fable 5 as reference material: QMD (credited to Shopify founder Tobi Lütke, semantic search over a docs corpus — the same retrieval-layer category this vault itself runs), GBrain (Garry Tan, YC), and “Graphify” (a separate, YC-funded open-source repo the creator describes as building smarter connections between files/folders — see Graphify for the wiki’s existing dedicated coverage). None of the three were used directly; the creator gave Fable all three as design inspiration and let it build a bespoke system.
  • Research input: the /last30days skill, credited to Matt Van Horn (Lyft co-founder), used to scan Reddit, Twitter, YouTube, Hacker News, and other sources for current second-brain best practices before Fable designed the system.
  • Self-verification via /goal. The creator set explicit performance goals for Fable to check its own work against — e.g. the graph view reloading in under 10 seconds — and had Fable iterate against that goal after layout changes, rather than eyeballing performance manually.
  • Context/scale caveat, stated by the creator directly: their own setup and file organization is idiosyncratic to their workspace, so the specific system isn’t meant to be copied wholesale — the transferable part is the four-layer framework and the principles (deterministic pre-filtering before any model call; audit connections via the graph; verify against measured token/speed deltas, not just appearance).

How this compares to the wiki’s own pattern

This vault already runs a version of the same idea: markdown files as source of truth, QMD as the hybrid retrieval layer (one of this video’s three named inspirations), and topic _index.md files as the navigation layer. The video’s brain.js deterministic-scoring-before-any-model-call approach is architecturally close to GBrain’s regex-based graph-wiring (both push work into cheap deterministic code ahead of any LLM call) but simpler — no knowledge graph, just a scored-and-ranked file/section lookup. It’s a fresh, independently-arrived-at data point for the same “compile/pre-process before you ever hit the model” thesis this wiki’s own Pinecone Nexus and RAG primer articles already track.

Try It

  1. Before reaching for vector search or a knowledge graph, try the cheaper first step this video demonstrates: deterministic keyword-scoring across file names/summaries, opening only the top-scored candidate, and checking a specific section before reading a whole file.
  2. Use your own agent’s /context (or equivalent token-accounting command) to actually measure retrieval cost before and after any change to your memory/wiki setup — the creator’s central claim is a measured delta, not a vibe.
  3. Audit your own MCP/API/CLI connections the way the video frames the applications layer: what’s connected but unused (a risk to prune) and what’s used constantly but not yet connected (a gap to close)?
  4. If you want current best-practice research folded into a system-design prompt, consider the same pattern: run a broad web-research skill first, then hand the findings plus 2-3 reference implementations to the model as inspiration rather than asking it to design from nothing.

Open Questions

  • The claimed ~40% token savings and speed advantage come from the creator’s own single-comparison test (plus unspecified “additional tests” by Fable itself) — not independently reproduced or benchmarked against a standardized task set.
  • Exact mechanics of brain.js’s scoring function (what signal beyond keyword-stripping it uses to rank candidate files) are described only at a high level in the source.
  • Creator identity and channel were not stated in the transcript and were not independently identified.
  • Whether this system was built entirely in one Fable 5 session or iteratively refined over multiple sessions is not specified.

Graph View

Backlinks