An octopus has around 500 million neurons in a massive nervous system. Where humans concentrate most neurons in the head, an octopus does the opposite. About two-thirds live in the arms themselves — roughly 40 million per arm — forming eight semi-autonomous mini-brains. Each arm tastes, touches, and makes motor decisions on its own. A central brain coordinates.
That's the architecture I ended up building — accidentally, then deliberately — for the way Claude works with my knowledge. Hence: Project Octopus. Here's what broke, what fixed it, and a prompt you can borrow to try the same pattern on your own knowledge bases.
The problem: four brains, no conversation
The whole thing started after I worked through Ken Lomax's wonderful workshop, My Second Brain (you find similar content on Youtube) — the idea that you have your own wiki which Claude Code builds from a folder with raw files. The idea landed, and I got to work creating brains one at a time.
First I had just the one that helps me with organizing my tool knowledge, mostly in the unfathomable depths of ABAP documentation. Realizing that I cannot have one large brain for all my needs, I started to create other ones, to avoid dilution of knowledge. I created another one for the new field of code-based agents, and one for personal development which became a pretty cool career advisor as we are currently preparing our Q3 SAP talks. And another one for API and Business Object documentation.
Keeping them separate was intentional. A single mega-brain collapses under its own weight, mixing goal-setting advice with ABAP transaction quirks.
The trade-off: Claude only knew about the individual ones when you worked in the corresponding project folder. Sit inside one brain and drift into a topic that belongs to another, and Claude has no way of knowing the other brain even exists. The answer comes from raw model knowledge — plausible, generic, and sometimes wrong.
The fix: a coordinating brain
The solution turned out to be smaller than expected. Not a fifth brain, but a compact registry — one table in the global CLAUDE.md that every Claude session loads automatically. Each row names a brain, its path, its scope, and the topics that trigger a consult. Two rules follow: read the matching brain's index before answering, and reconcile across brains when a topic straddles two of them.
That's it. No new folders, no orchestration layer, no third-party tooling. Just a lookup table that lives where Claude already looks.
The octopus metaphor writes itself. The four brains are the arms — specialized, autonomous, each holding its own hard-won knowledge. The registry is the central brain, unimpressive on paper, doing the one thing central brains do well: routing signals to the arm that already knows the answer.
Try it yourself
If you have two or more brains and want the same routing setup, drop the following into a Claude session and let it do the discovery and wiring for you.
Note: Your brain folders might not be called `mybrain<Name>` — adapt the naming in the prompt below to match your own convention.
Here's the prompt:
I have multiple "second brain" folders on my machine — each is a folder named `mybrain<Something>` following the LLM-Wiki pattern, with `raw/`, `wiki/`, and a `CLAUDE.md` at the root. Right now Claude only sees whichever brain I happen to be sitting in, so knowledge in the other brains stays invisible for the session. Fix that. Steps:
1. **Find all my brains.** Search my user home directory and its subfolders (including any OneDrive folders) for directories matching `mybrain*` that contain a `CLAUDE.md` at their root. Skip `.zip` archives, empty folders, and staging folders that lack the full brain structure.
2. **Read each brain's `CLAUDE.md`** to pull out its purpose and scope. Do not modify anything inside the brain folders.
3. **Locate my global Claude config** at `~/.claude/CLAUDE.md` (Windows: `C:\Users\<me>\.claude\CLAUDE.md`). If it does not exist, stop and tell me before creating anything.
4. **Prepare a new section** titled `## Personal Knowledge Bases (mybrain* wikis)` containing:
- A one-line introduction to the routing pattern.
- A markdown table with one row per brain, columns: **Brain**, **Path**, **Scope**, **Consult when**. Derive "Consult when" from each brain's own scope, pulling out two or three concrete topic keywords.
- A short workflow: read the matching brain's `wiki/index.md` first, cite pages, reconcile across brains when a topic spans two of them, fall back to model knowledge only when no brain covers the topic.
- A rule that each brain's `raw/` folder is read-only.
5. **Show me the preview** and ask me to confirm before writing the section into the global CLAUDE.md. Preserve everything already in that file — append or splice in cleanly, do not overwrite unrelated sections.
6. **After writing**, tell me how to verify: open a new Claude session, ask a question that clearly belongs to one specific brain from any folder on disk, and confirm Claude routes to that brain's wiki before answering.
Do not create any new brain folders. Do not modify anything inside the existing brains. Only edit the global `~/.claude/CLAUDE.md`.
Closing thoughts
That's the whole pattern: four arms of specialized knowledge, one small table in the middle, no orchestration layer. Total wiring cost was one section in a markdown file, and Claude now routes across brains without me having to remember which folder I'm sitting in.
If you're running multiple wikis and want the same routing, the prompt above will set it up for you. And if you've built a different way of stitching separate knowledge bases together, drop it in the comments — I'd like to see what other shapes this pattern can take.
Bluesky
