Over the past few days, I've discovered secall and built an llm wiki, experiencing a lot of trial and error, and for the first time I've actually used up the max 100 session limit.
I tried to do everything through Claude with secall, but the usage became unmanageable. I saw the developer's advice too late.
Still, after managing to convert existing sessions into wiki format, I'm now delegating wiki updates to gemma4 instead of relying solely on secall's functionality.
Of course, since gemma4 can't be completely trusted either, I'm building my own PR system.
Currently, I have 3 PR pipelines set up.
Scheduled session conversation review to explore wiki candidates and write wiki documents (gemma4)
Using wiki search mcp from a project perspective outside the llm wiki to identify gaps between the project and wiki documents, and write new wiki documents (Claude)
Using Obsidian web clipper to clip from bulletin boards, YouTube, etc., generating AI summaries through the body content and interpreter functions (gemma4, human)
These 3 pipelining methods submit PR requests to Claude, who is the llm wiki administrator, and the process is structured so Claude makes decisions to approve, reject, or request modifications. Of course, it's still being adjusted.
I also want to try using Codex, so I'm thinking of having it's GPT handle #1. Gemini didn't work out.
For #3, since it's a structure where I directly clip and save to raw, it's not included in secall embedding, so as a workaround I'm mimicking Claude Code conversation session json files and pushing the md file contents in the first turn of the conversation to do the embedding.
More sophistication will be needed though.
🧠 LLM Wiki / Second Brain Architecture Summary
📌 Core Philosophy
"Sessions end but context never dies"
Like the human hippocampus, an external memory system that structurally prevents LLM forgetting.
Not notes I view, but external memory that LLMs efficiently consume.
🏗️ Layered Structure
Raw Memory → SQLite (seCall) — original conversations/clippings/logs
Working Memory → PR layer under refinement
Knowledge Layer → Obsidian Wiki — validated knowledge
Not discarding but moving between layers. Downgrade instead of Reject.
🤖 Multi-LLM Role Separation
Role | Handled By |
|---|
Web Clipper Interpreter | Gemma 4 (local) |
Session Scan → wiki PR generation | GPT (batch) |
wiki Administrator / Gardening / PR Approval | Claude |
Regardless of which LLM you talk to, they all face the same memory layer.
🔁 PR Pipeline
Session/Clipping
↓
Gemma (summarization/compression/normalization)
↓
GPT (structuring/PR generation)
↓
Claude (review/approval/rejection)
↓
Wiki Reflection
🌱 Clipping = Seed Concept
Clipping is not complete knowledge but rather a seed of knowledge.
Paragraph-level turn decomposition → embeddable
Retrieval unit = Wiki unit
Stored in a format ready to use immediately upon retrieval
Recommended turn structure
## Summary
Core summary
## Key Actions
Action points
## Core Concepts
Core concepts
## Insight
Reasoning / meaning
## Raw
Original text
🔍 seCall Role
Command | Role |
|---|
wiki search
| Morpheme-based — "what do we know" |
recall
| Vector search — "how did we think" |
get
| Turn restoration — replay past reasoning |
BM25 + vector hybrid ensures both precision and recall.
💡 Differences from Traditional RAG
| Traditional RAG | LLM Wiki |
|---|
Data | Static documents | Living knowledge base |
Cross-session context | None | Connected via wiki + seCall |
Updates | Manual | Autonomous multi-LLM operation |
Design criterion | Optimized for humans to read | Optimized for LLMs to consume |
⚖️ Key Design Principles
Chunking is most important — "how you divide" matters more than embedding
Retrieval unit = Wiki unit — ready to use immediately upon retrieval
Downgrade instead of Reject — move layers instead of discarding
Insight is secondary data — must be validated, Claude is the gatekeeper
Layered Memory — staged refinement from Raw → Working → Wiki
🚀 Evolution Lineage
Traditional RAG
→ embed document chunks, inject on query retrieval
→ limitation: static, unstructured
LLM Wiki (current concept)
→ transform conversations/experiences into structured documents
→ limitation: still human-centric design
This system
→ optimized for LLM consumption structure
→ autonomous multi-LLM production/management
→ external expansion of context window
🎯 One-line Essence
If RAG is "retrieve and inject",
LLM Wiki is "LLMs autonomously managing their own memory structure"
Not just a second brain but a shared long-term memory layer for multiple LLMs.
And this conversation itself will be ingested to become part of that memory.
I'd love to buy the secall developer a coffee, so if you could set up some kind of channel...
Sorry for opening so many issues.
That's all for now.
